Last week I wrote about a Crypter-as-a-Service named Fudcrypt which obfuscates Java RATs in VBS scripts. However, this is not the only service being used by threat actors to deliver encrypted Java RATs.
A few days ago there was a new "The Story of Manuel’s Java RAT" which basically linked two different campaigns using same JRAT malware. In one of the campaigns there were JAR files attached to the emails, whereas in the other campaign the attachment were JS (JavaScript) dropping a JAR file. The JS campaign is the interesting part as this is linked to a Crypter-as-a-Service named Unknowcrypter.
Unknowcrypter and Fudcrypt are strongly linked and either the actor creating both services is the same or they are working together.
Unknowncrypter is announced in several underground forums as a crypter for Java and JS. There is even in Youtube some videos on how to use the crypter.
In order to use the service and encrypt Java/JS files it is necessary to use a windows application and a valid account.
The sample from the campaign "The Story of Manuel’s Java RAT" 5b7192be8956a0a6972cd493349fe2c58bc64529aa1f62b9f0e2eaebe65829be
is the perfect candidate to be dissected.
Looking at the JS code, the first interesting part is the "obfuscation" function for the payload.
The variable hp_pavilion is the final payload which it is base64 encoded.
It basically uses the same substitution mechanism than fudcrypt, but written in JS instead of VBS and using different characters and strings.
Below is the snippet code from fudcrypt:
After decoding the payload stored in hp_pavilion, there is again another round of base64 encoded strings, which are stored in LongText1 and LongText
LongText1 is just a base64 encoded and the output is a JS script which I will analyse later.
LongText is the malicious payload, the Java RAT, which it is base64 encoded but some characters needs to be swapped, in this case "#@>" with "A".
This is the exact same behaviour than in Fudcrypt:
Then, the script checks if Java Run Environment is installed. If not, this is download from hxxp://www.thegoldfingerinc[.]com/images/jre.zip
Fudcrypt does exactly the same and in the same manner. See the code from fudcrypt
Lastly, the Java RAT is made persistent via the Registry key "HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\ntfsmgr which it is the same exactly registry key name used by fudcrypt.
The remaining part is the script linked to the LongText1. This is script, after deobfuscation, leads to a JS script which is a worm name vjw0rm.
Although this code is not used, it has C2 capabilities.
To summarise: unknowncrypter and fudcrypter are the same crypter service but using to different script languages as output for the obfuscation. The only difference is the C2 capabilities which are gathered by two different malware, one for JS while the other is for VBS.
The analysis of the JavaRAT payload, which it is Adwind, is here
The existence of services to encrypt and obfuscate malware in order to avoid antivirus detection is nothing new at all. In this blog I wrote about a couple of services, qthelegend and qrypter, that obfuscate Java RATs like Adwind.
A few weeks back there was an interesting campaign against some financial institutions using some Java RAT and some VBS scripts. It turned out that this campaign used some crypt service named fudcrypt. This service is announced in several underground forums as "fully undetected crypt" service and used to have a website where it could be bought for a few dollars.
The are even some youtube videos on how to encrypt files with this crypt service. For example here.
The author of this malware claims that he is able to install Java JRE in victims which do not have Java installed so the JAR payload can be executed.
Although the main website fudcrypt[.]com is not anymore active, the service can still be bought via some underground forums.
In order to use the service and to obfuscated the payload, the author provides a windows application. This application checks for a valid license
As mentioned before Fudcrypt is still active as a service and some actors are using it so I'm going to analyse how it works with a recent sample
ef9c50fd15493937d5ee3366a58e41cd3ca1d9fb386fe578aea700c8f54f0f1a. This sample was detected only by a few AV when it was analysed three days ago:
The file is a VBS script which it is 929K and it has a variable named "pillow" which it is the payload.
The payload is in base64 encoded, but according to some functions in the code there are some characters that need to be swapped before decoding. This is "#(" with "m".
The base64 decoded payload is another VBS script which I've uploaded here
This script contains two other base64 encoded payloads stored in two variables: longText1 and longText.
Both of them are base64 encoded, however for the second one it is necessary (again) to swapped some characters:
It turns out that the second base64 encoded variable is a binary JAR file, which in essence is the final Java Rat payload. The JAR file is stored in %appdata% as ntfsmgr.jar. A copy of the file is here and a dynamic analysis is here. In essence, the payload is Adwind malware and the C2 is in jsbc-pcs.linkpc[.]net:1604
The code checks via some registry keys if Java is already installed. If it is not installed, a copy is downloaded from this URL: hxxp://www.thegoldfingerinc[.]com/images/jre.zip
Then, the dowloaded java is installed and persistence to run the Java RAT is pushed via the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Run
There is still one remaining script which I did not analyse yet. This is the one stored in longText1. This script again has a base64 encoded payload with leads to another VBS script. A copy of both VBS script are here and here
Looking at the last deobfuscate VBS script, the beginning of the script matches the Houdini Malware. Also the C2 pm2bitcoin[.]com is well known, however this C2 is not the one used, but goz.kingdaddy[.]pw.
The domain goz.kingdaddy[.]pw is not active but has been registered a few days ago
A good analysis on how the Houdini malware works was done 5 years ago by FireEye/Mandiant here.
In essence this crypt service is using some already known malware, Houdini, Although the final JAR payload is in the initial obfuscated VBS it would be possible that payload is pushed via the Houdini VBS script via the C2.
In a daily basis I see lot of Adwind malware trying to infect end users
Adwind is a multiplatform Remote Access Trojan (RAT) which has been in the wild for some time. In this Kasperky Blog post there is a good historical analysis.
In most of the cases Adwind is delivered as an attachment via email (as ZIP or JAR file), but it is not the only way. I've dealt with incidents involving Adwind where the infection vector was a malicious link.
Other potential infection vector is via weaponized MS office documents. Some of this weaponized document have really low detection rate, like the one above, which it is only detected by 20% of the Antivirus at the moment of this writing and 8 AV (from of a total of 60) when the file was originally reported
The malicious payload, a JAR file, is included in the MS office Document as an OLE object.
This can be seen doing some manual analysis on the file:
A Simple Use Case to detect the malware is to monitor any process spawned by MS Office, in this case it is a Java Process
In terms of persistence, the malware can be detected easily, as it creates an entry in the registry "HKCU\Software\Microsoft\Windows\CurrentVersion\Run " pointing to a java executable which it is allocated in the the AppData directory of the user:
This can be easily hunt with a remote PowerShell query, like the one below
Adwind malware kills massively processes relates to Antivirus and monitor tools, which can be also a good indicator for detection
To avoid those processes to be executed again the malware uses an interesting trick. It includes the processes in the registry key as 'debugger=svchost.exe' using the "Image File execution Option". This technique is described in this blog post
This can be spotted straight forward with a query, checking any registry imported from the AppData user folder, like the one above:
Another way is to monitor all the registry keys being set with debugger
IOC:
185.172.25.13
245addb0e7b0d9f63e8a63efb8c77ffdc4e39cb2ddbbe8a138f3203e7458caf5
