Payload

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

Scenario

You’ve completed Training Day — congrats, rookie. Now the real game begins. An unmarked binary just landed on your desk. It’s acting shady, tripping a few alarms, but no one's sure what it really is. Malware? Or just a misunderstood piece of code? Your mission: reverse-engineer the program, trace its behavior, and uncover the truth. Every line of code could be a clue—or a trap. Welcome to your first real case.

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: strings, ghidra, gdb, radare2.
• Artifacts: memory, jump, dump.

Detailed Investigation

1. In this case, we were tasked with investigating a suspicious binary that triggered multiple alarms upon execution. Extracting the malware archive revealed a single file named func_pointer.exe.

2. When the binary was executed, it only displayed a simple dialog box stating HTB pwned us No other immediate modifications were visibly observed. This behavior is interesting, as it suggests that the malware may be designed to execute post-exploitation activities in a stealthy manner.

1ST QUESTION -> ANS: REDACTED

1. Loading the binary into PEstudio allowed us to identify its hash, as well as review the imported and exported functions that could raise suspicion. In addition, analyzing the embedded strings provided further context, which may assist in attribution efforts or serve as a quick triage step to infer the potential objectives of the binary.
2. We also identified that the binary is 64-bit, and two imports, VirtualProtect and VirtualQuery were flagged as malicious. It is important to note, however, that not all imports marked as malicious should be considered inherently suspicious. Many Windows APIs are legitimate but frequently abused by malware, which often leads automated tools or triage utilities to flag them as potentially malicious.

2ND QUESTION -> ANS: REDACTED

1. Upon reviewing the strings in PEstudio, we were able to clearly identify the compiler used for the binary, which is MinGW. Numerous compiler-related strings referencing MinGW were present throughout the binary.

3RD QUESTION -> ANS: REDACTED

1. To identify information related to compilation datetime, I used radare2 with flag -I to shows for binary info (including its protections).

2. This binary was compiled as a 64-bit Windows console application. It has stack canaries enabled and NX/DEP protection, which prevent straightforward stack buffer overflows and execution of injected shellcode from data pages. However, it lacks ASLR support (no relocations, not PIC), meaning the memory layout is mostly predictable.

4TH QUESTION -> ANS: REDACTED

1. Based on our previous findings, the binary was compiled with ASLR (Address Space Layout Randomization) disabled.

5TH QUESTION -> ANS: REDACTED

1. There are many ways to identify the image base address, you may use decompiler or debugger. However, in this case I will use Detect-it-Easy (DIE) which commonly used to identify a file type along with heuristic analysis.
2. At the top right, we can see the image base address of the binary along with its entry point address.

6TH QUESTION -> ANS: REDACTED

1. Another useful tool to highlight is CFF Explorer, which is widely used for binary triage and analysis.
2. Inside parsed header section, we can identify the address of the binary's entrypoint.

7TH QUESTION -> ANS: REDACTED

1. To speed up the triage, I began by searching for code that attempts to obtain a handle to a DLL and store the address of its functions. This is so could quick reveals the intent of the binary.

2. This search led to the identification of the function FUN_140001d97.

3. Long story short, after reviewing each nested functions, identified FUN_1400017d0 as the function of primary interest.

4. Inside, it performs a simple bitwise operations actually. It's just a textbook XOR-based encryption / decryption.

5. However, the analysis revealed suspicious behavior when param3 was identified as a string buffer. Upon inspecting its contents, we observed the presence of encrypted strings. This indicates that, prior to obtaining the handle of a DLL and resolving its functions, the binary performs a payload decryption routine.

PAYLOAD LOCATION

PAYLOAD CONTENT

1. At this stage, we were able to clearly identify the first 8 bytes of the payload. In addition, another useful tool for static binary analysis is PE-Bear, which provides greater visibility into the encrypted payload structure and its characteristics.

PAYLOAD IS STORED AT .DATA SECTION (Global Initialized Variable)

8TH QUESTION -> ANS: REDACTED

1. Reviewing the previously identified decrypt function for the payloads. Notice param1 is treated as a pointer to a buffer of bytes, param2 iiis used as a modulus, means the function keeps wrappoing around inside that buffer.
2. It means param1 is a key material buffer, which is indexed repeatedly to generate the keystream local_1d that XORs against param3.

KEY BUFFER LOCATION

KEY BUFFER CONTENT

1. Great! Now we also identified the key buffer used (in hex).

9TH QUESTION -> ANS: REDACTED

1. To identify the address of the decrypted payload, we should debug the binary. To debug it I used x64Dbg.

2. At first, load the binary there and press run to user code so we jumped to the binary's entrypoint.

3. Next, right-click and follow the steps below. Since our objective is to begin debugging at the payload decoding phase, we should first locate the key buffer offset and set breakpoints there. Additional breakpoints can also be placed throughout the debugging process, as this may help us identify more accurate offsets for analysis.

RESULT AFTER JUMPED TO KEY BUFFER

1. After set breakpoint(s), just click the run button to jump there (it act like continue in GDB).

2. To identify the content, we can follow the dump by right click and follow these steps:

3. The full debugging steps are not shown here, as they would be too lengthy. The main objective is to identify where the decrypted value is stored.

4. Once this location is identified, another breakpoint can be set to track that section or register, and the dump can then be followed again in xDbg.

5. I recommend always comparing the logic with the assembly view in Ghidra, as this provides better context for identifying which instructions should be prioritized during debugging.

6. In short, we identified the actual offset where the decrypted payload is stored. Based on our findings, the encrypted payload resides in the .DATA section. Therefore, the debugging focus should be narrowed to mov instructions that interact with the data segment (ds).

7. To examine the content value and its address, it is best to begin the review at the cmp instruction. For this purpose, we set a breakpoint at offset 0x1400019A4 and then followed the dumps starting at offset 0x14000199B. Now we can see that the address of the decrypted payload is stored at 0x5FFC40, as ds:[RDX] is used to hold each decrypted payload buffer index and, in turn, points to this address.

8. At this stage, we can skip the previous breakpoint and set a new one at 0x1400019B4, then follow the dumps at 0x1400019AF. From there, by examining offset 0xFFC40 and the subsequent addresses, we can identify the entirety of the decrypted payload.

10TH QUESTION -> ANS: REDACTED

1. Based on our previous findings, we can clearly identify in the dump that the first 8 bytes of the payload reside at 0x5FFC38 + 0x8, spanning up to offset 0x5FFC48.

11TH QUESTION -> ANS: REDACTED

1. Continuing the review of invoked functions after the DLL handle retrieval, we identified a call to VirtualAllocEx(), which was notably absent from the Import Address Table (IAT) displayed in PEstudio.

IN PESTUDIO

1. While reviewing the code in Ghidra, we found that several other Windows API functions were also not identified by PEstudio. This occurs due to the way the code is written: these functions are resolved dynamically at runtime, so they do not appear in the static Import Address Table (.idata section).

NOTE:

Snippet code for dynamic resolve:

// C code.
pHVar1 = GetModuleHandleA("kernel32.dll");
pHVar1 = GetProcAddress(pHVar1, "VirtualAllocEx");

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

Findings

1. Persistence mechanism — As documented in the investigation steps.
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

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

Lessons Learned

1. Using PEStudio, DIE, Ghidra, CFF Explorer, PE Bear, and radare2 to conduct static windows binary analysis and triage.
2. Using x64dbg to conduct dynamic binary analysis.