Research by: Niv Asraf
Abstract
In the last two months, Check Point researchers encountered a new large-scale phishing campaign that recently targeted more than 40 prominent companies across multiple industries, in Colombia. The attackers’ objective was to discreetly install the notorious “Remcos” malware on victims’ computers. Remcos, a sophisticated “Swiss Army Knife” RAT, grants attackers full control over the infected computer and can be used in a variety of attacks. Common consequences of a Remcos infection include data theft, follow-up infections, and account takeover. In our report, we delve into the attack intricacies and highlight the stealthy techniques employed by the malicious actors.
Attack Flow
- Fraudulent Email:
The attackers initiated the campaign by sending deceptive emails allegedly from trusted entities, including reputable financial institutions and corporations operating within Colombia. These malicious emails were crafted to appear genuine, often containing urgent notifications, reports of overdue debts, or enticing offers.
- Email Contains an Archive File:
The phishing email contains an attachment that appears to be a harmless archive file, such as ZIP, RAR or TGZ. The attachment label states that it contains important documents, invoices, or other enticing information to encourage the recipients to open it.
- Highly Obfuscated BAT File with PowerShell Commands:
The archive file contains a highly obfuscated Batch (BAT) file. Upon execution, the BAT file runs PowerShell commands which are also heavily obfuscated. This multi-layer obfuscation makes it difficult for security solutions to detect and analyze the malicious payload.
- Loading .NET Modules:
After the PowerShell commands are deciphered, they load two .NET modules into memory. These modules are essential for the subsequent stages of the attack.
- First .NET Module: Evasion and Unhooking:
The first .NET module’s primary purpose is to evade detection and unhook any security mechanisms present in the targeted system. By removing or bypassing security hooks, the attackers increase the malware’s chances of remaining undetected and enable it to operate stealthily.
- Second .NET Module: Loading “LoadPE” and Remcos:
The second .NET module dynamically loads another component called “LoadPE” from the file resources. “LoadPE” is responsible for reflective loading, a technique that allows the loading of a Portable Executable (PE) file (in this case, the Remcos malware) directly into memory without the need for it to be stored on the disk.
- Reflective Loading with “LoadPE”:
Using the “LoadPE” component, the attackers load the final payload, the Remcos malware, directly from their resources into the memory. This reflective loading technique further enhances the malware’s ability to evade traditional antivirus and endpoint security solutions, as it bypasses standard file-based detection mechanisms.
- The Final Payload: Remcos – Swiss Army Knife RAT:
With the successful loading of the Remcos malware into memory, the attack is now complete. Remcos, a potent Remote Administration Tool (RAT), grants the attackers full control over the compromised system. It serves as a Swiss Army Knife for the attackers, allowing them to execute a wide range of malicious activities, including unauthorized access, data exfiltration, keylogging, remote surveillance, and more.
Technical Analysis
In the following sections, we examine the technical aspects of the observed issues. We focus on the malware’s evasion techniques and the deobfuscation process we employed to uncover the true nature of the BAT and .NET modules.
Our analysis starts with the malicious BAT file from attack chain stage 3 above.
After deobfuscating parts of the BAT file code with a Python script, the only thing we’re interested in is the last two lines of code:
Figure 4:The last two lines of deobfuscated BAT file.
The first line is responsible for copying the PowerShell executable to the current folder, abusing a double extension in the filename in order to hide the true file type.
And the second line of code looks like a heavily obfuscated PowerShell code.
After we organized and deobfuscated the PowerShell code, this is what we got:
Figure 5: Deobfuscated PowerShell code.
There are two functions here:
- “Zoskj” is responsible for decrypting the payload using AES CBC mode.
- “oPueH” uses GZIP to decompress it.
The flow is to first decode the Base64, and then decrypt it using AES. The last step is to decompress it.
AES key: Bh25J//GchqJk6Loyw9E05onwOgPl+4pjflSE6q18Hk=
AES IV: dQVwOVWNZWJ4TULVM0QMqQ==
Finally, after resolving the two .NET executables, they are both loaded in the memory:
Figure 6: Load 2 .NET executables to the memory
Figure 6: Load 2 .NET executables to the memory
We wanted to see why the attackers split the payload into two .NET executables and if there is a meaning to the order in which they are loaded.
Looking at the first .NET executable, we can see that it is highly obfuscated and almost unreadable.
Figure 7: First .NET obfuscated executable.
While this obfuscation is unknown, we can still use “de4dot” to make it a little bit more readable and then perform further deobfuscation.
de4dot is an open source (GPLv3) .NET deobfuscator and unpacker written in C#.
Figure 8: First .NET obfuscated executable after using de4dot.
The prominent pattern we observed involves deliberately enlarging the size of the code making it more complicated by extensively using Math.Abs/Min methods and adding numerous parentheses. Fortunately, we do not need to perform actual calculations; the values inside these methods directly serve as the final parameters passed into the “smethods_*” functions.
The first interesting thing we noticed here is the unknown strings (outlined in red in Figure 8) that are always passed into “smethod_0”. From this we understand that it is probably a string decryption function.
Looking at the function itself, we can see that only the string_0 and int_1 arguments are being used in the “for” loop, which is the only part of the code that is relevant here.
Basically, the function takes each “char” from the strings, turns it into an int and subtracts from it the int_1 argument, then converts the resulting value to char and appends it to the “stringBuilder”.
We created our own string decryption method in Python:
Figure 10: String decryption method in Python.
In the Figure 10 example, the return value is “ntdll.dll”.
So now, we can decrypt all unknown strings.
In addition, before the “Main” function executes, we see a lot of dynamically resolved functions assigned to delegated pointer variables to use in the code.
If we decrypt those strings, we can understand what the functions are, and rename the obfuscated delegated names.
Figure 11: Example of the “CloseHandle” function pointer being assigned.
After resolving and renaming, we get these function variables:
Figure 12: Decrypted delegated function pointers.
Now that we decrypted all the pointers, we can reverse-engineer the other methods and understand the flow of the main function.
Let’s analyze the function that receives the decrypted string “ntdll.dll”.
Figure 13: Choose the right ntdll based on IsWow64Process.
Looking at the first chunk of code, we can see two encrypted strings which translate to:
“C:\Windows\System32\” and “C:\Windows\SysWOW64”
We also see a delegated function pointer that we resolved earlier, IsWow64Process.
This checks whether the process runs under wow64, so we can use the right ntdll to read from the disk.
Figure 14: Unhooking DLL.
Although this function is still obfuscated, we can analyze and understand the code’s purpose, which is unhooking DLLs that are received as an argument to the function.
This is what happens here:
- Get a handle to the already-hooked library.
- Map a fresh copy of the relevant DLL into memory.
- Replace the .text section of the hooked DLL with the new one from the disk.
Figure 15: Unhooking.
VirtualProtect is used to change the .text section protection, using memcpy to copy the new unhooked section, and finally return to the old protection.
Now we can safely change the function name to UnhookModule.
This is the last major function of this executable:
Figure 16: Patching functions in memory with code that returns an error code.
This function takes a few arguments: Dll Name, Function Name, and a Byte Sequence.
It is responsible for patching functions in memory with code that returns an error code: 0x80070057 “The parameter is incorrect”.
To summarize, this is the first .NET Main Functionality:
- Unhooking kernel32.dll
- Unhooking ntdll.dll
- Patching the amsi.dll AmsiScanBuffer function to return “The parameter is incorrect” code (0x80070057)
- Patching the ntdll.dll EtwEventWrite function to return “The parameter is incorrect” code (0x80070057)
The second .NET is also heavily obfuscated but now the code size is much smaller. In addition, now that we understand the way the obfuscation works, it is much easier to understand its content.
Figure 17: Reversed and deobfuscated second .NET module.
To summarize, this is the second .NET Main Functionality:
- Check if there is a debugger.
- Use PowerShell to wait for the process to end and then delete the main module file.
- Load two additional files from the resources:
- Remcos malware
- LoadPE .NET executable
At the end of the Main function, the final payload, Remcos, is assigned to the “array” variable and then is passed as an argument to another invoked .NET executable, the “LoadPE” exe, which is responsible for getting an executable as an argument and loading it using reflective loading.
As we mentioned earlier in this report, reflective loading is used to dynamically load a library or executable directly into memory without relying on the standard operating system mechanisms for loading files from the disk.
In malware, reflective loading is often employed as a stealthy way to execute malicious code without writing any files to the disk. This makes it harder for traditional security tools to detect the presence of the malware as there are no files that can be scanned or monitored. Reflective loading also makes it harder to identify and analyze the malicious code.
The third LoadPE .NET executable is not obfuscated at all, which means we can easily reverse-engineer and understand what it’s used for.
These are its functions:
Figure 18: LoadPE .NET functions.
The final payload, the Remcos malware, stores its encrypted configuration file, called “SETTING”, in the resources.
We can easily see the configuration in memory:
Figure 19: Remcos configuration in memory.
Summary of the Remcos configuration:
Host:Port:Password: “192[.]161[.]184[.]21:24050:1”
Assigned name: “Vps”
Copy file: “remcos.exe”
Startup value: “Remcos”
Mutex: “Rmcvps-JUECXT”
Keylog file: “vpslogs.dat”
Screenshot file: “Screenshots”
Audio folder: “MicRecords”
Copy folder: “Remcos”
Keylog folder: “vp”
Keylog file max size: “100000”
We wanted to see if our assumptions were correct, so we entered the word “password” and also ”xxxx” and “123123”, then checked the keylogging file. As you can see, we were right.
Figure 20: Keylogging in action.
Conclusion
Our analysis offers a glimpse into the intricate world of evasion techniques and deobfuscation procedures employed by attackers. By deciphering the hidden functionalities of the malicious BAT and .NET modules, we were able to shed light on the attack flow’s complexity. Understanding these technical intricacies is essential for enhancing cybersecurity defenses and devising effective countermeasures to protect against such advanced phishing campaigns.
Check Point customers remain protected from the threats described in this research.
Check Point’s Threat Emulation provides comprehensive coverage of attack tactics, file types, and operating systems and has developed and deployed a signature to detect and protect customers against threats described in this research.
Threat Emulation:
Technique.Win.Unhooking.B
Technique.Win.WrongFileExt.A
Technique.Win.UnhookingNtdll.A
IOCs
C2 IOC:
192[.]161[.]184[.]21
BAT IOC’s:
dbc8cd0d565c9fa45a0f0ce030f609cfbc8dcc49
747c2466b4f4b5024f321a07fca597824d2483f8
3903cd20c6e72582f0ce3457a8964c6d9bc7496d
091a54d15376e86860ed52f3dcb5d3ded457e669
5d41cad361e530512a4bc8f394f5447fdcd19c1b
66e261009a745aeb0ed753cc920fca12880d5153
6bd967409c612466686e60dd409183a014171bf4
84668e4bb3b9366a8fd0856a6dc2a76a341589db
879b86cdf85c67b99c2f45afbaba8e4967a36065
0f0e747e23c98467bf825f8ef0dd1ab2eacb1169
1b9d6935421026676f2e39332894e61406768100
4d83ca1c2133425e1f87ea4729f40f17beeac8e2
5183b062a48926e20deef57a4d1819be62985803
796b5b5f2a9bffb777b46066e7167813dc53d344
9ec5ece2add690e3bca1a7ef84a73e10e326f39f
e543fd34e50bba41b422095dae1582d3e90718a3
RAR IOC’s:
ef1cc1750f5f580aa9338b8c5c5125cfd8406f7b
06c4ae8f298943340466a5dd1a6d44491349dc89
cf175cf4550280e43c6b094561fbe2925808a86e
1af2877ea0f103c0eb7a022616274b06dff387b1
30c4ede9a6f31c88b2ae1c0934a6be2dd85c4fcb
3b1d15c94f8a444cdeded4cb1fdc67835a3eb22f
4ad0661ce27ad4e738fac9df6399dade735aab75
59358571cc8679f945477d4616b853081e90f128
a0e0dd39ea5af2fc05fa0381d7f690840f726237
a738e73eb43b2b13d571bbec921364ef7c0fe89b
c464353ea1206bf98d74294846d44dcc77abd266
de47ac28807ef5ddf0baac89b833d629365b69fa
f0225203ef06dd74c5619e787bcb842bfee21715
f637469861d7933ca1e0b5940cd65008fe852ae6
07106f6c27f3f9111f6772be99c13a6d4c9086f9
0eb80eca7ce0ce7eb2247e5bc4f1fca0050c6c9a
10b4b1042cecb095b4290b585f3813d962363b80
114fdf1d2bb70d0701c3843a1ef6b85c312cb293
137424047b1b536d84fa67b57af530c2d0f7e103
1d50d5066bb37491b56c05b196a569740b1dfae0
1e7535f915f5feaa3efa9454595143287620d2dd
1f617be60cf587d9b4148b99330fe41ec13f9a0f
21f1c5fec49abbe72669d0b24332c1dc19655afc
273aad18bc2b709926857dfeb2004a6023e3801f
289da12f6a23df7ceec631db4222138934973f17
2990974b141cbd7f93331dc7ae99c8ce00768829
2cc559b88c1417bb706c1bdf2da899c4a906b96f
2e03467eb027b820d6414377c4cde1faed41f53d
2f82901f0467e2c1ca4c876f0718ab0054ee8665
2facc6928c6e6e1d934c342f8d0ecdb590227f6e
3030026cf11a87685b53b4339de628012a4ebb8c
32923f96042f5288a47bf44e6a70a2ad1a88e40e
33b3128ec42305c9df027a1b27ec776f87549178
3de22926115f4232b1fed26a4ea45dc9c8ad551f
3f92880d212006e2812dd11b945893616305bd65
4094f97258442bc1df5047fbd08b2e4cdf707788
432dc5cf8b64c591b8d5d80c6c94879b41fbcb25
446343828f9ea0c3da92e88401b06dcad2564efc
476f4ebc66a430e5211a45d3fd987e06adbb87e1
4a76ba6b31fb4afded84a31aac37961333221d4e
52ec5ca7ebfed9fd46e6995f295da9b58f8d0db7
56b41bfebfefe17fdb3f983c88b6ba1e509f4673
56fa7cece82be67830de5fda699fb4e8fb8c8ab8
5eb95c21bc3171b7e7a72d015d632d7cd92eeff5
631ce6b5704cba5087d8bb1f7ec294f1838f875a
6b6b98ce05a28d2089f40f814bd488f9d044b2ac
6d59089e1bd588e5dff8ddc22a7b5d489bb23099
6fa5b9e94f0ad29807fdf54fe686407988d22675
70a82522c0ff3d0ff1034cb75eb4c655fee8f16d
72db30e960256be5723cf497671af031b99da702
78fc5666b1599fb45a8de9ead18c0c88762b3fb0
7a982b71d4f3c9c280922b3a7446d5b37aea9ea5
7f034c654586f36718b0d8e2cf20898a2434b9be
7f3c4ea235a975d7373263b9122bc5f1b4014dc7
8136a49c3688c2205936dd87bb9fb0713969e74c
841e5093c48ff58949956a76638928f3a70dea09
85fda5b03b10c5ca740d8b402623e74bf47a1459
8a8b6182bf00f584446d8f5251fc10bc3e634e41
8f92c596c39bb90ede4434984e20ce9910b15161
90a7c84ca422b2a03d5be16b90805bb298f31ddb
90b44246a15df7ce331475cecdb32b907958c017
9417bb08836439b05e950bc397a7fcc1b6d65c3e
95aa52f8d8c9e2cc3f7e408a12c9b547efabef5f
9aaf87c7bd580bcde421bd45149534e1e94e5052
a3e4b4f0f6572b50ed72683ebef08d4f3ae9b28e
a4f5c257bbc2d231b62c54dbf1948475eeeae01d
a7a22b1637710ee68fe966c72a1efbef4b04f94f
afcc5ffd986c8a3097644db452f478318df175e3
b37b50f13fe9c7e749b3ccdc5cb27a5c75f563e8
b95f28e3e371c4e3bcfaf5d125b108ce0882492e
c184116dc08189023ca32d80a5f683c5230aa2d5
c7fdc4e9085dd5c9277fae611a5346e1ed822e05
cc136bc74eaa921fb852140b9d9fda9ea9bc9d57
ce7acbe0e521474fdcc337e6b6e93bd45e1f0e01
d01aeb3b10ed5f39623eaa2be7a5d45b4eb9daf3
d2cace3f1a8f7399b56df20af8c6cc73721c7437
d31f0105aaf6a63c9e74474c25a58fd876efa7a0
d5d6ca1af6f85497a600dec6068a179999f53ebe
d67ebf4f01fc1c6cb1089402cd4a75b4afae2907
d833ec0f14bfc04ba0739387844e6971d879fd73
d8d1840820cb74e3a40d09e6123aba21735fc0c4
d8e9eb2b5db47efd11066826c21e0300610d1871
db936d1615f6bb43c70af75b48f9a188ddd616b4
dc5898884939ac85426c75c053b4248fbc157d59
de89d77a580333433dad82418e94277288eeac3c
e08d2d4008b7aef450428400516c6642ddac7ccd
e2dfed7211a9277b4e43259cededb73b2bed90ce
e8162589c2594823a9847495389d6d3edeaea679
e95f2c4cd4bc70c8571c951ac7bc0578d22847aa
ee25058728ee4b1fcbe45c39d06d8b577f5d3cd2
f185ce72e88cafcf94ad96f5f71278daa2a5c1e6
f3b5d39e69712947dcdc71d5738518caf53a8d98
f4a1652c439b0a46218f08a11c913cab04895d84
fb52f09ca044e707dc435417c8fdd3a9e9949bee
The post Guarding Against the Unseen: Investigating a Stealthy Remcos Malware Attack on Colombian Firms appeared first on Check Point Research.
Article Link: Guarding Against the Unseen: Investigating a Stealthy Remcos Malware Attack on Colombian Firms - Check Point Research