← Back to Writeups
HTBEasySOC/DFIR

Zenith

D3v0o0Nu119/2/20267 min read
#soc/dfir#htb#easy

Zenith

Platform: HackTheBox | Type: SOC/DFIR | Difficulty: Easy | Author: D3v0o0Nu11 | Date: 2026-02-10

Scenario

We are contacting you with an urgent request concerning a potentially suspicious email that was recently received and unfortunately opened by one of our team members. As a construction company (Caymine builders), we regularly engage in project discussions with clients, and this email appeared to contain a project plan in PDF format. However, after further review, we have reason to believe this email and its attachment could be malicious. Despite our usual security protocols, the PDF was opened on one of our systems, which has raised significant concern regarding the security of our network.

Key Questions

  1. What indicators of compromise exist?
  2. What attack chain / MITRE techniques were used?
  3. What is the full timeline?

Investigation Timeline

TimeEventEvidence / Source
17:44:11The e-mail headers clearly show the message components and include the timestamp indicating when the Postfix MTA on `...

Evidence Analysed

  • Tools: binwalk, exiftool, ghidra, cyberchef.
  • Artifacts: EVTX, memory, registry, database.

Detailed Investigation

  1. In this case, we were tasked with investigating a phishing incident involving an email that contained a malicious PDF. Unfortunately, the PDF was opened, and the client is concerned about the security of their network.

Artifacts given

1ST QUESTION -> ANS: REDACTED

  1. To identify the timestamp of the e-mail retrieval, we can review the available e-mail artifacts and analyze the message headers.

In VSCODE

  1. The e-mail headers clearly show the message components and include the timestamp indicating when the Postfix MTA on mail.caymine.htb accepted and delivered the e-mail to the recipient’s mailbox (felamos@caymine.htb) at Thu, 19 Sep 2024 17:44:11 UTC.

  2. Also, scrolling down below we can see the attached PDF file.

  3. To review the file, we can just decode the base64 using cyberchef then save it as PDF file.

2ND QUESTION -> ANS: REDACTED

  1. To identify the file creation timestamp, we used exiftool in Linux to examine the PDF metadata. During the review, we observed that the Producer field was set to pyFPDF. The use of a non-standard PDF generation tool is noteworthy and raises a potential concern.

3RD QUESTION -> ANS: REDACTED

  1. Next, to identify what is the embedded file name, we can start by parse the PDF's Objects using peepdf.

  2. We identified several suspicious elements during the analysis. Starting with objects 11 and 12, we found a reference to object 13, which appears to contain the file extension of the displayed filename. Upon reviewing object 13, we can clearly conclude that the filename and its extension are downtown_construction_project_plan.pdf.

NOTE:

console
In a PDF, an indirect object reference has this format:
<object number> <generation number> R
  1. Reviewing object 14 revealed the content of the embedded file. However, the declared MIME type is inconsistent with the actual file data. Analysis of the raw bytes indicates that the embedded content is a PE binary.

  2. To make sure of it, after extract the pdf using binwalk and performs a basic file check, it confirms LINUX identified the file nto as PDF but as 32 bit PE binary.

4TH QUESTION -> ANS: REDACTED

  1. The compilation timestamp for the PE binary, can be easily identified again by simply running exiftool to check the binary's metadata.

5TH QUESTION -> ANS: REDACTED

  1. Since the question asks for the original project name, this can be verified by examining the debug information embedded in the binary. A static analysis in Ghidra can be performed with the objective of locating the Program Database (PDB) file path, which often reveals the original project name assigned by the developer.

Or you may use PESTUDIO

6TH QUESTION -> ANS: REDACTED

  1. To identify this, I began by detonating the malware in a controlled sandboxed environment (FLARE-VM) and examined the Users subdirectories. During this review, I found a newly created binary named test.exe inside the Public directory.

  2. Since the malware copies itself, we can verify its legitimacy by checking the file hash, a straightforward method. The analysis confirmed that the newly created file is identical to the original binary.

7TH QUESTION -> ANS: REDACTED

  1. Since the detonation was performed manually, we can also review the SOFTWARE or NTUSER.dat registry hive to identify anomalous registry key values under the Run key. However, because the binary is stored in the Public directory, the focus should be on reviewing HKEY_CURRENT_USER (NTUSER.dat).

NOTE:

To identify persistence mechanism as Run or RunOnce manually, you may check from these:

  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run (SOFTWARE)
  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce (SOFTWARE)
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run (NTUSER.dat)
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce (NTUSER.dat)
  1. Interestingly, a new Windows service named WindowsPooler was found installed on the system, and it references the malicious binary.
  2. Actually all of these findings can be confirmed by reviewing the code at function FUN_140001070

8TH QUESTION -> ANS: REDACTED

  1. To verify this, I continued the code review at function FUN_140001070 and identified several Windows API calls and code snippets consistent with process injection behavior. Specifically, the code performs process enumeration and targeting, opens the target process, allocates memory within the remote process, writes the payload into the allocated memory, and finally executes the injected code.

  2. Now, it is confirmed that explorer.exe indeed the targeted process for payload injection by the malware.

9TH QUESTION -> ANS: REDACTED

  1. To identify the client’s OS version, we reviewed the System event logs. These logs were first parsed using EvtxECmd (by Eric Zimmerman) and then examined with Timeline Explorer.

COMMAND

.\EvtxECmd.exe -f "path_to_file.evtx" --csv . --csvf filename_xxx.csv
  1. Afterwards, in Timeline Explorer, we can check for Event ID 2004 or search for the keyword "Build" to identify the OS build information.

  2. Review the Event ID 2004 details, it shows us information related to the client OS.

10TH QUESTION -> ANS: REDACTED

  1. To identify the adobe program used, we should review the Application event log file and check for Event ID 11707 for completed installation operation.

11TH QUESTION -> ANS: REDACTED

  1. Activity related to service installation can be identified in system event log. However, to give us quick scope or small horizon related to suspicious activity, we may also triage all event logs using evtx analyzer tool -> Hayabusa.

Command using Hayabusa

hayabusa-3.3.0-win-x64.exe csv-timeline -d dir_to_evtx -o htb-zenith-hayabusa.csv -p super-verbose
  1. Notice, that Hayabusa flagged a high alert named "Meterpreter or Cobalt Strike Getsystem Service Installation - System". This should be related to our interest.

  2. On felamos-PC (the client host), the threat actor performed privilege escalation by creating a service named ismzjo that executes command prompt as SYSTEM. Don't forget to conver the timestamp to UTC+0.

12TH QUESTION -> ANS: REDACTED

  1. At System windows event log, we can clearly identify the timestamp of WindowsPooler service exection for persistence. Check for event ID 7045 and triage specific for new installation service WindowsPooler.

  2. Great! We've investigated the case briefly.

Findings

  1. Persistence mechanism — An autostart/persistence mechanism was established on the host (see timeline).
  2. Initial access — The threat actor established access via the vector described in the investigation steps.
  3. Impact — As documented in the investigation steps.

MITRE ATT&CK Mapping

TacticTechniqueID
Defense EvasionObfuscated Files or InformationT1027
Defense EvasionProcess InjectionT1055
Defense EvasionModify RegistryT1112
PersistenceBoot or Logon Autostart ExecutionT1547
Initial AccessPhishingT1566

Answers / Flags

  • 1ST QUESTION -> ANS: REDACTED
  • 2ND QUESTION -> ANS: REDACTED
  • 3RD QUESTION -> ANS: REDACTED
  • 4TH QUESTION -> ANS: REDACTED
  • 5TH QUESTION -> ANS: REDACTED
  • 6TH QUESTION -> ANS: REDACTED
  • 7TH QUESTION -> ANS: REDACTED
  • 8TH QUESTION -> ANS: REDACTED
  • 9TH QUESTION -> ANS: REDACTED
  • 10TH QUESTION -> ANS: REDACTED
  • 11TH QUESTION -> ANS: REDACTED
  • 12TH QUESTION -> ANS: REDACTED

Lessons Learned

  1. Business e-mail compromise.
  2. Parse PDF objects using peepdf.
  3. Parse event logs using Hayabusa and EvtxeCmd.
  4. Using Timeline Explorer to review parsed event logs.
  5. Static binary analysis using pestudio, ghidra, and manual detonation using Flare-VM.