In May and June, two files were submitted to VirusTotal that were signed with the same digital certificate and were connected to the SWIFT-heist wing of the DPRK. One file is re-themed version of the fake resume creating tool used in the Redbanc and Pakistan attacks. The second file is a tool used to inject and run payloads inside of explorer.exe.
This brief post documents the capabilities of this second tool.
MD5: b9ad0cc2a2e0f513ce716cdf037da907
SHA1: 1a50a7ea5ca105df504c33af1c0329d36f03715b
SAH256: db0f102af2d350aa1a63772e6ee9b211d78aa962a34f75c8702e71ccd261243e
Parameter Check
The malware expects at least one parameter: a file path (pointing towards the injected payload) to be passed to it during execution.
The majority of the injector’s workflow takes place within two functions. In the first function, the injector checks for any arguments set during execution (coincidentally, similar to a previous post on this blog). If this number is less than 3, the malware will jump to a “create file check,” to be discussed shortly:
If, however, this number is great than or equal to 3, the malware will begin checking for execution parameters. These can be seen in clear-text during debugging. Accepted parameters include -S, -E, and -D. Of these, only -S has an immediately discernible purpose: it causes the malware to sleep. These parameters (and the sleep function) are shown below:
Payload Checks
After checking for these parameters, the malware performs an additional check: it uses the passed filepath and attempts to open a handle at this location with CreateFile. If this is unsuccessful, the malware will exit this workflow and terminate. In addition, the malware makes two additional checks: one to GetFileSize and one to ReadFile. Each is followed by a “test EAX EAX” instruction. In practical terms, this ensures that the file in question has a size greater than zero (i.e. isn’t empty) and can be read by the malware.
Next, the malware calls WTSEnumerateProcessesA to list the running processes. It cycles through these until it identifies the process for Explorer.exe, and which point it enters the subroutine boxed below:
Injection Routine
This routine is the parent function for decoding and dynamically resolving several API calls related to process resolution.
The file then allocates a section of memory to Explorer and writes the payload to this memory section (using the resolved APIs). It resolves the NTCreateThreadEx API and then creates and executes a thread at this location:
Cleaning Up
At this point, the malware returns to the original loop that was used to identify Explorer.exe as a running process. Curiously, the malware actually continues to run in this loop rather than breaking the loop once it is found.
Once this loop completes, the malware will exit this function and the loader will terminate. If the -D or -S parameters were specified, the malware will overwrite the original contents of the loaded payload and then delete this file from disk. If -E is specified, the malware will actually skip this step.
At this stage, the payload is expected to be run in memory and the “loading” is complete.