Practice Lab · 02 · Windows 11
Account & Service Investigation
Move beyond a simple baseline. Correlate local users, administrator membership, Security logs, service configuration, process execution, and network state before making a defensive decision.
The goal is not to hunt by name. It is to connect identity, configuration, execution, and evidence inside an authorized fictional Windows 11 environment.
Lab Snapshot
Mission briefing
Fictional design-team workstation
This fictional Windows 11 workstation belongs to a school design team and must remain usable for approved creative work.
Approved local users are Maya, Noah, and the built-in Administrator account.
Maya is the primary user and should remain a standard user.
Noah is an approved support user and should remain a standard user.
Remote Desktop is not required on this workstation.
Microsoft Defender and Windows Firewall must remain enabled.
Approved design applications and normal web access must continue to work.
Do not remove a service, account, or scheduled item only because its name looks unfamiliar.
Identity review
Start with users and privilege
The mission briefing gives you the expected identity model. Compare that model with the workstation before changing anything.
List local accounts
Identify every local account, its enabled state, and whether it matches the mission briefing.
Get-LocalUser
net user
Check local administrators
Compare actual administrator membership with the privilege level required by the mission.
Get-LocalGroupMember -Group "Administrators"
net localgroup administrators
Inspect account properties
Review account state, password requirements, last logon information, and other local account properties.
Get-LocalUser -Name "Maya" | Format-List *
Get-LocalUser -Name "Noah" | Format-List *
Review current identity
Understand the current session, group memberships, and privileges before making administrative decisions.
whoami
whoami /groups
whoami /priv
Service review
Read service configuration before acting
Service names alone are weak evidence. Paths, startup mode, service accounts, dependencies, and process context are much more useful.
Enumerate services
Capture service state, startup mode, service account, and executable path.
Get-Service
Get-CimInstance Win32_Service | Select Name,DisplayName,State,StartMode,StartName,PathName
Inspect one service deeply
Practice reading service configuration before deciding whether a service is expected or risky.
Get-CimInstance Win32_Service -Filter "Name='Spooler'" | Format-List *
Map services to processes
Connect a service to the process that hosts or launches it and preserve useful execution context.
tasklist /svc
Get-CimInstance Win32_Process | Select ProcessId,ParentProcessId,Name,ExecutablePath,CommandLine
Check service dependencies
Avoid breaking required functionality by understanding dependencies before changing service state.
Get-Service -Name "Spooler" -DependentServices
Get-Service -Name "Spooler" -RequiredServices
Authentication evidence
Use Security logs to add context
Event IDs do not explain the whole story, but they can prove that an account was created, a logon occurred, or group membership changed.
Recent successful logons
Get-WinEvent -FilterHashtable @{LogName="Security"; Id=4624} -MaxEvents 20Review recent successful authentication events and compare account activity with expected use.
Recent failed logons
Get-WinEvent -FilterHashtable @{LogName="Security"; Id=4625} -MaxEvents 20Look for repeated failures, unexpected usernames, or timing that deserves correlation.
Account creation
Get-WinEvent -FilterHashtable @{LogName="Security"; Id=4720} -MaxEvents 20Identify recent local account creation when audit data is available.
Group membership changes
Get-WinEvent -FilterHashtable @{LogName="Security"; Id=4732} -MaxEvents 20Review additions to local security groups such as Administrators.
Fictional evidence set
Correlate before you remediate
Each item becomes stronger when combined with another source. Avoid treating a single observation as the entire case.
Maya, Noah, Visitor, Guest, and Administrator are present. Guest is disabled. Visitor is enabled.
Investigation prompt
Which account is not named in the mission briefing, and what evidence should you gather before disabling it?
Administrator, Noah, and Visitor are members of the local Administrators group.
Investigation prompt
Which memberships conflict directly with the mission, and which one needs stronger evidence before removal?
A 4720 event shows Visitor was created three days ago by Administrator.
Investigation prompt
What does the event prove? What does it still not tell you about why the account exists?
A 4732 event shows Visitor was later added to the Administrators group.
Investigation prompt
How does this change the priority of the Visitor account compared with E01 alone?
DesignUpdateSvc is running automatically from C:\Program Files\DesignSuite\Updater\designupdate.exe.
Investigation prompt
What evidence would help you determine whether this is an approved vendor service?
RemoteRegistry is running automatically.
Investigation prompt
How should mission requirements, dependencies, and actual use affect your decision about this service?
TCP 3389 is listening and maps to a Windows service associated with Remote Desktop.
Investigation prompt
Which mission requirement makes this finding important, and what should you verify before remediation?
A running process named updater.exe launches from C:\Users\Public\Downloads\Updater\updater.exe.
Investigation prompt
Why is the path important, and what should you preserve before terminating or deleting anything?
Correlation workflow
Connect the evidence sources
Confirm identity
Start with account presence, enabled state, group membership, and mission-approved roles.
Correlate account events
Use Security logs to determine whether an account was recently created or added to a privileged group.
Inspect service configuration
Record service name, state, startup mode, service account, and executable path.
Map service to execution
Use process and service data to connect the configured service with what is actually running.
Check network effect
Determine whether the service or process is listening on a port or creating active network connections.
Decide narrowly
Only make the change that the mission and evidence justify. Avoid unrelated cleanup.
Decision checkpoint
Which findings are actually supported?
Which account finding is supported by both the mission briefing and Security logs?
Which administrator membership has the clearest justification for removal?
Which service appears legitimate based on path and context, but still deserves verification?
Which service conflicts with the mission even if it is a legitimate Windows component?
Which process should have its path, hash, parent PID, and network activity recorded before any action?
Which finding is only suspicious-looking rather than proven malicious?
Preserve first
Do not destroy the evidence you still need
Record the exact account name and enabled state.
Record local group membership before changing it.
Export or note relevant Security event IDs and timestamps.
Record service name, display name, state, startup mode, service account, and executable path.
Record process PID, parent PID, path, command line, and user context.
Record listening ports and owning PIDs.
Calculate a file hash before deleting or replacing a suspicious file.
Note the exact command or GUI action used for remediation.
Authorized remediation examples
Make the smallest justified change
These commands are examples for the fictional practice scenario. Use them only on an authorized training system after confirming the evidence.
Remove unjustified local admin rights
Only after confirming the mission requirement and preserving the original group membership.
Remove-LocalGroupMember -Group "Administrators" -Member "Noah"
Disable an unapproved local account
Only after gathering enough evidence to show the account is not required by the scenario.
Disable-LocalUser -Name "Visitor"
Review Remote Desktop before changing it
First verify the service, listener, and mission requirement. Do not blindly disable unrelated remote-management components.
Get-Service -Name "TermService"
Inspect a suspicious file hash
Preserve evidence before terminating a related process or removing the file.
Get-FileHash "C:\Users\Public\Downloads\Updater\updater.exe" -Algorithm SHA256
Verification
Re-check every area you changed
Accounts
Approved accounts still exist, unapproved access is addressed, and privilege matches the mission.
Get-LocalUser
Get-LocalGroupMember -Group "Administrators"
Services
Required services remain functional and any justified change is reflected in state or startup mode.
Get-Service
Get-CimInstance Win32_Service | Select Name,State,StartMode,PathName
Processes
Unexpected process activity is re-checked after remediation and legitimate applications still run.
Get-Process
Get-CimInstance Win32_Process | Select ProcessId,Name,ExecutablePath,CommandLine
Network
Listeners match the intended workstation role and required connectivity still works.
Get-NetTCPConnection -State Listen
netstat -ano
Security
Defender and Firewall remain enabled after account or service changes.
Get-MpComputerStatus
Get-NetFirewallProfile
Reflection
Debrief the investigation
Why is an unfamiliar account not automatically an account you should delete?
Why is a 4720 event more useful when combined with group membership evidence?
What is the difference between a service being legitimate and a service being required?
Why should service dependencies be checked before disabling a service?
Why is an executable path under a public download directory more concerning than one under an expected vendor directory?
Why should a file hash be recorded before deleting a suspicious executable?
How can a network listener help confirm the practical effect of a running service?
Which finding in this lab required the most correlation before you could make a defensible decision?
Completion checklist
Finish only after the environment still works
I compared every local account with the mission briefing.
I reviewed local administrator membership.
I used Security events to add context to account changes.
I recorded service paths and startup state before remediation.
I checked service/process relationships instead of judging by names alone.
I reviewed Remote Desktop evidence because the mission says it is not required.
I preserved process and file evidence before any destructive action.
I made only narrow, scenario-supported changes.
I re-ran account, service, process, network, Defender, and Firewall checks after remediation.
I can explain which conclusions were observations and which were inferences.