Spotting RATs: Delphi wrapper makes the analysis harder

Pierluigi Paganini July 08, 2019

Experts observed an increase of the malware spreading using less-known archive types as dropper,in particular ISO image.Delphi wrapper makes analysis harder

Introduction

In the last period, we observed an increase of the malware spreading using less-known archive types as an initial dropper, in particular, ISO image.

The spread of threats exploiting ISO image to hide themselves is helped by the Windows functionality, introduced since Windows 8, which allows the user to easily mount this file type through a double-click on it.

Recently, our monitoring operations discovered an interesting attack wave leveraging this technique, especially due to the particular impersonification the attacker was trying: he/they was mimicking an important Italian Manufacturing company

Technical Analysis

Figure 1. Phishing email content

The phishing email (Figure 1) has a well-designed body containing the enterprise logo and references about the impersonated company: its international reputation has been abused by attackers to lure the victim to open up the embedded attachment.

Surely the presence of an ISO file as attachment is suspicious, but for an unaware user it could go unnoticed, also thanks to the new Windows versions which natively support the filetype. 

The Loader

Extracting the content of the ISO image, we encounter an EXE file named “po-ima0948436.exe”. From the first retrieved information, in particular the “BobSoft Mini Delphi” signature, it seems to be packed with a well-known Delphi packer (already studied by other popular firms). According to FireEye this packer is already used by different malware family, like Pony, IRStealer, Nanocore, Netwire, Remcos, nJRAT. Moreover, in our previous report we have already studied the Delphi wrapper, this time applied to a Nanocore variant.

Figure 2. Evidence of the Delphi wrapper

As expected, the malicious payload is stored in the resource section in encrypted way (probably using a simple XOR-encryption). This is one of the main features of the Delphi packer.

Figure 3. Encrypted payload, stored in Resource section

Rather than studying the payload extraction mechanism, we focused on the huge number of checks to detect the lab environment and, consequently, to make the analysis harder. The evasion tricks are surely part of initial Delphi packer; it probably was generated using a specific factory which allows the attacker to customize the features will be added to its weapon. 

Once executed, the malware obviously kills itself detecting the analysis machine, so we are going to investigate what are the tricks employed to stop us. Using our custom tool, we are able to extract information about the high-level techniques fielded by the malware writer to evade the analysis.

Figure 4. High-level evasion techniques

The first trick exploits a well-known Windows API call, “IsDebuggerPresent” to check if the process is executed in debugging mode. Bypass this control is quite simple: using a debugger we can modify the return value of the API call, hijacking the malware control flow.

Figure 5. IsDebuggerPresent API call

Immediately after the first trick, the malware shows another technique to identify the fake environment, monitoring the cursor movements. The cursor movements, indeed, represent the presence of a user operating with the system. So, the malware can identify if it is executed in a sandbox evaluating the different position of the cursor in periodic time intervals. This can be done through a finite loop in which the process check the position using the “GetCursorPos” API call.

Figure 5. Check against the cursor movements

After that, the malware retrieves the list of all active processes. This list will be used later to identify the presence of programs belonging to analysis environment. The most popular strategy to obtain the processes list is to use the “CreateToolhelp32Snapshot” Windows function. The malware needs to navigate the list in order to create a buffer with the processes’ executable paths only (“svchost.exe”“services.exe” etc.). So, it must invoke the  “Process32First” and “Process32Next” API calls, enter in the PROCESSENTRY32 structure and extract the “szExeFile” field, containing the executable path name.

Figure 6. API calls to obtain the processes list

The information about the processes are stored to be processed in a second moment. At this point, the malware exhibits another evasion technique, but more advanced than the previous ones. Using the CPUID instruction, it tries to extract information about the processor and its features.

According to VMware specifications “Intel and AMD have reserved CPUID leaves 0x40000000 – 0x400000FF for software use. Hypervisors can use these leaves to provide an interface to pass information from the hypervisor to the guest operating system running inside a virtual machine. […] VMware defines the 0x40000000 leaf as the hypervisor CPUID information leaf”. So, calling the instruction with the 0x40000000 parameter (in EAX register), the query result is the “Hypervisor Brand” string, split into three different registers: ECX, EDX and EBX (shown in Figure 7).

Figure 7. Result of CPUID instruction invocation

As shown in the above figure, the result string is reversed: the malware needs to manipulate it to obtain the right information “VMwareVMware” (Figure 8).

Figure 8. String reporting the hypervisor brand

Using this information, the malware is able to check if it is executed on a virtualized environment comparing the string with the embedded ones:

  • XenVMMXenVMM (Xen VM)
  • prl hyperv (Parallels)
  • Microsoft Hv (Microsoft Hyper-V )
  • KVMKVMKVM (KVM)
  • VBoxVBoxVBox (VirtualBox)
  • VMwareVMware (VMware)
Figure 9. Embedded string used during the hypervisor check

Bypassed this check, the malware knows to be in a non-virtualized environment but it is not yet the time to pull out its malicious behavior! At this point, in fact, it reloads the old processes list, retrieved in a previous phase, to compare its entries with the hardcoded names belonging to programs used in malware analysis, like:

  • procmon.exe
  • ollydbg.exe
  • procexp.exe
  • windbg.exe
Figure 10. Check against malware analysis tools

The same is done with components belonging to anti-malware products, in particular Avast and AVG. The hardcoded components names are:

  • avastsvc.exe
  • avastui.exe
  • avgsvc.exe
  • avgui.exe
Figure 11. Check against anti-malware software components

The last check consists in the identification of defined strings, related to malware analysis environment, with the absolute path in which the initial EXE is located. If the path contains words like “sandbox”“malware”“sample”“virus” and others, the execution flow terminates. 

Figure 12. Check against suspicious strings in path

If all the checks are successful, the malware can show its malicious behavior. It creates a child process containing the same instructions of its parent, so it repeats all the checks just executed, but it has the only purpose of injecting the final payload in a new “iexplore.exe” process. 

Figure 13. Active processes

Analyzing the process, it is possible to identify a suspicious thread starting from 0x00000000address. Probably the technique used to inject malicious code in the legit one is based on “CreateRemoteThread”, with which the malware is able to allocate memory in the legit process memory space, fill it with malicious instructions and force the victim process to start the execution of the new thread.

Figure 14. Injected thread

The Payload

The final payload is nothing more XpertRAT, a well-known Remote Administration Tool.  When executed, it writes a copy of itself in a hidden folder named %AppData%\Roaming\{GUID},setting the persistence writing the HKCU\Software\Microsoft\Windows\CurrentVersion\Run\{GUID} with the location of the EXE just created.

Figure 15. Malware’s artifacts

In the below figure, it is possible to see the written registry key pointing to the executable to start at the next logons.

Figure 16. Malware persistence through registry key

In the same folder, there is a file named “ut” which is used by the malware as buffer to contain the exfiltrated data in “keylogging” mode, before sending it to the server.

So, the RAT tries to establish a connection to its C2, hosted at “thisurl.doesntexist[.]com”, waiting for new commands to execute on the victim machine.

Figure 17. Malware attempt to communicate

Unfortunately, the server seems to be down at the analysis time, so we can only inspect the network flow using a fake net. As shown in the following figure, the malware sends a TCP stream containing some parameters used at server-side to identify the client that tries to establish the connection.

Figure 18. Malware’s network traffic

Conclusion

Finally, the analyzed sample is a classic Remote Administration Tool which has a long list of capabilities, such as keylogging, remote desktop, command execution and other exfiltration abilities.

However, the interesting part of the analysis is surely the initial Delphi wrapper, which is full of advanced tricks to make the analysis harder. As mentioned before, this packer surely derives from some kind of factory which allows the attacker to choose the capabilities he wants. We, in fact, intercepted many other infections based on the same Delphi structure, but with different features in terms of evasion and encryption, as evidence of the possibility of customize it.  

Technical details, including IoCs and Yara Rules, are available in the analysis published in the Yoroi blog.

https://blog.yoroi.company/research/spotting-rats-tales-from-a-criminal-attack/

[adrotate banner=”9″][adrotate banner=”12″]

Pierluigi Paganini

(SecurityAffairs – ISO image, Delphi wrapper)

[adrotate banner=”5″]

[adrotate banner=”13″]



you might also like

leave a comment