Windows
internals Most EDR detections, most ATT&CK techniques and most incident triage happen here. You do not need to write kernel drivers — you need to read a process tree, know which parent-child pairs are impossible, and understand tokens well enough to explain how one click became domain admin.

A process is a container: private virtual memory, loaded modules (DLLs), handles, and a security token. Threads execute inside it. Every process except the first has a parent, and that lineage is what EDR records.

Office spawning a shell is the canonical "impossible parent". So is w3wp.exe (IIS) spawning cmd.exe — that is a web shell. Learning ten of these pairs gets you further than any signature list.

Processes you must recognise

• SID — the real identifier for a principal, e.g. S-1-5-21-…-1103. Names are cosmetic; SIDs are what ACLs store. Well-known ones worth recognising: S-1-5-18 SYSTEM, S-1-5-32-544 Administrators, RID 500 the built-in Administrator, 512 Domain Admins.
• Access token — attached to every process: user SID, group SIDs, and privileges such as SeDebugPrivilege (read any process memory) or SeImpersonatePrivilege (the basis of the "potato" escalations).
• Integrity levels — Low / Medium / High / System. A normal admin's shell runs Medium until UAC elevation makes it High. Browsers sandbox renderers at Low.
• SYSTEM ≠ Domain Admin. SYSTEM is total power on one machine; Domain Admin is power over the directory. Attack chains are usually local privilege escalation to SYSTEM, then credential theft, then lateral movement toward the second.

# hives
HKLM  machine-wide config      HKCU  current user
HKLM\SYSTEM\CurrentControlSet\Services      services + drivers
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run   classic autorun
HKCU\...\Windows\CurrentVersion\Explorer\Shell Folders\Startup
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
                                            debugger hijack (sticky keys)

# paths that matter
C:\Windows\System32          signed OS binaries — the LOLBin pantry
C:\Users\<u>\AppData\Local\Temp   payload staging
C:\Users\<u>\AppData\Roaming     persistence, browser profiles
C:\ProgramData                   world-writable-ish, malware favourite
\\?\C:\$Recycle.Bin              hiding in plain sight

Execution from Temp, ProgramData or a user's Downloads, by an unsigned binary, is a three-signal stack that should always be worth a look.

Attackers prefer built-in, signed tools because allow-listing and reputation checks pass them. Know these on sight:

Detection approach: do not block the binaries — most break the OS. Detect anomalous invocation: certutil with a URL, regsvr32 with scrobj.dll, PowerShell with encoded commands from an Office parent, rundll32 with no arguments.

• Run/RunOnce keys — noisy but still used constantly.
• Scheduled tasks — schtasks /create; check C:\Windows\System32\Tasks for XML with odd actions.
• Services — a new service pointing at a user-writable path, or a legitimate service with its ImagePath changed.
• WMI event subscriptions — filter + consumer + binding; fileless and frequently missed by manual checks.
• Startup folder — per-user and all-users shortcuts.
• DLL search-order / side-loading — a legitimate signed EXE in a folder with a malicious DLL beside it.
• COM hijacking — HKCU CLSID entries overriding system COM objects.
• Accessibility backdoors — sethc.exe / utilman.exe replaced or IFEO-debugged.
• Boot/logon scripts, GPO — domain-wide persistence, the nastiest variety.

LSASS holds authentication material for logged-on users so they are not re-prompted: NTLM hashes, Kerberos tickets, sometimes plaintext with legacy providers. Dumping its memory is therefore the single highest-value action on a Windows host, and any process opening a handle to lsass.exe with read-memory rights deserves an alert.

• Pass-the-hash — NTLM authentication proves knowledge of the hash, not the password. Steal the hash, authenticate as the user, never crack anything.
• Pass-the-ticket / Kerberoasting — request a service ticket encrypted with a service account's password hash, crack it offline. Service accounts with weak passwords and SPNs are the classic path.
• Token impersonation — reuse a token already present on the machine rather than credentials at all.
• DPAPI — protects browser-saved passwords and cookies; SYSTEM-level access plus the master key unlocks them, which is how session-cookie theft happens post-compromise.

Defensive levers worth naming in a design review: Credential Guard (isolates LSASS secrets in VBS), Protected Process Light on LSASS, tiered administration (admins never log into workstations), LAPS for unique local admin passwords, and disabling NTLM where possible.

Logon types in event 4624 are the fastest triage field: 2 interactive, 3 network (SMB/share), 10 RemoteInteractive (RDP), 5 service, 9 new-credentials (runas /netonly — often tooling). A wave of type 3 logons from one workstation to many servers is lateral movement in one line.

# who and what
whoami /all                       SID, groups, privileges
tasklist /svc
wmic process get Name,ProcessId,ParentProcessId,CommandLine
Get-CimInstance Win32_Process | Select Name,ProcessId,ParentProcessId,CommandLine

# network → process pivot
netstat -ano | findstr ESTABLISHED
Get-NetTCPConnection -State Established | Select LocalPort,RemoteAddress,RemotePort,OwningProcess

# persistence sweep
Get-ScheduledTask | Where State -ne "Disabled" | Select TaskName,TaskPath
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
Get-CimInstance -Namespace root\subscription -Class __EventFilter
Get-Service | Where {$_.Status -eq "Running"} | Select Name,DisplayName

# signing and hashes
Get-AuthenticodeSignature C:\path\to.exe
Get-FileHash -Algorithm SHA256 C:\path\to.exe

In practice you will run most of this through SentinelOne's remote shell or its Deep Visibility queries rather than by hand — but knowing the native equivalents means you can validate what the tool tells you.

1. Remove local admin from standard users. Single biggest reduction in attack success.
2. Application control — WDAC or AppLocker in audit then enforce; blocks the unsigned-binary-from-Temp class entirely.
3. ASR rules (Defender Attack Surface Reduction) — block Office child processes, credential stealing from LSASS, executable content from mail. Deploy in audit first.
4. Credential Guard + LAPS + tiered admin — breaks the hash-reuse chain.
5. Patch cadence — 14 days for high/critical is the Cyber Essentials bar and a reasonable internal SLA.
6. Macro policy — block macros from the internet; still one of the highest-yield settings in existence.
7. Baseline to CIS Benchmarks — gives you a defensible, measurable configuration standard, and maps neatly to what auditors ask for.

Rank your detection ideas by how expensive they are for an attacker to evade — the classic pyramid: hashes are free to change, IPs and domains cheap, tools moderate, behaviours (TTPs) expensive.

# pseudo-logic that generalises well
parent IN (winword,excel,outlook,powerpnt) AND child IN (cmd,powershell,wscript,mshta)
process=powershell AND cmdline CONTAINS ANY (-enc, -w hidden, downloadstring, frombase64)
process opens HANDLE to lsass.exe WITH access 0x1010 AND process NOT IN (known_edr, taskmgr)
new_service WITH image_path NOT UNDER (C:\Windows, C:\Program Files)
schtasks CREATE WHERE task_action CONTAINS (powershell, rundll32, %temp%)

Every rule needs three things before it ships: an ATT&CK technique ID, a known false-positive list from your own estate (backup agents, RMM tools and installers cause most of them), and a documented response action. A rule with no response instruction is a rule the on-call will close as "informational".