REMCOS RAT Infection

Remote control & Surveillance Software or REMCOS from breaking-security dot net. A lightweight remote administration tool (free and pro) version that been used by system admins professionals for at least its benign premise. Remcos has also appeared in multiple malware campaigns as Remote Access Trojan (RAT). Based on review on the previous analysis done on this malware type it appears to be that adversaries are using almost a similar tactics, but slight optimization in wrapping, obfuscation, and anti-debugging techniques to evade detection at best and to slow analysis for sure.

Remcos RAT infection in short is multi stage infection technique to place foothold in victims’ environment. The adversary uses office documents with hidden script to trick the user. once victim open the document the malicious script begin staging the infection by downloading and running malicious executables in the background. The attacker want to secure persistent in victims environment even after reboot, and placing keylogger as one of the obvious features of this malware.

In my analysis I’ve used different approaches for each of the given artifacts to check the variation with the previous findings [2][3] and what are the attacker methods that been used in this campaign . Both static and dynamic analysis techniques been used to reverse engineer the malware using debuggers, disassemblers, de-obfuscation techniques, and analyzing Windows API functions. In addition, I’ve conducted a live infection session to check if the C2 sever still active.

Files

File NameSHA265
Quotation.xla 05f728ee2f55714446aa32ab842bef2741cb14a25b879dc0f7deb2d25b0fad05
rthfy.exe1787f73acf804bff30fe863e077fb5bc9799b3cb39065534198f894757907e79
remcos.exe2cb54ba4e33af4b048dfa9aa0d13ce7ddf0f197bfba76ba88d5289d1108dd038
Table -1- Host-based IOCs

Connection

TypeFile NameURLPort
DownloaderQuotation.xlatinyurl [.] com443
Downloaderrthfy.exeaminsanat[.]com80
C2 Serverremcos.exewhatgodcannotdodoestnotexist[.]duckdns[.]org2889
Table -2- Network-based IOCs

Analysis

I break this section into three based on the stages number on this attack to follow along with the analysis highlighted in the infographic on top.

Stage 1: Spreadsheet

From the first glance of Quotation.xla file’s strings, it’s clear the malicious script calling, downloading and invoke an exe file from tinyurl[.]com. It seems that the attacker is not even trying to obfuscate the scripts in Macro file. So it’s been handed easily.

The Macro contains three PowerShell scripts that download file, set destination directory, and run the file in this order, file name: nm.exe. When dynamically running the Excel file three child cmd and powershell process are running. Capture process tree using ProcMon from SysInternals

When nm.exe first been downloaded to temporary directory then script moved it to %AppData%Roaming to execute. The entire purpose of nm.exe is just to send GET request to another, which makes it only a downloader. No scrambling or any obfuscation methods used in this executable

Here’s Wireshark caption during live attempt to infect the OS without using InetSim, FakeDNS, or ApateDNS, the reason here is to check if the C2 server still active, or any other C2 for that matter. Only the dropper file rthfy.exe been downloaded

Stage 2: Dropper

rthfy.exe is the dropper in this context, which is wrapper to remcos.exe aka the RAT. It’s a .NET 32-bit compiled executable, which is not different than the previous samples that been analyzed in [2]. However, the attacker ‘which I highly suspect is a different person from the one in the previous stage for the following reason’ have used highly obfuscation techniques for anti-debugging purposes. When disassembling the file in dnSpy, it appears to be that almost every function, class, objects, and arrays of the code’s been scrambled. I couldn’t decide which token to use in de4dot in order to clear, but auto clearing helped a bit and got better results to reach the wrapped binaries.

At early debugging stages it’s easy to spot and dump a malicious DLL. However, I didn’t fully analyze this artifact, but recent report [4] and quick google search can show its malicious purposes.

File NameSHA265
SHCore1.dll49dc26861fffee2f6440e56a10b7086ea305d2f16bb9e27ba3e08b9893557f86
Table -3- dumped DLL

SHCore1.dllwhich goes by the name of pTcW.dll from dnSpy point of view!’ helped to locate the cipher algorithm RijndaelManaged. However, I didn’t take full advantage of this finding to de-obfuscate the code because the very file that carries remcos.exe comes just right after couple of Step- into and Step-over and the rest of indicators is just clear text.

When dumping 4O0O in (Figure -7-) ‘which has the MZ header’ and analyzing it separately and checking resources section we can find it carries two binaries: remcos.exe and Wscript.exe (Figure -8-). Wscript has Powershell script that deploys the RAT. But more on that later in the third stage.

Coming snaps wraps up the second staged of this analysis which shows the persistent mechanism used in this attack and execution by calling AddInProcess32.exe.

Stage 3: the RAT

Since this an evasion tool, and there is pro version of it. I’ve took different approach when analyzing remcos.exe which is more of developed hypothesis based on the encountered API calls listed in (Table-4-). To put it simply I was expecting Code Injection and API Hooking to evade detection for three good reasons: –

  1. This RAT could be packed with another code that inject itself into other processes. More of persistent than the very RAT itself.
  2. It’s harder to spot which process to look for in static analysis because the process list might vary so the only way to find out is during debugging. Based on my attempts there’re anti-debugging techniques that makes it difficult to find out.
  3. Code injection, when combined with some form of hooking can also be used to implement a user-mode rootkit!
APIremcos.exe imports
CreateToolhelp32SnapshotFound
OpenProcessFound
VirtualAllocExFound
WriteProcessMemoryFound
CreateRemoteThreadNot Found
Table -4- API calls to implement Code Injection

The combination of those API calls is a secret recipe for Code Injection technique. However, with the very important API (CreateRemoteThread) ‘which is the mysterious process that’s going to be infected‘ not found in this very sample I dropped the attempts on this approach and continued to the rest of the analysis with terrible disappointment! However, another successful approach to find out if it inject a process or not would involve memory dumping and using Volatility.

The usual analysis

I’ve not got much more indicators between static and dynamic analysis of remcos.exe, and there’s not been major changes than the previous analysis [2][3]. Despite, it doesn’t hurt to try, there still anti-debugging techniques as mentioned above. The only variable is the C2 server! and probably the cipher method attacker/tool is using in this version when encrypting the traffic sent to the C2 server.

Figure -12- remcos.exe and its keylogger

When debugging remcos.exe using x32dbg, tried different breakpoints techniques of API calls such as virtualAlloc and virtualProtect, but couldn’t spot useful indicators other than the given. However, the only breakpoint worked for me to extract C2 server is by breaking into msvcrt.dll.free

Finally, As persistent mechanism the infected RAT stays in the register (HKCU\Software\Microsoft\Windows\CurrentVersion\Run)

References

[1] Remcos malware sample – https://www.malware-traffic-analysis.net/2021/01/06/index.html

[2] New Variant of Remcos RAT observed in the wild, Oct 2019https://www.fortinet.com/blog/threat-research/new-variant-of-remcos-rat-observed-in-the-wild

[3] Analysis: New Remcos RAT Arrives Via Phishing Email, Aug 2019 https://www.trendmicro.com/en_us/research/19/h/analysis-new-remcos-rat-arrives-via-phishing-email.html

[4] MalwareBazaar DB – https://bazaar.abuse.ch/sample/9fad68bbaba3bcd69e3b8100eb5c035ea2caf59e0f9115e36667a62b2dce84bb/#intel