Post cover image

September 20, 2026

TryHackMe — The Clean Exit

1. Executive Summary

By oiho

7 min read

1. Executive Summary

The investigation identified a sequence of suspicious activity performed from Turner's workstation on 12 July 2026.

The evidence shows that Turner connected a removable storage device labeled PERSONAL_BACKUP, executed exfiltool.exe, attempted to transfer FinanceDocs.zip to the external domain evil-external.thm, then accessed the internal system GTM-JUMP-01 and interacted with the hidden SMB share \\192.168.86.172\Staging$.

ShellBag evidence showed Turner browsing the restricted finance directory VendorContracts_Q3, with the last recorded interaction at 18:17:30.

The cleanup phase occurred shortly afterward. NTFS USN Journal evidence showed the Windows Firewall event log being overwritten and truncated at 18:21:40, consistent with Event Log clearing rather than a normal filesystem FileDelete. Execution evidence for wevtutil.exe during the same time window supports intentional anti-forensic activity.

The investigation therefore reconstructs the following high-level chain:

Removable storage connected
        ↓
exfiltool.exe executed
        ↓
Direct exfiltration attempted
        ↓
BITS transfer attempted to evil-external.thm
        ↓
FinanceDocs.zip identified
        ↓
RDP access to GTM-JUMP-01
        ↓
Restricted finance folder browsed
        ↓
Archive moved to \\192.168.86.172\Staging$
        ↓
Windows logs cleared / truncated

2. Primary Findings

None

3. Investigation Methodology

The analysis followed a forensic workflow rather than treating each question as an isolated flag hunt.

Observe
→ Identify the behavior to prove
→ Select the most relevant artifact
→ Query the artifact
→ Validate the result
→ Correlate independent artifacts
→ Build the timeline
→ State only what the evidence supports

The key principle throughout the investigation was:

Artifact selection must follow the investigative question.

Examples:

Device connection
→ Registry + Partition Diagnostic logs
​
Program execution
→ BAM / Prefetch
​
Background transfer
→ BITS Operational log
​
User folder interaction
→ ShellBags
​
RDP destination
→ Terminal Server Client registry
​
Filesystem deletion/truncation
→ USN Journal
​
Log clearing
→ USN Journal + execution artifacts

4. Finding 1 — Removable Storage Serial Number

Question

A storage device was connected to Turner's workstation on the day of the incident. What is its serial number?

Answer

MSFT300123456789ABCDEF

Evidence Strategy

A useful source for storage attachment activity is:

Microsoft-Windows-Partition/Diagnostic

The collected event log was:

C:\Users\DFIRUser\Kape-Collection\WKS-07\C\Windows\System32\winevt\logs\Microsoft-Windows-Partition%4Diagnostic.evtx

Because normal message rendering was unavailable, the event XML was more useful than the Message property.

Example enumeration:

$partitionLog = 'C:\Users\DFIRUser\Kape-Collection\WKS-07\C\Windows\System32\winevt\logs\Microsoft-Windows-Partition%4Diagnostic.evtx'
​
Get-WinEvent -Path $partitionLog |
Where-Object {
    $_.Id -eq 1006
} |
ForEach-Object {
    [xml]$xml = $_.ToXml()
    $xml.Event.EventData.Data
}

Relevant information included:

Manufacturer: JMicron
Model: Generic
Storage SerialNumber: 0123456789ABCDEF
​
ParentId:
USB\VID_152D&PID_0578\MSFT300123456789ABCDEF

Interpretation

There were two different identifiers:

Storage-layer SerialNumber
→ 0123456789ABCDEF
USB Device Instance identity
→ MSFT300123456789ABCDEF

The challenge expected the final component of the USB Device Instance ID:

MSFT300123456789ABCDEF

This distinction matters because USB-to-SATA/UASP bridge devices can expose different identifiers at different layers.

5. Finding 2 — Removable Storage Name

Question

What was the name of the storage device Turner connected with the workstation?

Answer

PERSONAL_BACKUP

Evidence Strategy

The hardware identity does not necessarily provide the user-visible storage name. Windows volume metadata was therefore examined.

The device was correlated to:

E:\

The relevant registry location was:

HKLM\TurnerSOFTWARE\Microsoft\Windows Search\VolumeInfoCache

Example query:

reg query "HKLM\TurnerSOFTWARE\Microsoft\Windows Search\VolumeInfoCache" /s |
Select-String "VolumeLabel|E:\\"

Relevant result:

VolumeLabel    REG_SZ    PERSONAL_BACKUP

Interpretation

Do not confuse:

USB device identity
→ MSFT300123456789ABCDEF
Hardware model
→ JMicron Generic
Drive letter
→ E:
Volume label
→ PERSONAL_BACKUP

The requested device name was the volume label:

PERSONAL_BACKUP

6. Finding 3 — Suspicious Executable

Question

An executable was run on Turner's workstation on the same day. Its name clearly reflects the intent behind running it. What is its name?

Answer

exfiltool.exe

Evidence Strategy

Prefetch was inspected first, but absence of a Prefetch entry does not prove absence of execution.

The investigation therefore pivoted to BAM.

Relevant registry location:

HKLM\TurnerSYSTEM\ControlSet001\Services\bam\State\UserSettings

Example command:

reg query "HKLM\TurnerSYSTEM\ControlSet001\Services\bam\State\UserSettings" /s

Relevant BAM value:

\Device\HarddiskVolume7\Tools\exfiltool.exe

The BAM timestamp decoded to approximately:

2026-07-12 18:06:54

Correlation

ShellBag evidence showed Turner interacting with:

E:\Tools

at approximately:

18:06:28

The combined evidence supports:

E:\Tools
    ↓
exfiltool.exe
    ↓
execution around 18:06:54

7. Finding 4 — BITS Transfer Target

Question

The first attempt failed. Turner then used a Windows-native background transfer mechanism to try again. What domain was he targeting?

Answer

evil-external.thm

Evidence Strategy

The phrase "Windows-native background transfer mechanism" points to:

BITS
Background Intelligent Transfer Service

Relevant log:

Microsoft-Windows-Bits-Client%4Operational.evtx

Example extraction:

$bits = 'C:\Users\DFIRUser\Kape-Collection\WKS-07\C\Windows\System32\winevt\Logs\Microsoft-Windows-Bits-Client%4Operational.evtx'
Get-WinEvent -Path $bits |
ForEach-Object {
    $xml = $_.ToXml()
    if ($xml -match 'https?://[^<"]+') {
        [pscustomobject]@{
            TimeCreated = $_.TimeCreated
            EventId     = $_.Id
            URL         = $matches[0]
        }
    }
}

Relevant URL:

https://evil-external.thm/upload/FinanceDocs.zip

Therefore the target domain was:

evil-external.thm

8. Finding 5 — Archive Name

Question

What was the name of the archive Turner prepared to send to that domain?

Answer

FinanceDocs.zip

Evidence

The archive name was visible directly in the BITS transfer URL:

https://evil-external.thm/upload/FinanceDocs.zip

The URL decomposes as:

Scheme:
https
Host:
evil-external.thm
Path:
/upload/FinanceDocs.zip
Filename:
FinanceDocs.zip

One artifact therefore answered both the destination-domain and archive-name questions.

9. Finding 6 — Internal System Accessed

Question

Both direct transfer attempts from the workstation failed. Turner then accessed another internal system before moving the data. What is the name of that system?

Answer

GTM-JUMP-01

Evidence Strategy

BAM showed execution of:

mstsc.exe

which is the Microsoft Remote Desktop Connection client.

Relevant registry locations:

HKU\TurnerUser\Software\Microsoft\Terminal Server Client\Default
HKU\TurnerUser\Software\Microsoft\Terminal Server Client\Servers

Example queries:

reg query "HKU\TurnerUser\Software\Microsoft\Terminal Server Client\Default" /s
reg query "HKU\TurnerUser\Software\Microsoft\Terminal Server Client\Servers" /s

These keys contain recent RDP destinations and related metadata.

The investigation identified:

GTM-JUMP-01

as the internal system accessed by Turner.

Network Correlation

ShellBag evidence later showed interaction with:

192.168.86.172

which is consistent with the internal staging phase.

10. Finding 7 — Restricted Finance Folder

Question

The client reported that vendor contracts are missing. Turner browsed the finance directory locally before removing it. What was the name of the folder containing those contracts?

Answer

VendorContracts_Q3

Evidence Strategy

ShellBags are useful for determining folders a user browsed through Windows Explorer.

Relevant user artifact:

C:\Users\DFIRUser\Kape-Collection\WKS-07\C\Users\aturner\AppData\Local\Microsoft\Windows\UsrClass.dat

The ShellBag path reconstructed:

Desktop
└── My Computer
    └── C:
        └── FinanceDocs
            └── Archive
                └── VendorContracts_Q3

Relevant folder:

C:\FinanceDocs\Archive\VendorContracts_Q3

The record showed:

ShellType: Directory
Value: VendorContracts_Q3
HasExplored: True

This directly supports user interaction with the restricted folder.

11. Finding 8 — Last Interaction Time

Question

What was the last interaction time of that restricted folder that Turner accessed?

Answer

18:17:30

Evidence

The ShellBag record for:

C:\FinanceDocs\Archive\VendorContracts_Q3

contained:

FirstInteracted:
2026-07-12 18:17:30
LastInteracted:
2026-07-12 18:17:30

The required answer was therefore:

18:17:30

Interpretation

Do not confuse:

NTFS AccessedOn

with:

ShellBag LastInteracted

The question concerns user interaction with the folder, so the ShellBag interaction field is the relevant evidence.

12. Finding 9 — Internal Staging Location

Question

Turner successfully moved the archive to the internal system he accessed. What was the full path of the location he copied it to?

Answer

\\192.168.86.172\Staging$

Evidence Strategy

ShellBags showed network browsing activity involving:

192.168.86.172

and the hidden SMB share:

\\192.168.86.172\Staging$

Relevant structure:

Desktop
└── Computers and Devices
    └── 192.168.86.172
        └── Staging$

Interaction time:

2026-07-12 18:14:30

Interpretation

The $ suffix denotes a hidden SMB share:

Staging$

The correct UNC path was:

\\192.168.86.172\Staging$

Evidence Discipline

ShellBags prove that Turner browsed the network location.

The challenge context establishes that the archive was successfully moved there.

Therefore:

Challenge context
→ copy succeeded
ShellBag evidence
→ destination location identified

ShellBags alone should not be overstated as direct proof of a file copy operation.

13. Finding 10 — Firewall Log Clearing

Question

Turner deleted several files to cover his tracks. When was the firewall log deleted?

Answer

06:21:40 PM

Initial Hypothesis — Security Event Log

The first hypothesis was to search for file deletion auditing.

Relevant events include:

4656
4659
4660
4663

The query was:

$sec = 'C:\Users\DFIRUser\Kape-Collection\WKS-07\C\Windows\System32\winevt\Logs\Security.evtx'
Get-WinEvent -Path $sec |
Where-Object {
    $_.Id -in 4656,4659,4660,4663
} |
Where-Object {
    $_.Message -match 'pfirewall|Firewall'
} |
Select-Object TimeCreated,Id,Message |
Format-List

No useful result was returned.

This did not prove that the activity did not occur. Possible explanations included:

File System Auditing not enabled
SACL not configured
Security log already cleared
Operation was log clearing rather than file deletion

The investigation therefore pivoted to the NTFS USN Journal.

14. Parsing the NTFS USN Journal

The journal was located at:

C:\Users\DFIRUser\Kape-Collection\WKS-07\C\$Extend\$J

PowerShell Path Handling

This is unsafe:

$j = "C:\Users\DFIRUser\Kape-Collection\WKS-07\C\$Extend\$J"

because PowerShell attempts to expand:

$Extend
$J

Use a literal single-quoted string:

$j = 'C:\Users\DFIRUser\Kape-Collection\WKS-07\C\$Extend\$J'

Verify:

Test-Path $j

Expected:

True

Parse With MFTECmd

$mfte = 'C:\Users\DFIRUser\DFIR Tools\EZ Tools\MFTECmd.exe'
$out = 'C:\Users\DFIRUser\Desktop\USNOut'
New-Item -ItemType Directory -Path $out -Force | Out-Null
& $mfte `
-f $j `
--csv $out `
--csvf 'usn.csv'

Search for firewall-related changes:

Import-Csv "$out\usn.csv" |
Where-Object {
    ($_ | Out-String) -match 'Firewall'
} |
Format-List *

A more focused query:

Import-Csv "$out\usn.csv" |
Where-Object {
    ($_ | Out-String) -match 'Firewall' -and
    ($_ | Out-String) -match 'Delete|Truncation|Overwrite'
} |
Format-List *

15. Critical Finding — The Firewall Log Was Cleared, Not Normally Deleted

The relevant USN Journal entry was:

Microsoft-Windows-Windows Firewall With Advanced Security%4Firewall.evtx
UpdateTimestamp:
2026-07-12 18:21:40.7658957
UpdateReasons:
DataOverwrite|DataTruncation

The evidence did not show:

FileDelete

Instead it showed:

DataOverwrite
DataTruncation

Therefore the more accurate interpretation is:

Firewall.evtx
    ↓
contents cleared / truncated
    ↓
file itself remains

A useful analogy:

FileDelete
= throw away the notebook
DataTruncation
= keep the notebook but erase its pages

16. Correlation With wevtutil.exe

Execution evidence showed:

wevtutil.exe

running around:

18:21:39–18:21:41

wevtutil.exe is a native Windows utility capable of clearing Event Logs.

Conceptually:

wevtutil cl <log-name>

can clear a Windows Event Log.

The timeline therefore becomes:

18:21:39–18:21:41
wevtutil.exe execution
        ↓
18:21:40.7658957
Firewall.evtx
DataOverwrite | DataTruncation

This supports intentional Event Log clearing.

Evidentiary Caution

Maintain the following distinction:

USN Journal
→ proves truncation/overwrite
Execution artifact
→ proves wevtutil.exe ran
Correlation
→ supports the hypothesis that wevtutil was used to clear the log

Without a recovered full command line, the USN Journal alone does not prove the exact command Turner entered.

17. Final Timeline

TimeActivityArtifact18:04:19JMicron external storage activePartition Diagnostic18:06:28Turner browsed E:\ToolsShellBags18:06:54exfiltool.exe executedBAM18:07:50E:\Personal Data interactionShellBags~18:10:42BITS attempted evil-external.thm/upload/FinanceDocs.zipBITS Operational~18:13:28mstsc.exe executedBAM18:14:30\\192.168.86.172\Staging$ browsedShellBags18:17:29C:\FinanceDocs\Archive browsedShellBags18:17:30VendorContracts_Q3 interacted withShellBags18:21:39–18:21:41wevtutil.exe execution / cleanup phaseExecution artifacts18:21:40Firewall EVTX truncatedUSN Journal18:22:45External storage state changePartition Diagnostic18:23:02External storage active againPartition Diagnostic

18. Analyst Lessons

18.1 Enumeration Before Assumption

Do not immediately jump from a question to a tool.

Example:

"Firewall log deleted"

does not automatically mean:

search FileDelete

Instead ask:

What filesystem operation actually occurred?

The answer in this case was:

DataTruncation

18.2 Artifact Selection Should Match the Question

QuestionPreferred ArtifactWas a device connected?Partition Diagnostic + RegistryWhat was the volume name?Registry / Volume metadataWas a program executed?BAM / Prefetch / AmcacheWas BITS used?BITS Operational logWhat remote RDP target was used?Terminal Server Client registryWhat folders did the user browse?ShellBagsDid a file change, rename, truncate, or delete?$UsnJrnl:$JWhat is the NTFS metadata?$MFTWas a log cleared?USN Journal + execution evidence

18.3 Evidence vs. Inference

Always distinguish direct evidence from analytical inference.

Example:

ShellBag:
\\192.168.86.172\Staging$
Directly proves:
User browsed the share.
Does not independently prove:
FinanceDocs.zip was copied there.

The challenge context supplied the successful-copy fact, while the ShellBag supplied the destination path.

18.4 One Artifact Being Cleared Does Not Remove All Evidence

This case demonstrates an important forensic principle:

Windows Event Log cleared
        ↓
Event contents may disappear
NTFS USN Journal
        ↓
still records filesystem change

Therefore:

Destruction of one source of evidence can itself create evidence in another source.

19. Final Investigative Conclusions

The investigation reconstructed a coherent sequence of removable-media use, execution of an exfiltration utility, failed direct transfer attempts, BITS-based exfiltration, internal staging through RDP/SMB infrastructure, access to restricted finance material, and subsequent log-cleaning activity.

The primary answers are:

USB Serial:
MSFT300123456789ABCDEF
Storage Name:
PERSONAL_BACKUP
Executable:
exfiltool.exe
BITS Target Domain:
evil-external.thm
Archive:
FinanceDocs.zip
Internal System:
GTM-JUMP-01
Restricted Folder:
VendorContracts_Q3
Last Interaction:
18:17:30
Internal Staging Path:
\\192.168.86.172\Staging$
Firewall Log Clear Time:
06:21:40 PM

The strongest lesson from this investigation is methodological:

Observe
→ Select Artifact
→ Query
→ Validate
→ Correlate
→ Reconstruct
→ Report

The objective is not simply to recover challenge answers. The objective is to build a defensible forensic explanation of what occurred, when it occurred, which artifact proves each fact, and where inference begins.