Forensics · Lesson 09
User Accounts & Authentication Evidence
Learn how account state, privilege, authentication, session type, profile evidence, and account changes work together to answer who could act, who authenticated, and what happened afterward.
Account evidence is easy to overstate. An administrator account is not proof of misuse, and a successful login is not proof of physical identity. Build conclusions from multiple layers.
Lesson Snapshot
Learning objectives
Separate identity, privilege, authentication, and activity
Explain how account state, group membership, authentication records, and session evidence work together.
Distinguish account existence from account use, and privilege capability from actual privileged action.
Recognize useful Windows and Linux account evidence without assuming that every administrator or sudo-capable account is unauthorized.
Correlate login events with account changes, file activity, services, tasks, shell history, and network evidence.
Preserve the original state of accounts and groups before disabling, deleting, or changing membership.
Write concise evidence-backed answers about who authenticated, what privileges existed, and what account changes occurred.
Core idea
Build account conclusions in layers
First prove the account exists, then determine its state and privileges, then establish authentication and session type, and finally correlate activity that occurred afterward.
Competition caution
Preserve the account before you remove it
Record account state, privileged groups, profile or home directory, authentication events, task/service assignments, and relevant ownership before making defensive changes.
Account principles
Avoid the most common identity assumptions
Account existence is not account use
A user account can exist without being used. Authentication logs and session evidence are needed to show activity.
Privilege is capability, not proof of action
Administrator, sudo, or privileged-group membership shows what an account can do, not what it actually did.
Authentication is not physical identity
A successful login proves that credentials or another authentication method were accepted for an account. It does not prove who was physically present.
Group changes matter
Adding or removing an account from Administrators, sudo, or another privileged group can change its effective capabilities.
Account lifecycle is evidence
Creation, enablement, disablement, password changes, lockouts, and deletion can all help reconstruct account history.
Document before hardening
Disabling or deleting an account can destroy easy access to membership, profile, ownership, and session context.
Evidence layers
Move from identity to action
Identity
Username, SID or UID, display name, profile/home path, local vs domain context.
Question answered
Which account is this?
State
Enabled, disabled, locked, expired, password-required, shell, home directory.
Question answered
Can the account currently authenticate or operate normally?
Privilege
Administrators, sudo, wheel, service rights, privileged groups, sudoers rules.
Question answered
What can the account potentially do?
Authentication
Successful and failed logons, SSH, RDP, local login, sudo authentication, cached login.
Question answered
When and how was the account authenticated?
Session
Interactive session, remote session, service logon, terminal, current login, session start and end.
Question answered
What kind of session existed?
Activity
Files, processes, services, tasks, commands, network connections, application use.
Question answered
What happened during or after the session?
Windows
Account evidence sources
Local Users and Groups
Local accounts, group membership, account state, and descriptive fields.
Availability can vary by Windows edition and environment.
net user / Get-LocalUser
Local account inventory and properties.
Account presence alone does not prove recent use.
net localgroup / Get-LocalGroupMember
Local group membership such as Administrators or Remote Desktop Users.
Membership proves capability, not that the privilege was used.
Security event log
Authentication, account creation, enablement, disablement, deletion, and group changes where auditing is available.
Coverage depends on audit policy and retention.
User profile directories
Profile existence, files, downloads, application data, and ownership context.
A profile can remain after an account is disabled or deleted.
Scheduled tasks and services
Accounts configured to run automated tasks or services.
Service or task account use is different from interactive user activity.
Linux
Account evidence sources
/etc/passwd
Username, UID, primary GID, comment field, home directory, and login shell.
The password hash is not stored here on modern systems.
/etc/shadow
Password-hash and password-aging information for local accounts.
Highly sensitive and normally readable only by root. Do not expose or copy real password hashes unnecessarily.
/etc/group
Local group membership and group identifiers.
Primary group membership may also be represented through /etc/passwd.
getent
Account and group records from the system's configured identity sources.
Can include directory-backed identities, not only local files.
auth.log / journal
Login, sudo, SSH, PAM, and authentication evidence where configured.
Logging source depends on distribution and configuration.
Home directories
User files, shell history, SSH data, application settings, scripts, and ownership context.
Home-directory evidence does not automatically prove recent authentication.
Windows commands
Inspect account state and group membership
List local users
Get-LocalUser
Shows local Windows accounts and basic state.
Inspect one local user
Get-LocalUser -Name "trainee1" | Format-List *
Displays detailed local-user properties for an authorized lab account.
List Administrators
Get-LocalGroupMember -Group "Administrators"
Shows local members of the Administrators group.
Classic account view
net user trainee1
Shows account state and selected account-policy details using a widely available Windows command.
Classic group membership
net localgroup Administrators
Lists members of the local Administrators group.
Current identity
whoami whoami /groups
Shows the current security principal and group memberships for the current process token.
Linux commands
Inspect identities and privilege groups
List passwd records
getent passwd
Shows account records from configured identity sources.
Inspect one account
getent passwd trainee1
Shows UID, primary GID, home directory, and shell for one account.
Group membership
id trainee1
Shows UID, primary GID, and supplementary groups.
List sudo group
getent group sudo
Shows members of the sudo group on Ubuntu-family systems.
Account status
sudo passwd -S trainee1
Shows local password/account status without displaying the password hash.
Current identity
whoami id
Shows the current account and group memberships.
Windows authentication
Common Security events for account investigations
Successful logon.
Establishes that Windows accepted authentication for an account and records useful session details such as logon type.
Failed logon.
Useful for failed authentication attempts, target account, source context, and failure reason.
Logoff.
Can help bound a session when paired with related logon information.
Explicit credentials used.
Useful when a process or resource access used separately supplied credentials.
Special privileges assigned to a new logon.
Useful for identifying privileged sessions.
User account created.
Establishes account creation timing.
User account enabled.
Shows when a disabled account became active.
User account disabled.
Shows a defensive or administrative state change.
User account deleted.
Helps reconstruct account lifecycle.
Member added to a security-enabled local group.
Useful for privilege escalation or authorized membership changes.
Member removed from a security-enabled local group.
Useful for privilege reduction or cleanup tracking.
Linux authentication
Common login, SSH, PAM, and sudo clues
Accepted password / Accepted publickeySSH authentication succeeded for the recorded account and source.
Limit
Does not prove whether the session was authorized or who physically controlled the client.
Failed passwordAn SSH authentication attempt failed.
Limit
A single failure may be normal; patterns and later success matter.
sudo commandAn account attempted or performed a command through sudo.
Limit
Read the exact command and result before describing the action.
session openedA PAM-managed session began for a service or account.
Limit
Session type and service context determine what kind of access occurred.
session closedA PAM-managed session ended.
Limit
Not every relevant activity is perfectly bounded by session records.
useradd / adduser / group changesAccount-management activity may appear in system logs or shell/admin records.
Limit
Confirm the resulting account and group state directly.
Question-to-evidence map
Use the right evidence for each account question
Does this account exist?
Local account inventory, getent, /etc/passwd, Get-LocalUser, or directory service records.
Is the account enabled?
Account status fields, passwd status, Windows account properties, or lifecycle events.
Is the account privileged?
Administrators, sudo, wheel, sudoers, or other privileged-group and policy evidence.
Did the account authenticate?
Security log, auth.log, journal, SSH records, RDP records, or local session evidence.
What kind of session existed?
Windows logon type, SSH/session records, who/w, service context, or task/service configuration.
What did the account do?
Files, processes, commands, services, tasks, application logs, and network evidence.
Privilege reasoning
Capability is not the same as action
student1 is a member of Administrators
Supported
The account has local administrative capability.
Not supported
The account used administrative privilege during the incident.
analyst is in the sudo group
Supported
The account may be allowed to use sudo according to system policy.
Not supported
The account executed a privileged command.
4672 follows a Windows logon
Supported
That logon session received special privileges.
Not supported
Those privileges were abused.
sudo log shows trainee1 ran systemctl restart ssh
Supported
The account invoked that command through sudo at the recorded time.
Not supported
The restart was unauthorized without scenario context.
backup-helper is added to Administrators
Supported
The account's local privilege capability increased.
Not supported
The account was malicious.
user removed from sudo group
Supported
The account's group-based sudo capability changed.
Not supported
All privilege paths were removed unless sudoers and other mechanisms were checked.
Profile evidence
User directories add activity context
C:\Users\<user>
WindowsDesktop, Downloads, Documents, AppData, browser profiles, application state, and file ownership.
Profile existence does not prove recent login.
/home/<user>
LinuxDocuments, downloads, shell history, .ssh, .config, scripts, and user-local data.
Home-directory timestamps may reflect automated application activity as well as human activity.
Profile ownership and ACLs
WindowsHelps connect files and directories to security principals.
Ownership can be reassigned and does not prove authorship.
UID/GID ownership
LinuxConnects filesystem objects to local account identifiers.
UID reuse or copied files can complicate historical interpretation.
Session types
Authentication context changes meaning
Interactive
WindowsLogon type 2
Local console-style user session.
Remote interactive
WindowsLogon type 10
Remote Desktop-style interactive session.
Network
WindowsLogon type 3
Network resource access or service interaction.
Service
WindowsLogon type 5
Service account session.
SSH
Linuxsshd accepted authentication and session-open messages
Remote shell or remote command session.
Local terminal
Linuxlogin/display-manager/PAM session evidence
Local user session.
Password & account state
State changes can explain authentication behavior
Password change
A password-reset or change event can explain later authentication success or failure.
Lockout
Repeated failed attempts or policy can temporarily prevent authentication.
Expiration
Expired passwords or accounts can explain failed logons without indicating an attack.
Password required
An account configured without normal password requirements may deserve review against the scenario.
Do not expose secrets
Never publish real passwords, password hashes, recovery codes, keys, or tokens in training documentation.
Service accounts
Not every active account represents a person
Service account
An account may exist mainly to run a Windows service, scheduled task, Linux daemon, or automation.
Non-interactive account
Some accounts are intentionally configured with shells or policies that prevent normal interactive login.
Built-in account
Windows and Linux include built-in system identities that should not be treated like ordinary human accounts.
Application-created account
Installed software can create dedicated accounts for isolation and least privilege.
Scenario context
The competition scenario determines whether a service or application account is expected and required.
Correlation
Combine account, authentication, and activity evidence
4720 account creation at 09:12 + 4732 Administrators membership at 09:13 + 4624 logon at 09:20
Supported conclusion
A newly created account gained administrative membership and later authenticated successfully.
SSH accepted login at 10:02 + sudo command at 10:05 + config mtime at 10:05
Supported conclusion
The account authenticated remotely and performed a privileged command aligned with the configuration change.
4625 failures at 11:30-11:32 + 4624 success at 11:33
Supported conclusion
Several failed Windows logons preceded a successful authentication.
Linux user added to sudo group at 12:10 + sudo service restart at 12:14
Supported conclusion
Privilege capability increased before a privileged service action.
RDP-style logon type 10 at 13:01 + user profile file change at 13:05
Supported conclusion
A remote interactive session existed before the profile file changed, but authorship still requires more evidence.
Service account logon + service start + process owned by same account
Supported conclusion
The account was being used in service context rather than ordinary interactive use.
Evidence note
Document account evidence so another teammate can verify it
Forensic question
Hostname
Account name
SID or UID if useful
Account state
Groups / privilege
Authentication source
Session type
Timestamp and zone
Source address if remote
Related file/process/service
Supported conclusion
Preservation checklist
Before disabling, deleting, or changing the account
Record the account name exactly.
Record whether the account is enabled, disabled, locked, or expired where available.
Record privileged and relevant group memberships.
Record home/profile path and ownership context.
Record recent authentication evidence.
Record session type or logon type.
Record source address for remote authentication where available.
Record service or task assignments using the account.
Record relevant sudoers or local policy context.
Record account creation or membership-change events.
Separate original state from your own defensive changes.
Only then disable, remove, or change the account if the scenario allows and requires it.
Common mistakes
Account-analysis mistakes that create false conclusions
Deleting the account first
This can remove easy access to membership, profile, ownership, and session context.
Treating admin membership as proof of misuse
Privilege capability is not the same as privileged action.
Treating successful login as physical identity
Credentials may be used by another person, service, or remote operator.
Ignoring session type
Interactive, remote, network, service, and batch sessions have different meanings.
Ignoring service accounts
Automated accounts can appear active without a human interactive session.
Trusting shell history as complete
Shell history can be incomplete, delayed, disabled, or altered.
Ignoring account lifecycle events
Creation, enablement, disablement, deletion, and group changes often explain the timeline.
Recording secrets
Do not copy real passwords, hashes, private keys, or tokens into training notes.
Fictional account lab
Reconstruct account creation, privilege, login, automation, and network activity
Account lab-helper is created on CP-WIN-11.
lab-helper is added to the local Administrators group.
lab-helper successfully logs on with logon type 10.
A file under C:\Users\lab-helper\Downloads is created.
A fictional task is configured to run under lab-helper.
A process running as lab-helper opens a connection to fictional lab host 203.0.113.90.
Task 01
Which event proves the account existed before the login?
The account-creation event at 14:02.
Task 02
What establishes that the account had local administrative capability?
The Administrators group-add event at 14:03.
Task 03
What does logon type 10 add?
It supports that lab-helper authenticated through a remote interactive session such as RDP.
Task 04
Does the file in Downloads prove the account owner created it personally?
No. The file exists in that profile context, but authorship requires additional evidence.
Task 05
What evidence connects the account to automated activity?
The scheduled task configured to run as lab-helper.
Task 06
What should be preserved before disabling lab-helper?
Account state, group membership, profile evidence, authentication events, task configuration, process evidence, and network evidence.
Lesson checklist
Before moving on
I distinguish account existence from account use.
I distinguish privilege capability from privileged action.
I record account state before changing it.
I record relevant group membership.
I identify the authentication source and session type.
I record source address for remote logins where available.
I correlate account evidence with files, tasks, services, and processes.
I recognize service and automation accounts.
I use Windows Security or Linux auth/journal evidence to prove authentication.
I do not treat a successful login as proof of physical identity.
I separate original evidence from my team's defensive changes.
I avoid collecting or exposing secret credentials.
Reflection
Check your account reasoning
Question 1
Why does administrator or sudo membership fail to prove that privilege was used?
Question 2
What additional evidence do you need after confirming that an account exists?
Question 3
Why does session type matter when interpreting authentication?
Question 4
How can a service account create misleading assumptions about human activity?
Question 5
Why should you record group membership before removing an account from a privileged group?
Question 6
What evidence would you use to connect an authenticated account to a specific file or process action?
Carry this forward
Prove the account, state, privilege, authentication, session type, and activity separately. Correlate before concluding, and preserve account evidence before defensive cleanup.