Lab OS.2 — Registry & File System Hunt

Lab Overview

The Scenario

Following your process analysis in Lab OS.1, the incident response team confirmed a C2 beacon on the Windows server. The beacon has been contained, but leadership wants to know: "What else did the attacker leave behind? Will they get back in after we clean the beacon?"

Your mission is to hunt the endpoint's registry and file system for persistence mechanisms. The attacker had enough time to establish multiple footholds — your job is to find them all. The same Velociraptor-connected endpoint from Lab OS.1 is still available, and the planted artifacts include registry autorun entries, suspicious files in web directories, and more.

Part 1: Understanding Persistence Locations

Before hunting, you need to know where to look. Windows offers dozens of persistence mechanisms. The most common ones used by real attackers are:

Registry Autorun Keys

File System Locations

Part 2: Registry Hunt — Autorun Keys

Step 1 — Collect Registry Run Keys

In the Velociraptor client view, click New Collection and search for:

Windows.Sys.StartupItems

This artifact collects entries from all common autorun locations — Run, RunOnce, Startup folders, and more. Launch the collection and wait for completion.

Step 2 — Analyze the Results

Review every entry in the results table. For each entry, evaluate:

1. Name: Does the entry name look legitimate? (e.g., "SecurityHealth" is a real Windows Defender entry; "SystemUpdate" or a random string is suspicious)
2. Command/Path: Does the executable path point to a standard location (C:\Windows, C:\Program Files) or a user-writable directory?
3. Location: Which registry key or startup folder contains the entry?

Document every entry in your report using this template:

AUTORUN ENTRY ANALYSIS
─────────────────────
Name:      [entry name]
Location:  [registry key or folder path]
Command:   [full command/path to executable]
Verdict:   LEGITIMATE / SUSPICIOUS / MALICIOUS
Reason:    [why you classified it this way]
ATT&CK:   [technique ID if malicious]

Step 3 — Deep Dive into HKLM Run Key

For a more targeted collection, run:

Windows.Registry.ValueQuery

Configure the parameters:

• Key: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\*

This returns every value under the HKLM Run key with full detail including the data type, value data, and last modified timestamp. Compare results against Step 2 to ensure nothing was missed.

Click to enlarge

Part 3: Registry Hunt — Services

Step 4 — Enumerate Installed Services

Attackers frequently register malware as a Windows service for persistent, automatic execution. Collect:

Windows.System.Services

This artifact enumerates all registered services. The result set will be large (100+ services on a typical system). Focus your analysis on:

Step 5 — Identify the Suspicious Service

Find the service entry that doesn't belong. Record:

SUSPICIOUS SERVICE
──────────────────
Service Name:  [name]
Display Name:  [display name]
Binary Path:   [path to executable]
Start Type:    [Auto/Manual/Disabled]
Account:       [LocalSystem/LocalService/specific user]
Description:   [description or blank]
State:         [Running/Stopped]
ATT&CK:       T1543.003 (Create or Modify System Process: Windows Service)

Part 4: File System Hunt — Web Shell

Step 6 — Scan the IIS Web Root

Web shells are one of the most common persistence mechanisms for attackers who compromised a system through a web application. Search the IIS web root:

Windows.Search.FileFinder

Configure the parameters:

• SearchFilesGlob: C:\inetpub\wwwroot\**

Review every file in the results. A legitimate IIS deployment will contain:

• .html, .css, .js files
• web.config (IIS configuration)
• Application-specific files

Look for files that don't belong:

• .aspx files with generic names (cmd.aspx, shell.aspx, upload.aspx, test.aspx)
• Files with recent modification timestamps that don't match the application deployment
• Very small files (webshells are typically <10KB) with suspicious names

Step 7 — Examine the Webshell Content

Once you identify the suspicious file, collect its content. You can use:

Windows.Search.FileFinder

With the accessor set to include file content for the specific suspicious file. Alternatively, use:

Windows.NTFS.MFT

To get the MFT entry for the file, including the exact creation and modification timestamps (which may differ from what the standard API reports — a sign of timestamp manipulation).

Document the webshell:

WEBSHELL DETECTED
─────────────────
File Path:    [full path]
File Size:    [bytes]
Created:      [timestamp]
Modified:     [timestamp]
Hash (SHA256):[hash value]
Type:         [ASPX/PHP/JSP]
Capability:   [command execution / file upload / both]
ATT&CK:      T1505.003 (Server Software Component: Web Shell)

Part 5: File System Hunt — Temp and Staging Directories

Step 8 — Scan Temp Directories

Attackers use temp directories as staging areas for downloaded tools, exfiltrated data, and intermediate payloads. Search:

Windows.Search.FileFinder

Configure the parameters:

• SearchFilesGlob: C:\Windows\Temp\**

Then also scan user temp:

• SearchFilesGlob: C:\Users\*\AppData\Local\Temp\**

For each suspicious file found, record:

• Filename and extension
• File size
• Creation and modification timestamps
• SHA256 hash

Step 9 — Scan Startup Folders

Check both the all-users and per-user startup folders:

• C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\*
• C:\Users\*\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\*

Any executable (.exe, .bat, .vbs, .ps1, .lnk) in these folders runs at user logon.

Click to enlarge

Part 6: Build Your Persistence Hunt Report

Compile all discoveries into a structured report:

PERSISTENCE HUNT REPORT
═══════════════════════
Endpoint:     [hostname]
Client ID:    [Velociraptor client ID]
Date:         [today's date]
Analyst:      [your name]
Related To:   Lab OS.1 Process Baseline findings

PERSISTENCE MECHANISMS FOUND
────────────────────────────

1. Registry Run Key Entry
   Location:  [registry path]
   Value:     [entry name]
   Data:      [command/path]
   ATT&CK:   T1547.001

2. Suspicious Windows Service
   Name:      [service name]
   Binary:    [path]
   Start:     [Auto]
   ATT&CK:   T1543.003

3. Web Shell
   Path:      [full file path]
   Type:      [ASPX]
   Hash:      [SHA256]
   ATT&CK:   T1505.003

4. [Any additional findings from Temp/Startup scans]

INDICATORS OF COMPROMISE
─────────────────────────
Files:
  - [path 1] (SHA256: [hash])
  - [path 2] (SHA256: [hash])
  - [path 3] (SHA256: [hash])

Registry:
  - [key path] = [value]

Network:
  - [C2 IP from Lab OS.1]

ATT&CK MAPPING
───────────────
T1547.001 — Boot or Logon Autostart: Registry Run Keys
T1543.003 — Create or Modify System Process: Windows Service
T1505.003 — Server Software Component: Web Shell
T1074.001 — Data Staged: Local Data Staging

REMEDIATION STEPS
─────────────────
1. Delete malicious registry Run key entry
2. Stop and remove the suspicious service
3. Delete the webshell from the IIS webroot
4. Remove all staged files from Temp directories
5. Reset all credentials (attacker had system-level access)
6. Rebuild the server from a known-good image

Deliverable Checklist

Before completing the lab, ensure you have:

• Registry Autorun Analysis — All Run/RunOnce entries documented with verdicts
• Service Enumeration — Suspicious service identified with binary path and start type
• Webshell Detection — Suspicious file in IIS webroot identified with hash and capability assessment
• Temp Directory Scan — Staging artifacts documented with timestamps and hashes
• Startup Folder Check — Both all-users and per-user startup folders scanned
• Persistence Hunt Report — Complete report with ATT&CK mappings and IOCs

What's Next

In Lab OS.3 — Event Log Deep Dive, you'll shift from endpoint artifact collection to Windows Event Log analysis. Using the Wazuh Dashboard with 505 pre-loaded alerts, you'll explore Event IDs 4624/4625/4688/7045/1102, correlate events across log channels, and build an Event Log Investigation Matrix connecting the logs to the multi-stage attack you've been uncovering.