SecretPictures

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

Scenario

The university's IT team began receiving reports of strange activity on library computers. Students noticed hidden files appearing on their USB drives and disappearing moments later. An investigation revealed a single suspicious file named "SecretPictures." When opened, it vanished instantly without leaving a trace, and no antivirus tool could identify it. The IT team isolated the file and provided it for your analysis. As a cybersecurity analyst, your task is to determine what this malware does, how it spreads, and how to stop it before it affects more systems.

Key Questions

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

Investigation Timeline

Evidence Analysed

• Tools: wireshark, powershell, strings, pe studio, ida.
• Artifacts: registry.

Detailed Investigation

1. In this case, we were tasked with analyzing a PE file suspected of causing unusual activity on library computers, with no logs or operating system artifacts provided by the university’s IT team.

1ST QUESTION --> ANS: REDACTED

1. To get the MD5 checksum, in powershell I ran this command:

 ps1 read-only • copy allowed Copy
Get-Filehash .\secretPictures.exe -Algorithm MD5

2ND QUESTION --> ANS: REDACTED

1. A quick PE file analysis using PE Studio, DiE, or even a simple strings inspection is sufficient to determine the programming language used in the malware, compiled used, identify any packers, and gain a broader understanding of potentially malicious import functions.

RESULT FROM DIE

3RD QUESTION --> ANS: REDACTED

1. To identify the name of the folder that the malware hides in by copying itself, we need to perform code review to the PE binary. In this writeup, I a using IDA.

2. Reviewing the main.main() function, found 4 functions that could be our interest.

3. Inside the main.hide(), the binary performs a current working directory check using main_getCurrentPath().

4. Another functions that should be our interest are main_lurk() and main_vanish(), also off_90D2F0 section, which stored the path to "C:\Systemlogs".

OFF_90D2F0 section

1. Afterwards, it called runtime_concatstring2() to copy the binary to Systemlogs directory.

2. From reviewing the pseudocode, we can infer that a Systemlogs directory will be created, and the malware will copy itself there once its current location is identified by the program and before the execution flow is finished.

3. However, it is best to verify this behavior by debugging the binary.

BEFORE

AFTER

1. As shown above, after main_lurk() completes, the program proceeds to main_vanish(). At this point, the Systemlogs directory has not yet been created, because the copying operation actually occurs inside the main_vanish() function.

SYSTEMLOGS DIRECTORY AND INSIDE IT

1. Noticed that the copied filename is changed to logcheck.exe and the original binary is removed.

4TH QUESTION --> ANS: REDACTED

1. To identify its FQDN, I created a sandbox environment with fake network capability. For this purpose, I used REMnux configured with INetSim.

2. On my Windows machine (FLARE-VM), I captured the network traffic using Wireshark and executed the malware again to observe and extract its FQDN.

3. As seen above, flare performed an outbound connection to malware.invalid[.]com.

5TH QUESTION --> ANS: REDACTED

1. Upon reviewing the main_lurk() function, it becomes evident that the binary attempts to open a registry key under the Run location and create a new value inside it. This behavior indicates a persistence mechanism, typically used to ensure execution after reboot. Although the sample also uses scheduled task–related functionality elsewhere, the logic here directly targets Run key–based persistence.

2. The registry root handle is not stored in cleartext. Instead, the malware passes a decimal constant to the golang_org_x_sys_windows_registry_OpenKey function. To identify which predefined HKEY it corresponds to, this decimal value must be translated to hexadecimal.

3. This conversion can be validated using any standard decimal-to-hex utility.

v43 = golang_org_x_sys_windows_registry_OpenKey(
        -2147483647,
        (unsigned int)"Software\\Microsoft\\Windows\\CurrentVersion\\RUN",
        45,
        3,
        a5,
        a6,
        a7,
        a8,
        a9);

1. After obtaining the hex form, we correlate the value with documented Windows predefined registry handles, such as those listed in the Windows SDK (winreg.h) or in public mirrors.

2. Great! Based on this mapping, we can conclusively determine that the malware attempts to open and write to:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run

1. This confirms that the malware establishes persistence by placing an entry under the HKCU Run key, ensuring the malicious program executes automatically for the current user during system startup.
2. We can see the value stored there by visiting the key using any registry viewer software you have.

6TH QUESTION --> ANS: REDACTED

1. Although an initial inspection using PeStudio did not reveal any Windows API associated with drive-type enumeration, a deeper review of the disassembled code shows that the malware does invoke such functionality internally.

2. Upon examining the main_outbreak() function, the API usage becomes evident.

3. This function is responsible for the malware’s worm-like propagation mechanism. It iterates through drive letters from 68 (‘D’) to 90 (‘Z’), generating paths for each potential drive. For every detected removable drive, the malware attempts to copy itself to that location under the lure filename SecretPictures.exe.

4. Based on this analysis, it is clear that the malware relies on the GetDriveType Windows API to identify removable drives before performing the copy operation.

7TH QUESTION --> ANS: REDACTED

1. To identify the library function used for the periodic execution, we just need to review the main_repeat() function.
2. We can clearly see the NewTicker API is invoked there.

8TH QUESTION --> ANS: REDACTED

1. By reviewing the execution graph in IDA, it is evident that the function main_touchBase is invoked early in the execution flow, serving as one of the malware’s initial routines.

2. Immediately after this call, the malware proceeds to establish outbound communication with its Command-and-Control (C2) domain, indicating that this stage is responsible for its initial beaconing or registration attempt.

3. A quick inspection of the imported libraries and referenced functions shows that the malware relies on Base64 operations to encode both its outbound requests and the responses received from the C2 server. This suggests the malware employs simple encoding—rather than encryption—to obfuscate network traffic and evade basic detection mechanisms.

9TH QUESTION --> ANS: REDACTED

1. Inspecting at one of the POST request packet in previously captured netflow in wireshark, we can identify 2 fields in the request body -> name and version.

2. These also mentioned at the main_collectData() function.

3. We've finished briefly analyzed the binary.

Findings

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

MITRE ATT&CK Mapping

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

Lessons Learned

1. Static Analysis using tools such as IDA, PE Studio, and Detect It Easy (DiE) to examine the PE file’s structure, metadata, and potential indicators of malicious behavior.
2. Capturing netflow using Wireshark to monitor network activity and observe the malware’s behavior during execution.
3. Debugging using IDA.