The sample is detected by a few antivirus products when it was initially seen.

MD5: c16f6825fd1dc4795761c211adf4616a

This sample uses process hollowing to unpack itself and execute in the context of svchost. It uses the following sequence of api calls to inject its image into svchost and start executing:

->CreateProcessA

->ZwAllocateVirtualMemory

->ZwWriteVirtualMemory

->ZwSetContextThread

->ZwResumeThread

Following is the MD5 hash of the unpacked sample:

MD5 :396b28833ba95d54b49c037200ff7f42

The unpacked sample seems to belong to an unknown malware family. At the time of the analysis only a small number of AV vendors detected it through heuristics. This could be an indication of a targeted attack.

wpsF29.tmp

Fig: Virustotal Results for unpacked file

Upon execution the malware checks its presence in the system using a mutex. The mutex name is in following format “Global\phil\machine_identifier”.

The malware loads the API SystemFunction036 from advapi32, which effectively resolves to RtlGenRandom. It is used to generate random values, for filename generation or random time delays.

wpsF3A.tmp

Fig:SystemFunction036 api

The malware creates a copy of itself with a random name in the start menu. The random name is generated by SystemFunction036 api .

wpsF3B.tmp

The malware collects data from the infected system and sends it to the C&C server after a random time delay. The time delay is in a range of around 10 minutes. This is suspected to be a sandbox-evasion technique or to avoid triggering alarms at a perimeter security solution.

wpsF4B.tmp

Fig : C&C communication after after sleep in loop

When communicating with the C&C server, the malware generates a random URL in the following format:

POST /ijluiipi.php?ozuvwik={machine identifier} + {b64 encoded data}

wpsF4C.tmp

Fig : example URLs

The strings used in the URLs are generated by its custom algorithm

wpsF4D.tmp

Fig: part of custom URL generation algorithm

The network traffic is in the following format

wpsF5E.tmp

Fig: C&C traffic

The malware collects user information from the infected system and send it to its C&C. The data includes the OS version, the computer name and the user name of the logged-on user. This behavior is typical for reconnaissance malware, as this data is useful in a second stage attack of a targeted attack.

 

wpsF6E.tmp

Fig: Collection of user information

Also, the malware is grabbing screenshots, which are useful for the attacker to determine which applications are being used on an infected machine.

 

wpsF6F.tmp

Fig: Screenshot generation

After data exfiltration the malware waits for commands from the C&C server. The C&C server can issue commands to instruct the malware to do the following.

image

The following code shows how it processes the response from the server.

v3 = result;
if ( result )
{
if ( uBytes )
{
v4 = DecryptData((int)&unk_404250, dword_404290, (int)result, uBytes, (DWORD)&pdwDataLen);
result = LocalFree__(v3);
if ( v4 )
{
v5 = pdwDataLen;
if ( pdwDataLen )
{
serverReply = v4;
if ( (signed int)pdwDataLen > 0 )
{
while ( 1 )
{
if ( !*(_BYTE *)serverReply )
goto LABEL_23;
if ( *(_BYTE *)serverReply == 2 )
{
GetComputerInformation();
goto LABEL_21;
}
if ( *(_BYTE *)serverReply == 3 )
{
EnumerateProcess();
goto LABEL_21;
}
if ( *(_BYTE *)serverReply == 4 )
{
v7 = *(_DWORD *)((char *)serverReply + 1);
serverReply = (char *)serverReply + 5;
v8 = ((-5 – v7 + v5) & 0x80000000u) != 0;
v5 += -5 – v7;
pdwDataLen = v5;
if ( !v8 )
{
CreateFileAndExecute(serverReply, v7);
v5 = pdwDataLen;
serverReply = (char *)serverReply + v7;
}
LABEL_17:
v9 = *(_DWORD *)((char *)serverReply + 1);
serverReply = (char *)serverReply + 5;
v8 = ((-5 – v9 + v5) & 0x80000000u) != 0;
v5 += -5 – v9;
pdwDataLen = v5;
if ( !v8 )
{
UpdateSelf(serverReply, v9);
v5 = pdwDataLen;
serverReply = (char *)serverReply + v9;
}
goto LABEL_22;
}
if ( *(_BYTE *)serverReply == 5 )
goto LABEL_17;
if ( *(_BYTE *)serverReply == 6 )
break;
if ( *(_BYTE *)serverReply == 7 )
{
GetScreenshots();
LABEL_21:
++serverReply;
v5 = pdwDataLen– – 1;
}
LABEL_22:
if ( (signed int)v5 <= 0 )
goto LABEL_23;
}
DeleteFile();

Analysis of the Exploit Kit

Rig exploit kit is involved in the exploitation process which uses flash targeting CVE 2015-5122 (flash 0 day disclosed via the HackingTeam leak) to distribute the malware. This is the landing page of the exploit kit:

wpsF80.tmp

Fig: Landing page of rig exploit kit

The exploit kit then redirects to flash exploit.

wpsF81.tmp

Fig: Flash exploit from the exploit kit

The exploit is meant for  ‘use after free’ vulnerability in DisplayObject.opaqueBackground .  The exploit  creates Textline object and then triggering custom valueof function method defined in its own class by setting textline to opaqueBackgroud.

The valueof function frees TextLine object by recursively calling recreateTextLine  and returns new vector object of length 0x62 , during return the value is modified to 0x6a.

Then it searches for corrupted vector by length and overwrites adjacent vector length with value of 0x4000000 triggering exploitation process.

wpsF92.tmp

Fig:  deobfuscated flash

Due to the nature of the malware we assume this to be a first-stage attack, attempting to target banking customers of UniCredit in Ukraine. The malware is designed to identify the infected machine, its owner and running applications and can download and execute second-stage malware. We were not able to obtain any second stage attack malicious binaries.  The attack clearly shows that cyber criminals are considerably fast in incorporating newly published exploits into their repertoire.

Thanks to Sandeep Kumar Mandhotra and Paul Kimayong and the rest of Cyphort Labs for their help in analyzing this sample.