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

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, or ProgramData
  • powershell.exe or cmd.exe whose parent is something that has no reason to spawn a shell — Office, a browser, or explorer.exe launching an encoded PowerShell command
  • A process with a legitimate name in the wrong place — svchost.exe not under C:\Windows\System32, or with a parent that is not services.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

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.