Hunt Me I: Payment Collectors
TryHackMe Challenge Walkthrough
Challenge Overview
On Friday, September 15, 2023, Michael Ascot, a Senior Finance Director from SwiftSpend, was checking his emails in Outlook and came across an email appearing to be from Abotech Waste Management regarding a monthly invoice for their services. Michael actioned this email and downloaded the attachment to his workstation without thinking.
The following week, Michael received another email from his contact at Abotech claiming they were recently hacked and to carefully review any attachments sent by their employees. However, the damage has already been done. Use the attached Elastic instance to hunt for malicious activity on Michael’s workstation and within the SwiftSpend domain.
Threat Analysis Summary
Analyst Summary Report
Incident Title
Spearphishing Leads to DNS Exfiltration of Financial Records
Category
Exfiltration Over DNS, User Execution, Discovery
Detection Source
Windows Event Logs, PowerShell Logs
Impact
Sensitive internal financial data exfiltrated from mapped file share
Investigation Workflow
- Identified and analyzed malicious ZIP and LNK file
Traced attacker activity via PowerShell and Event Logs
Confirmed data exfiltration path using DNS queries
Mapped techniques to MITRE ATT&CK
Recommendations
- Implement attachment sandboxing for email attachments
Block execution of PowerShell scripts for non-admin users
Monitor for abnormal nslookup usage and DNS tunneling
Educate staff on phishing awareness
Tools Used
- CyberChef
MITRE ATT&CK
Windows Event Log Analysis
Kibana (Elastic)
Key Evidences
- Event ID 11 – Creation of malicious ZIP and extracted LNK file
Event ID 1 – PowerShell and command-line processes for enumeration
Event ID 800 – Execution of remote PowerShell scripts
nslookup usage for data exfiltration
File access logs for ClientPortfolioSummary.xlsx and archive creation
Chain Attack Overview
Initial Access
Malicious ZIP file via phishing email
Execution
User executes .lnk file from ZIP, launching PowerShell
Persistence
N/A (no persistence mechanism identified)
Privilege Escalation
Not observed
Defense Evasion
Use of .lnk file and PowerShell to avoid detection
Discovery
systeminfo.exe, whoami, net commands executed via PowerShell
Credential Access
Not explicitly observed
Exfiltration
Data zipped and sent using nslookup over DNS
Command & Control
Reverse shell established using powercat.ps1 via ngrok.io
Impact
Theft of sensitive financial Excel files from internal file share
MITRE ATT&CK Mapping
Phase
ID
Technique
Description
Initial Access
T1566.001
Phishing: Spear phishing Attachment
Invoice ZIP sent to Michael via e-mail
Execution
T1204.002
User Execution: Malicious File
.lnk file double-clicked by user
Discovery
T1082
System Information Discovery
Execution of systeminfo.exe
Collection
T1119
Automated Collection
Use of robocopy to gather documents
Exfiltration
T1048
Exfiltration Over Alternative Protocol
DNS exfiltration using nslookup
C2
T1059.001
PowerShell
powercat.ps1 used to establish reverse shell
Reference: [MITRE ATT&CK Navigator] ( https://attack.mitre.org/ )
Q & A
Q1: What was the name of the ZIP attachment that Michael downloaded?
first set the date to the 15.9.2023
We are going to look a .zip file created (ID 11) from outlook by the user Michael Ascot.
Kibana Query:
process.name: OUTLOOK.EXE AND winlog.event_id: 11 AND file.name: "*.zip"
From the results (see screenshot), the following fields confirmed the activity:
host.name: Identified the machine used
user.name: Showed the action was taken by michael.ascot
file.path: Revealed the exact location and name of the file
Answer
Invoice_AT_2023-227.zip
Q2: What was the contained file that Michael extracted from the attachment?
After finding the ZIP file Invoice_AT_2023-227.zip, I checked what got extracted from it.
The extracted file was: Payment_Invoice.pdf.lnk.lnk
(clearly we could have looked just for the surrounding documents of the file.zip)
Scrolling through nearby events, you can already spot signs of what’s coming next:
- Powerview.ps1 – typical for domain recon.
- Microsoft.PowerShell.Archive.psm1 – probably used for creating a ZIP for exfil.
- exfilt8me.zip – shows up shortly after, launched via PowerShell.
All signs point to this .lnk kicking off the attack chain.
Answer
Payment_Invoice.pdf.lnk.lnk
Q3: What was the name of the command-line process that spawned from the extracted file attachment?
checked what ran right after the .lnk file by filtering on its process.parent.pid, and looked for process creation events (event.code: 1).
That gave me the answer— the .lnk file launched: powershell.exe
Exactly what you’d expect at the start of an attack chain.
Answer
powershell.exe
Q4: What URL did the attacker use to download a tool to establish a reverse shell connection?
I checked the event details and found the URL right in the process.command_line field.
The script being downloaded is powercat.ps1, a PowerShell version of netcat — commonly used for tunneling, scanning, and reverse shells.
Answer
https://raw.githubusercontent.com/besimorhino/powercat/master/powercat.ps1
Q5: What port did the workstation connect to the attacker on?
The port is right there in the process.command_line. The attacker used an ngrok.io tunnel with: -p 19282
Answer
19282
Q6: What was the first native Windows binary the attacker ran for system enumeration after obtaining remote access?
we could just look for event_id 1 and process like cmd.exe or powershell.exe
or we can follow the crumbles and look for what the powershell execution generated
I followed the PowerShell process (PID 3880) and checked what it spawned
Two child processes popped up — 9060 and 6492. Looking at what they ran, I saw a bunch of classic recon commands like whoami, net group, and so on.
The first native binary that kicked things off was: systeminfo.exe
Answer
systeminfo.exe
Q7: What is the URL of the script that the attacker downloads to enumerate the domain?
Even without knowing ahead of time that powerview.ps1 was used, it stands out pretty quickly.
I opened the visualize library (create a lens) and built a quick table on file.name.keyword — powerview.ps1 jumped right out.
I sorted the events by time and found the initial activity:
– Event 11 → file creation
– Event 800 → PowerShell pipeline execution
That’s where the URL shows up.
Answer
hxxps[://]raw[.]githubusercontent[.]com/PowerShellEmpire/PowerTools/master/PowerView/powerview[.]ps1
(URL defanged)
Q8: What was the name of the file share that the attacker mapped to Michael's workstation?
I filtered for event.code: 1 where the parent process was PowerShell. After the usual recon commands (whoami, net group, etc.), the attacker found a file share with financial records.
Not long after, you can already see where this is going — robocopy is used for exfil, files are deleted, and nslookup starts talking to an external domain.
The share that was mapped: SSF-FinancialRecords
Answer
SSF-FinancialRecords
Q9: What directory did the attacker copy the contents of the file share to?
We already saw in the previous events that the attacker used robocopy to pull data from the file share. The destination path shows up clearly in the logs.
Answer
C:\Users\michael.ascot\downloads\exfiltration
Q10: What was the name of the Excel file the attacker extracted from the file share?
I filtered for robocopy.exe and checked for any .xls file created during the exfil. One hit stood out in the logs.
Answer
ClientPortfolioSummary.xlsx
Q11: What was the name of the archive file that the attacker created to prepare for exfiltration?
We already saw this earlier — the file used for exfil was exfilt8me.zip. I double-checked by looking for file creation events (event.code: 11), and there it was.
Answer
exfilt8me.zip
Q12: What is the MITRE ID of the technique that the attacker used to exfiltrate the data?
After creating the archive, the attacker used nslookup from the exfil directory to send data out — clearly exfiltrating over DNS.
Checking the MITRE ATT&CK framework, that lines up with:
[T1048 – Exfiltration Over Alternative Protocol](https://attack.mitre.org/techniques/T1048/)
Answer
T1048
Q13: What was the domain of the attacker's server that retrieved the exfiltrated data?
We saw it earlier during the DNS exfil — the requests were going out to:
Answer
haz4rdw4re.io
Q14: The attacker exfiltrated an additional file from the victim's workstation. What is the flag you receive after reconstructing the file?
The nslookup logs show a series of base64-encoded chunks — each one 30 characters long, which makes it easy to spot the pattern.
we can see that
– ReadAllBytes of the file zip
– $base64 -split ‘(.{1,30})’
so every chunk is 30 char encoded base64
We found 18 total chunks — two distinct sets. The second set starts with a break in the chunking pattern.
These chunks were:
VEhNezE0OTczMjFmNGY2ZjA1OWE1Mm
RmYjEyNGZiMTY1NjZlfQ==
Decoding with CyberChef gave us the final flag:
Answer
THM{1497321f4f6f059a52dfb124fb16566e}
Conclusion
A classic phishing setup: fake invoice, malicious .lnk, PowerShell abuse — and boom, your files are off on a DNS road trip.
The attacker didn’t reinvent the wheel here. Just zipped up some living-off-the-land tools (hello robocopy, nslookup, and PowerView.ps1), quietly ran their script kiddie playbook, and exfiltrated sensitive data one hex chunk at a time.
The good news? Every step left a footprint. With proper logging, clear process lineage, and a bit of patience in Kibana, the whole thing unraveled like bad DNS hygiene.
Moral of the story: .lnk attachments are still a thing. And nslookup is still getting away with way too much.