WSH RAT and the link to unknowcrypter and Fudcrypt

There are plenty of malspam campaigns using the the code "MT103" from SWIFT to claim some kind of payments. 

                                     




However, recently there was one in particular using some malicious JavaScript as an attachment quite interesting. Some samples of the campaign can be found here and here 

The payload in those campaigns delivered the malware "wsh RAT".  This malware family is quite new, however the actor behind is not new at all, but linked to some other crypters services mentioned in this blog.

Analysis of the code - overlap with Uknowncrypter and Fudcrypt

While I did the analyses of the sample here I found several interesting points which I will detail here.

The obfuscation mechanism used is very similar in terms of the 'algorithm' and base64 encoding to the one used in unknowcrypter and Fudcrypter 

The final decoded payload leads to some interesting indicators.

This code is similar  Vjw0rm  which is used by unknowcrypter. Also, the host "unknownsoft.duckdns[.]org" was used by uknowncrypter at some point.  

But the most interesting aspect is the skype ID "unknown.sales64"

The skype ID is linked to the domain http[:]//www.wshsoftware[.]site where WSH RAT is sold.

The capabilities of this RAT are described in the website:

A full video of the capabilities of this RAT is also linked in the main website

https://youtu.be/rdG16vk9qNQ

According to the video and some screenshots the malicious payload can be generated in VBS and JS

Unknowcrypter generates JavaScript code while Fudcrypt VBS code, however the code in essence was the same in both cases, as showed in the post here 

The domain wshsoftware[.]site has been registered with the email address stonexevans@gmail[.]com

This same email address was used to register the domain "fudcrypt[.]com" which was used to sell Fudcrypt service at some point

So "WSH RAT", "unknowcrypter" and "Fudcrypt" are linked between them

In the next blog I will dig into the code and capabilities of the malware

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: 

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 {
     meta:
      description = "Gozi C2 memory"
      author = "@Angelill0 -  Angel Alonso Parrizas"
      date = "2018-11-19"

   strings:
      
        $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

   condition:
        $s1 or $s2 or  $s3

}

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

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. 

@abuse.ch 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.

The strange case of Adwind embedded in a MS-DOS file

A few days ago there was a malspam campaign mimicking one bank and delivering a PDF file and some DOC files exploiting CVE-2017-11882










The PDF file contains several images and and two interesting URLs





The first URL, http://dropboox[.]ga clearly is a phishing link for Dropbox, however in this case it is not being used.

The other link, is still active by the time of writing this post, https://urlz[.]fr/6DWd,  redirects to http://mineralsconventionregistration[.]ca/Scann%20copy.z which it is a compressed file. In VT this file is being flagged: https://www.virustotal.com/#/file/670bca12bb20921b4689bb2651a8cc7b87840f31dbf729694027db4fb64e3296/detection




The first time I tried to detonate the file in several sandboxes it did not work, so I was interesting to understand a bit more. The file inside has .JAR extension, however the magic number for this file doesn't really correspond with the extension of the file, as it is MS-DOS




A first analysis of the file shows interesting things.  The beginning of the file is a MS-DOS file:


However, it contains several more files inside:




The analysis from previous tools seems is not accurate as one of the MS-DOS file has 7.2MB, however the total file is only around 800k. Checking with other tools, the analysis is different, for example, with foremost the MS-DOS files doesn't show





When unzipping the the .jar file, there is some warning :




I did a manual analysis on the file and as first look I even see some HTML, PHP and JavaScript code, right after the first MS-DOS code




When dumping the first PHP file, the content clearly is a phishing website to get passwords from email.




Then I forced my sandbox to detonate the file as JAR file, and ignoring the magic number, this worked and I could see they typical Adwind behaviour.








The connection to the Jrat C&C is 185.29.10.138:6060  (jrat138.duckdns.org). That IP is not new to me, as I have seen this IP linked to Qrat / Qrypter / Adwind in some analysis I i did in the past . 

As I said in the beginning, the file doesn't detonate in some sandboxes, due to how it is built. For example, this is the analysis from HA with no detonation

https://www.hybrid-analysis.com/sample/94f087e4f03d4c109db44e9c111e8a4c500ef619ccb5a4833b283495b9ecb23e?environmentId=100
Other sandboxes, detects that the extension doesn't match the magic number




Regarding the AV, it seems some of them detectes the HTML, in the beginning of the file, as phishing. While other detect it as Adwind




The behavior of the DOC files is very similar. However, instead of including the URLs in the PDF file,  CVE-2017-11882 is exploited to download the maliciuos file:




http://mineralsconventionregistration[.]ca/scan.hta

In the end, the final payload is exactly the same in bot cases, however the URL is not exactly the same:

http://mineralsconventionregistration[.]ca/scan.jar





Regardless of what the AV / Sandboxes detect, and what the magic number is,  when the user opens the file via the explorer, the file is executed like a normal Java file, hence it gets infected with Adwind. It seems that bad guys are trying with this techniques to by-pass some detection controls.


IOCs:

 http://dropboox[.]ga
185.29.10.138:6060  
jrat138.duckdns[.]org
http://mineralsconventionregistration[.]ca/scan.jar
http://mineralsconventionregistration[.]ca/scan.hta
1540f31ed4c2a721771dbc452b8feeaa
a9122eb1e0345568540ae6a9e35432cc
1540f31ed4c2a721771dbc452b8feeaa