TryHackMe: File & Hash Threat Intel — Walkthrough (Lab 2)

DFIRHive
Oct 21
6 min read

TryHackMe ‘File & Hash Threat Intelligence’ room — a hands-on lab focused on file artefacts, hash analysis, and sandbox enrichment to connect local evidence with global intelligence.

The File & Hash Threat Intelligence lab is where TryHackMe finally starts getting closer to how we work in the field.

Instead of theory, you’re handling actual artefacts — hashing files, running them through VirusTotal, and matching behaviour in sandboxes.

It’s short, but it hits the core idea: how a single file turns into a lead when you start enriching it.

Here’s the walkthrough with the questions, answers, and how each one connects to what we actually do.

Room URL: https://tryhackme.com/room/fileandhashthreatintel

Question 1 — One file displays one of the indicators mentioned. Can you identify the file and the indicator? (Answer: file, property)

Answer: payroll.pdf, Double extensions

Reference: Filename heuristic

Explanation: Heuristic indicators refer to patterns that hint at suspicious intent without directly confirming it.

One of the simplest is the double extension trick — a file like payroll.pdf.exe appears harmless (PDF) but is actually executable.

Attackers rely on Windows hiding known extensions, making the file look legitimate.

It’s a small but reliable red flag during triage and phishing investigations.

“Screenshot of payroll.pdf file properties showing it’s actually an executable application file.” — *"The suspicious file ‘payroll.pdf’ reveals itself as an executable when checked in properties — a classic double-extension trick."*

Question 2 — What is the SHA256 hash of the file bl0gger.exe?

Answer: 2672B6688D7B32A90F9153D2FF607D6801E6CBDE61F509ED36D0450745998D58

Reference: File hashing and artefact identification.

Explanation: A hash is a unique fingerprint derived from a file’s content using cryptographic algorithms (MD5, SHA1, SHA256). Even a one-byte change alters the hash completely .This SHA256 value identifies the bl0gger.exe sample universally — across VirusTotal, MalwareBazaar, or internal telemetry. Hashes are central to CTI because they connect visually different but technically identical files across systems and time.

“PowerShell output showing the SHA256 hash value of bl0gger.exe file.” — *" Generating a SHA256 hash using PowerShell to uniquely identify the suspicious file bl0gger.exe."*

Question 3 — On VirusTotal, what is the threat label used to identify the malicious file?

Answer: Trojan.Graftor/FlyStudio

Reference: VirusTotal detection results.

Explanation: VirusTotal aggregates signatures from multiple antivirus engines. The Trojan.Graftor/FlyStudio tag points to a trojan family known for credential theft and persistence through process injection. While vendor names differ, consistent results indicate similar functionality — a clue that multiple detection engines recognise the same malicious behaviour.

“VirusTotal detection summary showing bl0gger.exe flagged as Trojan.Graftor/FlyStudio by multiple vendors.” — *"VirusTotal analysis confirming the file as Trojan.Graftor/FlyStudio, detected by 63 out of 72 security vendors."*

Question 4 — When was the file first submitted for analysis? (Answer format: YYYY-MM-DD HH:MM:SS)

Answer: 2025-05-15 12:03:49

Reference: VirusTotal “First Submission” timestamp.

Explanation:The first submission date provides temporal context for the malware’s appearance in the wild. A recent timestamp means active distribution, while older ones suggest re-use of a known payload.T hese patterns help analysts trace when a campaign started or resurfaced.

“VirusTotal history panel showing first submission and last analysis timestamps for the malware sample.” — *"File timeline on VirusTotal showing when the malicious sample was first submitted and last seen in the wild."*

Question 5 — According to MalwareBazaar, which vendor classified the Morse-Code-Analyzer file as non-malicious?

Answer: CyberFortress

Reference: MalwareBazaar report summary.

Explanation: Different vendors use different detection heuristics. While most engines marked the file malicious, one labelled it clean. This shows why multi-source correlation matters — false negatives are common, and relying on a single verdict can skew analysis. The presence of one non-malicious flag among many detections often reflects heuristic variation, not safety.

On malware bazaar write 
sha256:1f8806869616c18cbae9ffcf581c0428915d32fb70119df16d08078d92d1a5e3

Question 6 — On VirusTotal, what MITRE technique has been flagged for persistence and privilege escalation for the Morse-Code-Analyzer file?

Answer: DLL Side-Loading

Reference: VirusTotal → Behaviour tab → MITRE ATT&CK mapping.

Explanation: DLL side-loading is a persistence method where attackers place a malicious DLL in the same folder as a legitimate executable. When the trusted application runs, it loads the attacker’s DLL, executing their code silently. This technique (MITRE ATT&CK T1574.002) grants persistence and privilege escalation since the payload inherits the privileges of the parent process.

“VirusTotal behavioural analysis showing DLL Side-Loading technique flagged for persistence and privilege escalation.” — *"VirusTotal behaviour report mapping DLL Side-Loading (T1574.002) for privilege escalation."*

Question 7 — What tags are used to identify the bl0gger.exe malicious file on Hybrid Analysis? (Answer: Tag1, Tag2, Tag3)

Answer: BlackMoon, Discovery, Windows-Server-Utility

Reference: Hybrid Analysis sandbox tag summary.

Explanation: Sandbox tags summarise what the file did during execution.“BlackMoon” links it to a known malware family; “Discovery” indicates system information gathering; “Windows-Server-Utility” shows disguise as an administrative binary. These tags provide a quick overview of behaviour, helping analysts prioritise samples for deeper review.

Hybrid Analysis sandbox interface displaying tags like BlackMoon, Discovery, and Windows-Server-Utility.” — *"Hybrid Analysis tagging summary for bl0gger.exe revealing system discovery and masquerading behaviour."*

Question 8 — What was the stealth command line executed from the file?

Answer: regsvr32 %WINDIR%\Media\ActiveX.ocx/s

Reference: Hybrid Analysis → Process activity logs.

Explanation: This command silently registers a malicious DLL (ActiveX.ocx) without showing output, thanks to the /s flag. Regsvr32 abuse is a common stealth technique that allows script or DLL execution under legitimate system processes.

“Hybrid Analysis showing regsvr32 command used to silently load ActiveX.ocx.” — *"Sandbox log showing regsvr32 command used for stealth DLL execution — a common anti-detection method."*

Question 9 — Which other process was spawned according to the process tree?

Answer: werfault.exe

Reference: Hybrid Analysis → Process tree section.

Explanation: Check for Processes

“Hybrid Analysis process tree indicating werfault.exe spawned by malicious process.” — *"Process tree revealing werfault.exe spawned from a suspicious parent "*

Question 10 — The payroll.pdf application seems to be masquerading as which known Windows file?

Answer: svchost.exe

Reference: File properties and metadata.

Explanation: Masquerading involves renaming a malicious file after a trusted system binary — in this case, svchost.dll. Legitimate svchost.dll lives only in C:\Windows\System32 and is signed by Microsoft. Any variation outside that location is considered suspicious.

File properties of payroll.pdf showing original filename as svchost.dll.” — *"Masquerading detected — the payroll.pdf file pretends to be svchost.dll, a trusted Windows system file."*

Question 11 — What associated URL is linked to the file?

Answer: hxxp://121.182.174.27:3000/server.exe

Reference: Sandbox network traffic.

Explanation:

Calculate the hash and open in sandbox to check:

“Sandbox network indicators showing associated URL hxxp://121.182.174.27:3000/server.exe.” — *"Sandbox report highlighting a malicious URL used by the sample for command-and-control communication."*

Question 12 — How many extracted strings were identified from the sandbox analysis of the file?

Answer: 454

Reference: Sandbox “Extracted Strings” section.

Explanation: String extraction reveals readable text inside executables — commands, file paths, domains, or function calls.

“Hybrid Analysis showing 454 extracted strings including file paths and function names.” — "*Extracted strings from the file providing insight into embedded paths, commands, and possible configuration details.*"

Let's move to practical scenario for Challenge.bin.sample.

Question 13 — What is the SHA256 hash of the file?

Answer: 43B0AC119FF957BB209D86EC206EA1EC3C51DD87BEBF7B4A649C7E6C7F3756E7

Reference: Hash generated from the Powershell command

“PowerShell window displaying SHA256 hash — *"PowerShell output showing SHA256 hash generated for the sample file, used for correlation in VirusTotal."*

Question 14 — What family labels are assigned to the file on VirusTotal?

Answer: Akira, FileCryptor

Reference: VirusTotal → Threat label summary.

Explanation: The sample is linked to the Akira ransomware family, known for encrypting data and dropping ransom notes.“FileCryptor” reflects its encryption capability and aligns with Akira’s attack pattern.

“VirusTotal detection showing Akira and FileCryptor family labels for ransomware sample.” — " *VirusTotal categorizing the analysed file as part of the Akira ransomware family with FileCryptor tags."*

Question 15 — When was the first time the file was recorded in the wild? (Answer Format: YYYY-MM-DD HH:MM:SS UTC)

Answer: 2024-10-30 17:17:24 UTC

Reference: VirusTotal → “First seen in the wild.”

Explanation: The “first seen” timestamp helps track campaign evolution and distribution. It’s an important metric when determining whether a threat is new, active, or resurfacing.

“VirusTotal report displaying first-seen date of 2024-10-30 17:17:24 UTC for ransomware sample.” — *"First-seen timestamp in VirusTotal showing when the sample file was initially detected in the wild."*

Question 16 — Name the text file dropped during the execution of the malicious file.

Answer: akira_readme.txt

Reference: Sandbox → Extracted files.

Explanation: The dropped ransom note is typical of Akira infections. It provides proof of encryption and contact details for ransom negotiations — confirming the sample’s purpose as ransomware.

Hybrid Analysis extracted files list showing akira_readme.txt dropped by the ransomware.” — *"Sandbox evidence of Akira ransomware dropping akira_readme.txt ransom note during execution."*

Question 18 — What PowerShell script is observed to be executed?

Answer: Get-WmiObject Win32_Shadowcopy | Remove-WmiObject

Reference: Sandbox behaviour analysis.

Explanation: This PowerShell command deletes system shadow copies, preventing file recovery. This behaviour maps directly to the MITRE ATT&CK technique T1490 — Inhibit System Recovery, a standard post-encryption tactic in ransomware operations.

“Hybrid Analysis sandbox showing PowerShell command Get-WmiObject Win32_Shadowcopy Remove-WmiObject used to delete shadow copies.” — *" Sandbox log showing PowerShell execution of Get-WmiObject Win32_Shadowcopy | Remove-WmiObject, a ransomware technique for deleting shadow copies."*

Question 19 — What is the MITRE ATT&CK ID associated with this execution?

Answer: T1490

Reference: MITRE ATT&CK Framework.

Explanation: Technique T1490 (Inhibit System Recovery) covers deletion or modification of backups, shadow copies, or recovery data. Its purpose is to ensure the victim cannot restore data without paying the ransom.

“Hybrid Analysis report mapping PowerShell shadow copy deletion to MITRE ATT&CK technique T1490 Inhibit System Recovery.” — *"MITRE ATT&CK mapping highlighting technique T1490 — Inhibit System Recovery — linked to ransomware behaviour."*

Thanks for reading and supporting.

If this helped you understand the TryHackMe CTI room a little better, feel free to share it with others or tag DFIRHive.

Every share helps us bring more practical content to the DFIR community.