Sunday, February 3, 2019

Unknowncrypter, the crypter twin of Fudcrypt: another Crypter-as-a-Service for Java and JS

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 RAT5b7192be8956a0a6972cd493349fe2c58bc64529aa1f62b9f0e2eaebe65829be 
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


Sunday, January 27, 2019

Fudcrypt: the service to crypt Java RAT through VBS scripts and Houdini malware

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.