Practice Lab · 11 · Mixed Systems
Mixed-System Incident Triage
Prioritize and correlate findings across Windows 11, Linux, Windows Server, and Cisco without treating every anomaly as the same level of risk.
The challenge is not finding the most issues. It is deciding what matters first, what is related, and what can safely wait.
Lab Snapshot
Mission briefing
Find the highest-risk path without breaking the environment
This fictional incident spans one Windows 11 workstation, one Ubuntu workstation, one Windows Server host, and one Cisco access switch.
The team has a limited investigation window and must prioritize the systems most likely to affect the rest of the environment.
Preserve evidence before making changes that could destroy logs, process state, network state, or authentication clues.
Do not assume every unusual setting is malicious; compare each finding with the mission requirements.
Use cross-system evidence to determine whether events are related or merely coincidental.
Contain only the systems and services supported by evidence, and preserve required competition functionality.
Document what is known, what is suspected, and what still requires verification.
This is an authorized defensive practice scenario only.
Environment
Know the role of each system before triage
WIN11-OPS
Operations workstation
Defender and Firewall enabled, RDP not required, only approved users should have local administrator rights.
UBU-DEV
Linux development workstation
SSH not required, priya may use sudo, alex should not have unrestricted sudo.
SRV-FILES
Windows Server file server
SMB file sharing required, approved administrator access only, suspicious services must be investigated.
SW1
Cisco access switch
VLANs 10, 20, and 99 remain operational, management restricted to VLAN 99, access ports retain intended security.
Priority model
Rank findings before acting
Active compromise or propagation risk
Preserve evidence, confirm scope, and contain only the verified risky component.
Identity and privilege exposure
Determine whether the identity is approved, when the change occurred, and whether it enabled other activity.
Configuration weakness without active evidence
Record the weakness, verify mission requirements, and remediate after higher-risk findings are handled.
Benign or mission-required anomaly
Document why it is expected so the team does not waste time repeatedly investigating it.
Windows 11 triage
Prioritize privilege, execution, and outbound activity
Users and administrators
Identify unexpected local users and privileged membership before changing anything.
Get-LocalUser
Get-LocalGroupMember Administrators
Processes and connections
Correlate running processes with active communication and prioritize unknown network-active processes.
Get-Process | Sort-Object ProcessName
Get-NetTCPConnection | Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,State,OwningProcess
Services and persistence
Review services and scheduled tasks that could explain repeated execution.
Get-Service | Sort-Object Status,Name
Get-ScheduledTask
Security events
Correlate logons, failed logons, privilege use, account creation, and group changes.
Get-WinEvent -FilterHashtable @{LogName="Security"; Id=4624,4625,4672,4720,4732} -MaxEvents 100Linux triage
Separate privilege weakness from active compromise
Users and privilege
Compare user and sudo rights with the mission-approved privilege model.
getent passwd
getent group sudo
sudo -l -U alex
sudo -l -U priya
Processes and sockets
Identify active processes and listeners before disabling services.
ps aux --sort=-%cpu | head -n 30
ss -tulpn
Services and schedules
Review service state and recurring execution sources.
systemctl --type=service --state=running
systemctl list-timers --all
crontab -l
sudo crontab -l
Authentication evidence
Correlate authentication and sudo activity with process and service findings.
sudo grep -Ei "accepted|failed|sudo|session opened|session closed" /var/log/auth.log 2>/dev/null | tail -n 120
Windows Server triage
Protect required services while investigating propagation
Privileged identities
Identify approved and unexpected privileged identities without assuming domain membership.
Get-LocalGroupMember Administrators
Get-ADGroupMember "Domain Admins" -ErrorAction SilentlyContinue
Required roles and shares
Separate mission-required file services from unnecessary or suspicious roles.
Get-WindowsFeature | Where-Object {$_.InstallState -eq 'Installed'}Get-SmbShare
Get-SmbSession
Services and service-install events
Identify newly installed services and correlate them with executable paths.
Get-Service | Sort-Object Status,Name
Get-WinEvent -FilterHashtable @{LogName="System"; Id=7045} -MaxEvents 50Authentication and file access
Review logons, privileged sessions, and SMB share access.
Get-WinEvent -FilterHashtable @{LogName="Security"; Id=4624,4625,4672,5140} -MaxEvents 100Cisco triage
Use network evidence to test scope hypotheses
Interface and VLAN state
Confirm the basic Layer 2 environment remains stable before changing security policy.
show interfaces status
show vlan brief
Trunk and management path
Verify required VLANs and the management interface are still operational.
show interfaces trunk
show ip interface brief
ACL and VTY policy
Review management restrictions and ACL behavior without rewriting policy blindly.
show ip access-lists
show running-config | section line vty
Port-security evidence
Identify access-port violations or link events that may correlate with suspicious endpoint activity.
show port-security
show interfaces status err-disabled
show logging
Fictional evidence set
Correlate across systems before deciding scope
A local account named support-temp was created yesterday and added to Administrators. The mission roster does not list this account.
Triage prompt
What additional event IDs and timestamps would help determine when and by whom this privilege change occurred?
An unknown process named updater-helper.exe is running from the user's Downloads folder and owns an outbound TCP connection.
Triage prompt
What should be preserved before stopping the process?
SSH is running and listening on TCP 22 even though the mission says SSH is not required.
Triage prompt
Is this automatically the highest-priority finding? What evidence would raise or lower its priority?
alex is a member of sudo and also has a NOPASSWD rule in /etc/sudoers.d/alex-temp.
Triage prompt
Which part conflicts with the approved privilege model, and what should be documented before changing it?
A service named FileIndexHelper was installed recently from C:\Temp\fileindex.exe. The required SMB services are otherwise healthy.
Triage prompt
How would you determine whether the service is related to the workstation activity or is a separate issue?
Security logs show a successful administrative logon from WIN11-OPS shortly after support-temp was created.
Triage prompt
How does this change the importance of the workstation account finding?
The switch logs show no port-security violation on the WIN11-OPS access port, and the expected MAC address remains learned there.
Triage prompt
Which network hypothesis becomes less likely based on this evidence?
VTY access is correctly restricted to VLAN 99. No ACL counters suggest management access from the student network.
Triage prompt
Why is this important when deciding whether the incident spread through network-device management?
The service installation on SRV-FILES occurred three minutes after the administrative logon sourced from WIN11-OPS.
Triage prompt
Does timing alone prove causation? What additional evidence would make the relationship stronger?
No authentication or network evidence links UBU-DEV to either WIN11-OPS or SRV-FILES during the same time window.
Triage prompt
How should this affect the priority of the Linux findings compared with the Windows findings?
Correlation board
Ask the questions that determine scope
Which system should be investigated first?
Prefer the system with active suspicious execution, unexpected privilege, and evidence of access to another host.
What appears related?
Look for matching identities, source addresses, timestamps, executable names, hashes, service paths, or process evidence.
What may be unrelated?
A weak configuration can exist at the same time as an incident without participating in that incident.
What should be contained first?
Prioritize verified active behavior that can affect other systems while preserving evidence and required functionality.
What should wait?
Lower-risk hardening findings can wait until active execution, privilege, and propagation risks are controlled.
What proves recovery?
Re-run the same checks that revealed the problem and confirm required services still work.
Evidence notebook
Keep findings comparable across platforms
System
WIN11-OPS
Time
14:32 local
Observation
support-temp added to Administrators
Source
Local group membership + Security event
Confidence
High
Related systems
Possible link to SRV-FILES
Action
Preserve event details before removal
Verification
Privileged membership corrected; approved admins unaffected
Authorized containment examples
Contain the verified risk, not the entire environment
These commands are for the fictional authorized lab and should only be used after preserving relevant evidence.
Disable an unapproved Windows account
Use only after preserving the account, group membership, timestamps, and related security events.
Disable-LocalUser -Name support-temp
Stop a verified suspicious process
Use only after preserving process path, hash, parent, command line, and network evidence.
Stop-Process -Id <PID>
Disable an unneeded Linux service
Use only when the mission confirms SSH is not required and you have recorded current service and authentication evidence.
sudo systemctl disable --now ssh
Disable a suspicious server service
Use only after confirming the service is not required and preserving its binary path and installation evidence.
Stop-Service -Name "FileIndexHelper"
Set-Service -Name "FileIndexHelper" -StartupType Disabled
Verification
Re-check every affected platform after containment
WIN11-OPS
Unapproved privilege and verified suspicious execution are removed while Defender, Firewall, and required applications remain operational.
Get-LocalGroupMember Administrators
Get-Process | Sort-Object ProcessName
Get-NetTCPConnection | Select-Object RemoteAddress,RemotePort,State,OwningProcess
UBU-DEV
Privilege and remote-service state now match the mission without breaking required local development functionality.
getent group sudo
sudo -l -U alex
systemctl is-enabled ssh
ss -tulpn
SRV-FILES
Suspicious service activity is contained while required SMB file sharing remains available.
Get-Service
Get-SmbShare
Get-SmbSession
SW1
Required VLANs, trunks, access ports, and management restrictions remain intact.
show interfaces status
show vlan brief
show interfaces trunk
show ip access-lists
Cross-system
No new evidence shows continued propagation or persistence between the affected systems.
Re-run the exact authentication, process, service, and network checks that produced the original findings.
Reflection
Debrief the triage decisions
Why is active suspicious execution on WIN11-OPS more urgent than an unused SSH service on UBU-DEV?
How does the administrative logon from WIN11-OPS to SRV-FILES change the scope of the investigation?
Why does timing alone not prove that the workstation caused the suspicious server service installation?
What evidence would make the workstation-to-server relationship more convincing?
Why should required SMB services on SRV-FILES be preserved during containment?
Why is the switch evidence useful even though no network-device compromise was found?
How do you distinguish an incident indicator from a separate hardening issue?
What should be documented before removing support-temp from privileged access?
Completion checklist
Finish only when risk is contained and mission services still work
I ranked findings by active risk, privilege, propagation potential, and mission impact.
I preserved evidence before containment.
I identified which findings were likely related and which were probably separate.
I investigated cross-system authentication and timing.
I did not disable required services simply because they were network-facing.
I used switch evidence to test network-based hypotheses.
I contained only evidence-supported risky behavior.
I verified Windows, Linux, Server, and Cisco mission requirements after changes.
I separated confirmed facts from hypotheses in my notes.
I can explain why my triage order was efficient and defensible.