Triage a Suspected-Compromised Windows 11 PC in 30 Minutes
Lab details
- Type
- Attack and detection
- Level
- Beginner
- Time
- 30 min
- Verified on
- Windows 11 24H2 (build 26100.2894), Hyper-V VM on an internal-only virtual switch
Before you start
- An administrator account on the machine
- Autoruns and Process Explorer from Sysinternals (free)
Tools used
- Autoruns
- Process Explorer
- Event Viewer
References
What This Is For
Someone believes a machine is compromised and you have half an hour to form a view. This is the ordered pass — the checks that pay off fastest, sequenced so that a clear finding stops you early and a clean result is actually meaningful.
It is triage, not a full forensic examination. The goal is a defensible answer to "is something wrong here, and is it serious enough to escalate", not a court exhibit.
Before You Touch Anything: Decide If This Should Be Live
One decision first, because it is irreversible.
If this machine might become a legal or HR matter, stop. Every action you take on a running system changes it — timestamps move, the page file churns, artifacts roll off. If the answer might need to hold up formally, image the disk and capture memory before you do anything else, and hand it to someone equipped for that.
For the ordinary case — a home PC after a scam call, a work laptop acting strangely — live triage is the right call, because the alternative is doing nothing. Proceed, but know that you are trading evidentiary purity for speed, and say so if anyone asks.
Do not reboot. Several of the most useful signals live in memory and in the current session's state, and a reboot discards them.
Step 1: Running processes (5 minutes)
Open Process Explorer elevated. Configure it to earn its keep:
- Options → Verify Image Signatures, then add the Verified Signer column. Unsigned processes rise to your attention immediately.
- Options → VirusTotal → Check VirusTotal.com. This sends hashes, not files, and flags known-bad binaries in seconds.
Then read the tree, looking for:
- Unsigned processes running from
AppData,Temp, orProgramData powershell.exeorcmd.exewhose parent is something that has no reason to spawn a shell — Office, a browser, orexplorer.exelaunching an encoded PowerShell command- A process with a legitimate name in the wrong place —
svchost.exenot underC:\Windows\System32, or with a parent that is notservices.exe - Any VirusTotal hit above a couple of detections
A signed process from the right path with no VirusTotal hits is almost never your problem. Spend your attention on what fails those tests.
Step 2: Persistence (8 minutes)
Open Autoruns elevated. Options → Hide Microsoft Entries and Hide Windows Entries, then Verify Image Signatures. This strips the display down to third-party autostarts, which is where persistence lives.
Work these tabs in order:
- Logon — the classic startup locations, Run keys, Startup folder
- Scheduled Tasks — see event IDs 7045 and 4698 for what makes one suspicious
- Services — anything unsigned or running from a user path
- Drivers — a short list normally; an unsigned entry here is high priority
Yellow rows are entries whose file is missing; pink rows are unsigned. An unsigned autostart running from a user directory is the single most productive finding in this whole pass. Right-click anything suspicious → Check VirusTotal, and → Jump to Entry to see exactly where it is registered.
Step 3: Network connections (5 minutes)
Back in Process Explorer, or with TCPView, look at active connections. For a machine at rest, you want to know what is talking to the internet and why.
netstat -bano | Select-String "ESTABLISHED"
-b gives the owning process, -o the PID. Cross-reference each established outbound connection against a process you can explain. A connection owned by an unsigned binary, or by an interpreter, or to a raw IP with no hostname, is worth running down.
This is a snapshot. For history, SRUM and the firewall log cover what happened before you arrived.
Step 4: Recent logons (5 minutes)
Open Event Viewer → Security, filter to event 4624, and read the recent entries for Logon Types 10 (RDP) and 2 (interactive) at times the owner was not present, or from source addresses that are not local. Then check 4720 — a user account created — which attackers add more often than people expect.
Full detail: event ID 4624 and logon types. If remote access is the specific worry, the remote-access lab is the deeper pass.
Step 5: New local accounts and admin group changes (3 minutes)
Get-LocalUser | Select-Object Name, Enabled, LastLogon
Get-LocalGroupMember -Group "Administrators"
An account the owner does not recognise, a disabled account newly enabled, or an unexpected member of Administrators is a strong signal and quick to check.
Step 6: Decide and write it down (4 minutes)
You now have enough for a call. Sort what you found into three buckets:
- Confirmed bad — a VirusTotal-flagged binary, an unsigned autostart running from
Temp, a remote logon from an address the owner does not know. One of these is enough to treat the machine as compromised. - Unexplained — something you cannot account for but cannot condemn. These are the follow-ups, using the deeper artifact labs.
- Explained — accounted for, set aside.
Write the list down now, while it is in front of you, with paths and timestamps. If this does escalate, that note is where it starts.
If You Found Something
Do not start deleting. On a live machine, removing the persistence before you understand it can leave the payload running and destroy the evidence of how it got there.
- If it might be a formal matter: stop, preserve, escalate.
- If it is a home machine to be cleaned: work through the consumer removal guide for removing malware from Windows 11, and if remote access was involved, what to do after a remote access scam.
- Either way, assume any password entered on that machine while it was compromised is now known to someone else. Change them from a different device.
If You Found Nothing
A clean pass through all six steps is a genuine result, not a failure — but state its limits. You checked the fast, high-yield locations. You did not do memory analysis, you did not examine every persistence mechanism, and the event log only reaches as far back as its retention allows. "No indicators in a 30-minute triage" is an honest and useful sentence. "The machine is definitely clean" is not one this pass can support.
Related
- Windows 11 forensic artifacts overview
- Event IDs 7045 and 4698: spotting persistence
- How to tell if a Windows 11 PC was remotely accessed
FAQ
Should I disconnect the machine from the internet first?
If something appears to be actively communicating or exfiltrating, yes — pull the network to stop it, then triage. If you are doing a precautionary check with no active indicator, staying connected lets you use VirusTotal lookups and see live connections, which is worth more during triage. Do not reboot either way; a reboot discards memory-resident evidence.
Is 30 minutes really enough to know?
It is enough to know whether there are obvious indicators, which resolves the large majority of "is my PC hacked" cases either way. It is not enough to prove a machine is clean — that requires memory analysis, full artifact review, and a known-good baseline. Triage narrows the question and tells you whether to escalate; it does not close it.
Can I run these tools on a machine that is not mine?
For a machine you have been asked to examine by its owner or your employer, yes — this is read-only defensive analysis. If the machine could become an HR, legal, or law-enforcement matter, do not run live tools on it: image it and hand it to someone qualified, because every action here alters the evidence.
What if I do not have the tools installed and cannot download them on the machine?
Download the Sysinternals tools on a clean machine and bring them on a USB stick — they need no installation and run from anywhere. Avoid downloading tools onto the machine you are investigating: it adds your own activity to the timeline you are trying to read, and a compromised machine is not one you want to browse the internet from.
Related labs
Windows 11 Forensic Artifacts: Where Evidence of Program Execution Lives
Windows records that a program ran in at least six separate places, and they do not agree with each other. Here is what each artifact actually proves on Windows 11, and which one to trust.
ShimCache vs Amcache vs Prefetch: Which One Proves Execution?
Three Windows artifacts get treated as interchangeable evidence that a program ran. Only one of them actually proves it. Here is what each records on Windows 11 and how to read them together.
Prefetch Files on Windows 11: Proving a Program Ran, and When
A .pf file records how many times a program ran and the last eight times it happened. Here is how to read Prefetch on Windows 11, and the three ways the evidence misleads you.
Amcache.hve on Windows 11: What It Records and How to Read It
Amcache stores the SHA-1 of executables Windows has encountered — including ones already deleted. Here is how to parse it on Windows 11 and what its entries do and do not prove.