XWorm RAT Delivered via Shellcode: Multi-Stage Attack Analysis

Remote Access Trojans (RATs) often remain quiet in the wild employing increasingly stealthy methods to exfiltrate sensitive data. Latest trends show attackers follow either fileless or in-memory techniques (via shellcode or script loaders) to deliver and execute malware.  

This blog post drills into the trend of how attackers are using shellcode as an enabling technology for modern RAT campaigns. This example injects the XWorm RAT.

Fig. 1 - Attack chain

Malicious email sample:

Fig. 2 - Malicious email

Office file and its content:

From the email, we see it has .xlam file attached to it. Given that the .xlam are archive files, we can just unzip and statically analyze it to view file contents.

On unzipping the file, we see the oleObject1.bin file in the embeddings folder of Excel file. We can also use the oledump Python tool to view the suspicious embedded file.

Fig. 3 - Ole10Native stream

On using oledump, we are successfully able to fetch the suspicious file “oleObject1.bin”. Further, we can see oleObject1.bin has a stream called Ole10nATive.  

Ole10nATive streams are commonly used by attackers to hide malicious encrypted codes.  

We can further extract this stream by using oledump to select object A1 and create a dump of it.

Shellcode analysis:

After creating a dump of the file, we see an encrypted file likely to be shellcode. A shellcode can be identified by a series of indicators such as call followed by jmp/pop instructions or API hashing.

We can use tools like XORSearch to find the offset from where shellcode will be executed.
 

Fig. 4 - Getting offset of shellcode

Here we observed “GetEIP” method at 0x000001D7, 0x000001D8, 0x0000026F offset which can be used to execute shellcode successfully. “GetEIP” method is used to run shellcode correctly as it needs to identify where it is being executed in memory.

As we have offsets now, we can emulate it using scdbg (a tool used for shellcode analysis and debugging).

Checking at any of the offsets gives us the same results:

Fig. 5 - Shellcode emulation

In Fig. 4, we find two windows API “GetProcAddress” and “ExpandEnvironmentStringsW” getting called which indicates this to be an expected shellcode. We also observed “unhooked call” instruction which refers to technique used by malware to bypass security products.

The “Facturas.bin” file has a few more API calls which are used to download, save and execute malware.

Fig. 6 - API calls and URL after cleaning up shellcode

From above figure, we see the API calls and URL:

• UrlMon
• UrlDownloadToFile
• LoadLibraryW
• hxxp://alpinreisan1[.]com/UXO[.]exe 

UrlMon API has key functionalities for downloading files from URL using UrlDownloadToFile. The file is downloaded from the mentioned URL and saved to %APPDATA%. Then LoadLibraryW is used to execute the file in memory from address space.

First stage executable analysis (UXO.exe)

On statically analysing downloaded file “UXO.exe” is found to be .NET compiled executable.  

Fig. 7 - Executable file summary

On statically analysing the file, we see the original filename is “KQuT.exe”. While analysing the .NET compiled binaries, it is good to focus on the classes/methods that use ‘Drawing’. The reason for this is that a lot of .NET malware will load a bitmap or object from its resource section and reflectively load the next stage into memory.

Fig. 8 - Steganography image in .exe file

On further analyzing the executable file in dnSpy, we saw the class “HashtaneProjeENSONhali” uses “System.Drawing”. Moving ahead and debugging the file, as soon as the malware hits entry point, the malware gathers a byte array from another class (Form_SecretaryDetail) within the file and loads it into memory.

Fig. 9 - File creation

Fig. 10 - Created file (Creative AI) loaded in memory

Second Stage DLL file analysis (CreativeAI.dll):

We were successfully able to dump the DLL file from memory and let us now look at the analysis of the file.

Using tools like PEStudio and Detect-It Easy (DiE) for static analysis, we can confirm the file type and its original name. Also, we can have a thorough look at the imports and strings that have been flagged.

Fig. 11 - DLL file summary from memory using PeStudio

The above figure shows it is a DLL .NET compiled file having filename as CreativeAI.dll which we saw in Fig. 12 below:

Fig. 12 - Suspicious strings and imports from PeStudio

 
From static analysis, we can figure out the suspicious strings and imports such as:

• MemoryStream
• CreateEncryptor

Viewing the DLL file in Detect-It Easy gives us some more insights into what sort of protection the DLL uses to hinder analysis:

Fig. 13 - DiE tool analysis

The DLL file uses several encryption techniques for analysis to be difficult such as RSACryptor, Virtualization, Fake. cctor, and many more.

Since the DLL file is loaded in memory as a byte array, we won’t be able to debug the file standalone. So, we need to debug the module while it is running in the memory of our original file, UXO.exe.

On performing further analysis, we observed “CreativeAI.dll” runs another Dll in the memory named as “DriverFixPro.dll” using Reflective DLL injection.

Fig. 14 -  DriverFixPro DLL loaded in memory

Fig. 15 - Reflective .DLL injection

Third Stage DLL Analysis (DriverFix Pro.dll)

Let us dump and extract this new DLL and check its content statically and dynamically. For statically analysing the file we will using DiE (Detect It Easy) and PeStudio to look for interesting artifacts.

When we loaded the file in PeStudio, we found more interesting strings and imports as seen in the figure below:

Fig. 16 – Suspicious strings and imports

Upon viewing the file in DnSpy, the file is found to be having a lot of obfuscated codes which hinders the analysis. For analysis, the only option we have is to set breakpoints and step through each class looking for any human readable code.

Fig. 17 - Heavily obfuscated .DLL code

Further debugging is out of scope from the perspective of this blog. Hence, when the file is loaded in memory it already performed the injection to its own process (UXO.exe) and we were able to dump the memory strings of the file. The strings from the memory dump show an interesting name “UD_XWormClient 6.5” which gives us indication of the malware belonging to the XWorm family.

Final Stage C2 connection

Fig. 18 - Memory strings showing presence of “UD_XWormClient”

After successful injection, the file tries to connect to IP: 158.94.209[.]180 where malware exfiltrates its data. When we tried to look up relations for 158.94.209[.]180 on Virus Total, we found it to be hosting a domain “berlin101[.]com:6000”. This domain is recognized as a C2 for XWorm malware.

Fig. 19 - UXO[.]exe network connection

Conclusion

The campaign is delivered by phishing email, using a fake invoice as a lure. The email has an Office file (.xlam) attachment, which, on downloading and opening, shows a blank or corrupted Office file. This malicious document has an embedded oleObject1.bin file, which hides embedded shellcode. The shellcode, when executed it, initiates connection to retrieve and deploy secondary payload.

The second payload, which was an executable was found to be .NET binary that reflectively loaded into the memory. The file which was loaded in memory is found to be a .dll  file which was also .NET compiled.

The second stage .DLL file from memory uses heavily obfuscated packing and encryption techniques. This second stage .DLL file loaded another .DLL file in memory again using reflective DLL injection which was further responsible for final execution of malware.

The next and final step performs a process injection in its own main executable file, maintaining persistence and exfiltrating data to its Command & Control servers. The C2s where data was exfiltrated was found to be related to XWorm family.

Protection Statement  

• Stage 2 (Lure) - Phishing email associated with this attack was identified and blocked by email security analytics.
• Stage 5 (Dropper File) – The dropper files are added to Forcepoint malicious database and are blocked.
• Stage 6 (Call Home) - C2 servers are categorized under the security category and blocked.

IOCs