Solution
To analyze the provided memory.dmp file, we start with WinDbg.
On the WinDbg CLI, we can determine the original process name of this dump by using the command !analyze -v:
Next, we use the lm command to list all modules loaded into the process:
The first module loaded is ctfmon, which corresponds to the executable that originally spawned this process. This makes sense because when an executable starts, it is the very first module loaded, followed by the necessary DLLs it references.
The full path of the executable can be easily identified:
We then extract the executable image from the memory dump for further analysis:
.writemem C:\Users\admin\Desktop\ctfmon_dump.bin 0x00007ff66f330000 0x00007ff66f343000
Afterwards, we apply PE Dump Fixer to restore the original offsets of the module in virtual memory. Finally, we unmap the virtual addresses and rebuild a valid PE file using PE Unmapper.
At this point, the reconstructed executable is ready for reverse engineering in IDA.
The function sub_7FF66F338790 contains the core logic of the program.
The program first generates a random string and stores it in the environment variable MAVEN_HOME. This string is then XORed with the computer name, and the result is hashed with SHA-256 to derive the AES-CBC encryption key.
The IV is created by computing the MD5 hash of the first argument passed to the program.
The file targeted for encryption is flag.pdf.
The encrypted data is then sent to the C2 server.
Once we understand the logic, we can recover both the AES key and IV by reading the environment variable and inspecting the command-line arguments used when the process is executed.
By using the !peb command in WinDbg, we can inspect the Process Environment Block (PEB) of the current process. This reveals details such as the executable path, command-line arguments, environment variables, and other process-related state information.
From this, we can derive the AES Key:bb9b02534fe93a7d55f3a6050b1ede4e64fa2d520eee220a5f51fd7deeb153f9
And the IV:bf720623a85a294e52a16a1aba465f6d
Although the file was exfiltrated to a C2 server and no network traffic was captured, there is still a chance to recover the encrypted content directly from memory while it was in transit.
Since the target file is a PDF, we know with certainty that the first 4 bytes of the plaintext must be %PDF, and the encryption mode is AES-CBC. With the derived key and IV, we can brute-force by decrypting candidate memory blocks and comparing the resulting plaintext against the known PDF signature. This allows us to pinpoint the memory region containing the encrypted file data.
Using this approach, the script successfully locates and reconstructs the PDF:
$ python3 solve.py
[+] Derived key: bb9b02534fe93a7d55f3a6050b1ede4e64fa2d520eee220a5f51fd7deeb153f9
[+] Derived iv : bf720623a85a294e52a16a1aba465f6d
[!!!] Found PDF header at offset 0x12f4d4
[+] flag.pdf written, size: 10005