# Triage a Suspected-Compromised Windows 11 PC in 30 Minutes URL: https://www.mytechnician.tech/labs/triage-compromised-windows-11-pc-30-minutes/ Published: 2026-08-08 | Author: Ankit Kumar Track: Attack and detection | Difficulty: Beginner | Authorization: defensive Time required: 30 min Verified on: Windows 11 24H2 (build 26100.2894), Hyper-V VM on an internal-only virtual switch MITRE ATT&CK: T1057, T1543 Tags: Detection, Forensics, Persistence, Windows 11 Summary: A fast, ordered pass over a Windows 11 machine you think is compromised, using only free tools. What to check, in what sequence, and how to tell a real finding from normal noise. ## 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](https://www.mytechnician.tech/labs/event-ids-7045-4698-service-scheduled-task-persistence/) 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](https://www.mytechnician.tech/labs/srum-srudb-dat-windows-11-forensics/) and [the firewall log](https://www.mytechnician.tech/labs/read-windows-firewall-log-pfirewall-windows-11/) 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](https://www.mytechnician.tech/labs/event-id-4624-logon-types-windows/). If remote access is the specific worry, [the remote-access lab](https://www.mytechnician.tech/labs/detect-remote-access-windows-11-rdp-teamviewer-anydesk/) 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](https://www.mytechnician.tech/tips/remove-virus-malware-windows-11/), and if remote access was involved, [what to do after a remote access scam](https://www.mytechnician.tech/tips/what-to-do-after-remote-access-scam-anydesk-teamviewer/). - 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](https://www.mytechnician.tech/labs/windows-11-forensic-artifacts-program-execution/) - [Event IDs 7045 and 4698: spotting persistence](https://www.mytechnician.tech/labs/event-ids-7045-4698-service-scheduled-task-persistence/) - [How to tell if a Windows 11 PC was remotely accessed](https://www.mytechnician.tech/labs/detect-remote-access-windows-11-rdp-teamviewer-anydesk/) ## 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. --- Source: https://www.mytechnician.tech/labs/triage-compromised-windows-11-pc-30-minutes/ — My Technician Security Labs. Authorization: defensive. This write-up is published for defensive and educational use on systems you own or are authorized to test. More labs: https://www.mytechnician.tech/labs/