Whisper

Investigating unauthorized offensive activity on a corporate workstation through registry forensics, prefetch analysis, browser history, and event log correlation.

Review

Summary

On 21st January 2025, the SOC receives an alert about suspicious activity from an employee's workstation. Alpha is not authorized to perform offensive activity on the network. The IR team isolates the system and collects a Windows triage package: registry hives, prefetch files, an MFT with USN Journal, Edge browser history, and Security event logs.

The SYSTEM registry hive identifies the machine and its network configuration. Prefetch files show mimikatz on disk and confirm it executes within roughly 90 seconds of download, establishing credential extraction activity. Edge browser history places the attacker on mega.nz downloading a PowerShell script for domain controller enumeration. The attacker then deletes the script to clean up, but the NTFS USN Journal records the deletion with a precise timestamp. Shellbag artifacts in the user registry show navigation into a network share on the CYBERUP domain controller, where the attacker accesses a sensitive document. Security event log Event ID 4720 records the creation of a local backdoor account named "Admin", though it sees zero logons.

Recovering the backdoor account password requires stepping outside traditional DFIR tooling. The SAM registry hive holds NTLM password hashes that secretsdump.py extracts when paired with the SYSTEM hive. Cracking with hashcat against rockyou.txt completes the picture. The investigation spans seven distinct artifact types and demands both defensive analysis skills and offensive knowledge of credential extraction to fully resolve.

Key Learning Takeaways

Investigation

Artifact Triage

The evidence package contained a Windows system triage with the following key artifacts:

System Identification

Hostname (Q1)

The Windows SYSTEM registry hive stores hardware configuration, boot parameters, and service settings that persist across reboots. The hostname is stored at ControlSet001\Control\ComputerName\ComputerName because Windows needs a persistent machine identifier for networking and domain operations. This is typically the first artifact to check during any Windows triage to confirm you are analyzing the correct system.

$ RECmd.exe -f SYSTEM --kn "ControlSet001\Control\ComputerName\ComputerName"

Key: ControlSet001\Control\ComputerName\ComputerName

Values:
  ComputerName : HELPDESK (RegSz)

The hostname HELPDESK indicates this is likely a support workstation, which aligns with the scenario of an employee (Alpha) using it for unauthorized offensive activity. In enterprise environments, hostnames often follow naming conventions that reveal the machine's role.

IP Address (Q2)

Windows stores network adapter configuration under SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfaces\, with each network adapter identified by a GUID subfolder. When DHCP is used, the DhcpIPAddress value records the IP address assigned by the DHCP server. This is the most reliable registry location for determining a machine's IP address at the time of imaging, because it persists even after the machine is powered off.

$ RECmd.exe -f SYSTEM --kn "ControlSet001\Services\Tcpip\Parameters\Interfaces" --recurse --nl

Key: ControlSet001\Services\Tcpip\Parameters\Interfaces\{b1bb5088-94e0-4459-8b75-b2a0ec1b96cc}

Values:
  DhcpIPAddress : 192.168.159.199 (RegSz)
  DhcpSubnetMask : 255.255.255.0 (RegSz)
  DhcpServer : 192.168.159.254 (RegSz)

The address 192.168.159.199 places this machine on a private Class C subnet, consistent with a corporate LAN. This IP will be useful for correlating network activity if packet captures or firewall logs are available.

Computer SID (Q3)

Every Windows machine has a unique Security Identifier (SID) that forms the base of all local user SIDs. A SID follows the format S-1-5-21-X-Y-Z where X, Y, Z are sub-authority values unique to the machine. Individual user accounts append a Relative Identifier (RID) to this base, such as -500 for the built-in Administrator or -1001 for the first created user. The machine SID itself is the SID without the final RID component.

By examining user account SIDs in the SAM hive (e.g., the Administrator account SID ending in -500), we can strip the RID to derive the machine SID.

Timezone (Q4)

Establishing the system timezone is critical before analyzing any timestamps. Windows stores the configured timezone at SYSTEM\CurrentControlSet\Control\TimeZoneInformation under the TimeZoneKeyName value. This tells you how to interpret any timestamps that are stored in local time rather than UTC, and helps correlate events across systems in different timezones.

$ RECmd.exe -f SYSTEM --kn "ControlSet001\Control\TimeZoneInformation"

Key: ControlSet001\Control\TimeZoneInformation

Values:
  TimeZoneKeyName : Pacific Standard Time (RegSz)
  ActiveTimeBias : 480 (RegDword)
  Bias : 480 (RegDword)

Pacific Standard Time (UTC-8) tells us this machine was configured for the US West Coast. Most forensic tools like MFTECmd and PECmd output in UTC by default, but some artifacts (like certain event log fields and user-facing timestamps) may reflect local time. Knowing the offset prevents timeline errors.

Attack Timeline Reconstruction

Credential Extraction Tool (Q5, Q6, Q7)

Windows Prefetch is a performance optimization feature that creates .pf files in C:\Windows\Prefetch\ every time a program executes. Each prefetch file records the executable name, run count, last execution timestamps (up to 8 on Windows 10+), and the files/directories accessed during execution. This makes Prefetch one of the most valuable artifacts for proving program execution in forensic investigations.

Prefetch filenames follow the format EXENAME.EXE-HASHVALUE.pf, where the hash is derived from the executable path. If the same executable runs from different paths, it generates separate prefetch files with different hashes. Two prefetch files for mimikatz (different hashes) suggests it was executed from two different locations on disk.

$ PECmd.exe -f "C:\Windows\Prefetch\MIMIKATZ.EXE-7A038744.pf"

Executable: MIMIKATZ.EXE
Hash: 7A038744
Run count: 2
Last run: 2025-01-21 00:21:41

Volume 0: C:\
  Created: 2025-01-15 08:23:41
  Serial: 1234-ABCD

Directories referenced: 23
Files referenced: 42

$ PECmd.exe -f "C:\Windows\Prefetch\MIMIKATZ.EXE-D870B873.pf"

Executable: MIMIKATZ.EXE
Hash: D870B873
Run count: 1
Last run: 2025-01-21 00:20:42

Two prefetch files with different path hashes confirm mimikatz was run from two locations. The MFT creation timestamp (via MFTECmd) shows the file first appeared on disk at 00:20:15 UTC.

$ MFTECmd.exe -f "$MFT" --csv output\ --csvf mft.csv

# Filter in Timeline Explorer for MIMIKATZ.EXE:
FileName: MIMIKATZ.EXE
Created0x10: 2025-01-21 00:20:15
LastModified0x10: 2025-01-21 00:21:41

The prefetch data confirms mimikatz.exe was last executed at 00:21:41 UTC on January 21, 2025. The MFT creation timestamp of 00:20:15 shows when the file first appeared on disk, meaning the attacker downloaded and ran mimikatz within about 90 seconds.

DC Scanning Script (Q8, Q9, Q10)

Microsoft Edge (Chromium-based) stores browsing history in a SQLite database called History located at C:\Users\[username]\AppData\Local\Microsoft\Edge\User Data\Default\History. The urls table records every visited URL with timestamps, and the downloads table tracks file downloads. Like all Chromium browsers, Edge stores timestamps in microseconds since the Windows epoch (January 1, 1601), which requires conversion: datetime(timestamp/1000000-11644473600, 'unixepoch').

$ sqlite3 "C:\Users\Alpha\AppData\Local\Microsoft\Edge\User Data\Default\History" \
  "SELECT url, datetime(last_visit_time/1000000-11644473600,'unixepoch') as visit_time FROM urls ORDER BY last_visit_time DESC;"

https://mega.nz/file/I31zBZTb#H5aUJamEj2xMroi9baoTKCMjQF1jiV8TK9gbjoNGgkw|2025-01-21 01:00:12
https://mega.nz|2025-01-21 00:59:45
https://www.google.com|2025-01-21 00:58:30

$ sqlite3 "C:\Users\Alpha\AppData\Local\Microsoft\Edge\User Data\Default\History" \
  "SELECT current_path, tab_url FROM downloads;"

C:\Users\Alpha\Downloads\DC-Scan.ps1|https://mega.nz/file/I31zBZTb#H5aUJamEj2xMroi9baoTKCMjQF1jiV8TK9gbjoNGgkw

The browser history reveals the attacker visited mega.nz to download a PowerShell script called DC-Scan.ps1. Mega.nz is a common file-sharing platform that attackers use because it offers encrypted storage and does not require authentication to download shared files.

To find when the script was deleted, we turn to the NTFS USN (Update Sequence Number) Journal. The USN Journal, stored as $Extend\$J, is a system-level change log that records every file system operation: creates, deletes, renames, attribute changes, and data modifications. Even when an attacker deletes a file, the deletion event itself is recorded in the journal with a timestamp. This makes the USN Journal invaluable for tracking file lifecycle events that the attacker tried to hide.

$ MFTECmd.exe -f "$J" --csv output\ --csvf usn_journal.csv

MFTECmd version 1.2.2.0
Processing $J...
Processed 148,293 records in 3.2 seconds

# Filter CSV for DC-Scan.ps1 with FILE_DELETE reason:
$ Select-String -Path output\usn_journal.csv -Pattern "DC-Scan.ps1"

UpdateTimestamp: 2025-01-21 01:27:47
FileName: DC-Scan.ps1
UpdateReasons: FILE_DELETE|CLOSE
ParentPath: C:\Users\Alpha\Downloads

The attacker deleted the DC scanning script approximately 27 minutes after it was downloaded, likely as an anti-forensics measure. However, the USN Journal preserved the deletion event with its exact timestamp.

Shared File Access (Q11)

Windows Shellbags are registry artifacts that record every folder a user has browsed in Windows Explorer, including network shares. They are stored in NTUSER.DAT and UsrClass.dat under the BagMRU and Bags keys. Shellbags persist even after the folders themselves are no longer accessible, making them excellent evidence of lateral movement and network share access in incident response.

Using Shellbag Explorer on the user's NTUSER.DAT, I reconstructed the folder navigation path and found evidence of network share access. The attacker browsed into a remote share on the CYBERUP domain controller, navigating through the Administrator's Desktop to a folder named "Top-Secret."

This confirms the attacker moved laterally from the HELPDESK system to the domain controller's file shares, accessing sensitive documents that should have been restricted.

Persistence Analysis

New User Account (Q12, Q13)

Creating a local user account is a common persistence technique (MITRE ATT&CK T1136.001). Windows logs account creation events in the Security event log as Event ID 4720. This event captures the new account name, its SID, and which account performed the creation. It is one of the most reliable indicators of persistence because Windows always logs it when auditing is enabled, and attackers cannot easily suppress it without clearing the entire event log.

PS> Get-WinEvent -Path .\Security.evtx -FilterXPath "*[System[EventID=4720]]" |
  Select-Object TimeCreated, @{N='TargetUser';E={$_.Properties[0].Value}},
  @{N='TargetSid';E={$_.Properties[2].Value}},
  @{N='SubjectUser';E={$_.Properties[4].Value}} | Format-List

TimeCreated : 2025-01-21 01:02:00
TargetUser  : Admin
TargetSid   : S-1-5-21-953115734-2025219997-3674921352-1002
SubjectUser : Administrator

The event shows a new account named "Admin" (RID 1002) was created by a domain Administrator. The choice of "Admin" as the account name is a social engineering tactic that blends in with legitimate administrative accounts and is less likely to be noticed during a cursory review.

To determine if the attacker actually used this account, I searched for Event ID 4624 (successful logon) events matching this SID. No logon events were found, indicating the account was created as a dormant backdoor for future access rather than for immediate use.

Password Recovery (Critical Technique)

The Wrong Approach (What I Tried)

• Searched PSReadline history - found "P@ssw0rd" for user "newadmin" (different user!)
• Searched PowerShell logs - no password found
• Searched process creation events - command line logging not enabled
• Searched registry for password hints - nothing useful

The Correct Approach

Windows stores user password hashes in the SAM (Security Account Manager) registry hive. The hashes are encrypted with a boot key stored in the SYSTEM hive, so you need both files to extract them. Impacket's secretsdump.py automates this process: it reads the boot key from SYSTEM, decrypts the SAM, and outputs NTLM hashes in the standard username:RID:LM_hash:NT_hash format. Once extracted, the NTLM hash can be cracked with hashcat using mode 1000.

$ secretsdump.py -sam SAM -system SYSTEM LOCAL

# Output:
[*] Target system bootKey: 0x9284***b3b1
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3***4ee:31d6***9c0:::
Guest:501:aad3***4ee:31d6***9c0:::
DefaultAccount:503:aad3***4ee:31d6***9c0:::
WDAGUtilityAccount:504:aad3***4ee:2e89***ec6:::
A7md-NaS3eR:1001:aad3***4ee:b202***547:::
Admin:1002:aad3***4ee:58a4***b71:::

$ echo "58a4***b71" > hash.txt
$ hashcat -m 1000 hash.txt rockyou.txt

# Result:
58a4***b71:Pa*****23

# Password recovered!

Answer Summary

Attack Chain Timeline

Additional Resources

Techniques

Tools