Figure 1: Phishing email

Figure 2: PDF file

The malicious URL was hidden in a stream object (/ObjStm), making it challenging to detect. However, extracting the URL by pdf-parser reveals that it is located in object 14 within stream object 1, as shown in Figure 3.

Figure 3: URL in the stream object

Upon clicking the file, the victim connects to the URL https://www[.]cttuae[.]com/ems/page[.]html, a website that seemingly offers travel services. The attacker had uploaded a malicious HTML file to the “ems” path on July 12, with the source code displayed in Figure 4.

Figure 4: HTML page “page.html”

Instead of directly downloading a virus, the attacker adopts a more sophisticated approach by utilizing the “search-ms” protocol to trigger a search result. Specifically, they search for “ORDER_SPEC0723” on a remote cloud storage server facilitated by DriveHQ. Notably, the file “ORDER_PSEC0723” masquerades as a PDF file icon, but upon closer inspection, it is revealed to be an LNK file that executes a PowerShell script within the same folder, as shown in Figure 5. This tactic allows the attacker to initiate their malicious activities discreetly.

Figure 5: Search result and the LNK file “ORDER_PSEC01723”

The PowerShell script “pf.ps1” (Figure 6) is then executed, beginning with the use of “regsvr32” to launch the injector “doc.dll,” which was written in Rust. It opens the decoy PDF file “T.pdf” and executes “AA.exe.” Finally, all File Explorer windows are closed using “Stop-Process -Force.” The PDF file “T.pdf” in Figure 7 appears clean and contains clear text, intending to distract the victim from other malicious actions. The following section will look in detail at “doc.dll” and “AA.exe.”

Figure 6: PowerShell script “pf.ps1”

Figure 7: Decoy file “T.pdf”

Figure 8: String section

The injection process begins with creating a “notepad.exe” process using CreateProcessA. The shellcode is subsequently obtained through Base64 decoding and LZMA decompression. The injector then injects the shellcode using functions directly with the NTAPI library. This entire process mirrors the behavior of the Red Team tool “Freeze.rs” which was launched in May, showing rapid adoption of this new tool.” The source code and injector’s assembly code showcased in Figure 9.

Figure 9: Shellcode injection

Over the past month, we’ve compiled a collection of diverse Rust injectors, including DLL files with LZMA-compressed shellcode, DLL files featuring RC4-encrypted shellcode, and EXE files incorporating RC4-encrypted shellcode. The shellcode data within these injectors are all encoded using Base64, and intriguingly, the file type and encryption algorithm appear to be selectable options within the program. This observation aligns seamlessly with the options found in the “Freeze.rs” repository, suggesting a potential connection to this Red Team tool. The flexibility in choosing encryption methods and file types adds to the sophistication of these injectors, further complicating detection and analysis for security researchers.

Figure 10: “Freeze.rs” options

When utilizing the RC4 algorithm variant, the key is expanded to 256 bytes and used in the Pseudo-Random Generation Algorithm (PRGA). The corresponding source code and assembly for this injector variant can be seen in Figure 11. Upon comparison, it becomes evident that this attacker employs “Freeze.rs” to bypass EDRs and utilizes suspended processes. The decrypted shellcode can be found at address 0x650000, as shown in Figure 12.

Figure 11: RC4 decryption

Figure 12: Decrypted shellcode

The decrypted shellcode applies AMSI bypass and WDLP bypass techniques, subsequently executing a .NET payload. Once executed, the .NET assembly can be dumped from memory address 0x1AAB6E70, as depicted in Figure 13, allowing for analysis as a stand-alone .NET executable.

Figure 13: Decrypted .Net payload

The .NET payload discovered in the process is known as XWorm, a commodity RAT tool reportedly traded in underground forums. XWorm is equipped with typical RAT functionalities, including gathering machine information, capturing screenshots, logging keystrokes, and establishing control over compromised devices. In this instance, the XWorm payload version is v3.1, and the C2 server information remains hidden on the “pastebin.com” website, as illustrated in Figure 14.

Figure 14: XWorm V3.1 and the C2 server IP address on pastebin.com

Figure 15: MSIL downloader’s links

Upon download completion, “AA.exe” utilizes the file name “760” as the decoding key and performs a subtraction operation with each byte in the downloaded data. The decoded data is a SYK Crypter with a resource named "SYKSBIKO," which contains the encrypted payload. The DLL file checks to ensure the environment is not in debug mode and then proceeds with processing the resource data by employing RC4 decryption with the key “gOhgyzyDebuggerDisplayAttributei.” It invokes a small .NET code, "Zlas1," for further deflation.

Figure 16: Calling .Net code for decompression

To evade detection, SYK Crypter encoded the strings utilized in its execution flow, with the decoding function depicted in Figure 17. Additionally, it employs functions like “GetProcessesByName,” “Directory.Exists,” and “File.Exists” to assess the presence of security appliances within the compromised environment. The list used for checking is found in Figure 18.

Figure 17: String Converter function

Figure 18: Security appliance checking list

For persistence, the malware appends the “.exe” extension to the file “AA” and copies the MSIL downloader to the “Startup” folder. It also adds a registry entry “Run” at “HCKU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows.” The corresponding code is depicted in Figures 19 and 20.

Figure 19: Copy self to “Startup”

Figure 20: Add Registry

After RC4 decryption and deflation of the resource data “SYKSBIKO.Properties.Resources.resources‎‎.a,” the execution file is obtained, as shown in Figure 21. SYK Crypter then loads a Base64 .NET code and calls its “GetDelegateForFunctionPointer” function, creating delegation to all APIs from kernel32  or ntdll in the same method. Figure 22 shows a snippet loading “kernel32!WriteProcessMemory,” following which the decrypted payload is injected into a process.

Figure 21: Decrypt resource data from SYK Crypter

Figure 22: Invoke “GetDelegateForFunctionPointer” to get API

The injected payload is the Remcos RAT, originally designed as a legitimate tool for remote computer control. However, since its release in 2016, hackers have exploited it to gain control over victims’ devices. The configuration can be obtained by RC4 decrypting the “SETTINGS” resource, with the clear configuration displayed in Figure 24. Interestingly, the C2 server IP address remains the same as the XWorm payload’s.

Figure 23: Encrypted configuration in “SETTINGS”

Figure 24: Decrypted configuration

Figure 25: Telemetry