Cyber criminals have been taking advantage of built-in Windows capabilities to mount disk image files once they are opened by the end user. There are multiple disk image file formats, but we have seen ISO and IMG files being abused the most. A disk image is essentially a virtual copy of a physical disk that houses all of the files and requires that it be mounted in order to access its contents. The advantages of using disk images, combined with the easy access to purchasing RATs, make this a preferred and effective method for cyber criminals.
In this blog, I dissect a campaign that uses this method to compromise a system, providing insight into what the CrowdStrike FalconComplete team has observed since 2019. I will also provide step-by-step remediation along with recommendations for how to implement this approach in your network.
Parcel-themed Phishing Email Scenario
The chain starts with a simple email containing a disk image file (.IMG) to socially engineer the victim into viewing the contents. The message seems to be coming from a worldwide package delivery company.
Figure 1. Phishing contents sample. The delivery company did not send this email.
The attachment in this sample is only 2MB, which raises a flag immediately as disk images are typically larger in size.
Figure 2. IMG file properties
Double-clicking on the file allows Windows 8 and Windows 10 to mount the IMG file natively to the next available drive. This sample uses a PDF icon as a disguise.
Figure 3. IMG file mounted on disk
Analysis
Exeinfo PE identified the binary as a compiled AutoIT script version 3. AutoIT is a scripting language used to automate Windows GUI tasks. Cybercriminals would first compile these scripts into an executable using the Aut2Exe compiler and further convert it into a disk image file to then distribute it widely in campaigns.
Figure 4. Exeinfo PE against binary e-voucher.exe
Dumping the rcdata resource and reviewing the strings shows AU3!, a common string seen in AutoIT-developed scripts.
Figure 5. Hexdump of e-voucher.exe
The AutoIT script is obfuscated, and it is used as a dropper to eventually load the NanoCore RAT on the intended system.
Figure 6. Snippet of obfuscated AutoIt script
Beginning on line 9746 in Figure 6, we can see the following three resources:
dusmtask1
bdechangepin2
aadWamExtension3
The script merges these three resources and passes the key “hwnglongpcoiftynieblwrqseblfkkwvfvbhnizgvvfanyqbrn” as the second parameter to the function swydxtrwncfvpukruyyjvmtphe(). To decrypt, it creates a hash using CryptCreateHash with this key. Consequently, it then uses the function CryptDeriveKey and creates a separate key from the results of CryptCreateHash. Finally, CryptDecrypt is used to decrypt the resource.
Figure 7. Encrypted stream prior to CryptDecrypt
Figure 8. Contents decrypted after CryptDecrypt returns
Once the contents are decrypted, it will then use the CreateProcessW function to spawn the legitimate process RegAsm.exe in a suspended state using the process creation flag 0x00000004 (CREATE_SUSPENDED)
Figure 9. x32dbg debugger CreateProcessW function starts RegAsm.exe in suspended state
Shortly after, it proceeds to allocate memory space for the malicious payload that was decrypted earlier. This memory region is created with memory protection of 0x40 (PAGE_EXECUTE_READWRITE)
Figure 10. x32dbg debugger VirtualAllocEx allocating memory space
Last, the WriteProcessMemory call is seen to finally write the contents into this newly created memory region.
Figure 11. x32dbg debugger WriteProcessMemory function writing into memory region
Inspecting RegAsm.exe using ProcessHacker shows the memory region 0x400000 that was created earlier filled with the payload. The sample is using a well-known technique to hollow out RegAsm.exe and inject its payload.
Figure 12. ProcessHacker showing memory region injected with malicious code
After dumping the malicious code out of memory, we can confirm that it is a .NET built binary packed with Eazfuscator.
Figure 13. Exeinfo displaying packer information on dumped process
Running de4dot against this copy is able to deobfuscate to see readable strings.
Figure 14. DnsSpy after deobfuscation
The malware then proceeds to drop a copy of itself to the path
C:\Users\username\PasswordOnWakeSettingFlyout\DataExchangeHost.exe
In addition, it creates persistence by using a URL shortcut in the StartUp folder that points to the copy of NanoCore RAT to survive reboot. A malicious VBS script named AppVEntSubsystems64.vbs is also dropped in the same directory where DataExchangeHost.exe resides.
Figure 15. VBS script contents
The Falcon Complete Team has seen variations of the script above being obfuscated with the same ultimate goal such as in Figure 16.
Figure 16. VbsEdit debugging obfuscated script
A copy of RegAsm.exe is dropped onto disk and is added to the Run key to boot on user logon, as seen in Falcon’s Process Tree viewer. Falcon also logs the network connection used as the C2 in this sample, as seen in Figure 17.
Figure 17. Falcon Process Tree displaying Registry Operations and DNS request
The functionality of NanoCore RAT has been covered heavily, so this blog will not focus on it. Figure 18 shows the same detection in Falcon’s UI but this time being prevented after running the same sample with the detection and prevention settings set to “Aggressive.”
Figure 18. Prevention policy enabled