A Not-So Civic Duty: Asprox Botnet Campaign Spreads Court Dates and Malware

Executive Summary

FireEye Labs has been tracking a recent spike in malicious email detections that we attribute to a campaign that began in 2013. While malicious email campaigns are nothing new, this one is significant in that we are observing mass-targeting attackers adopting the malware evasion methods pioneered by the stealthier APT attackers. And this is certainly a high-volume business, with anywhere from a few hundred to ten thousand malicious emails sent daily – usually distributing between 50 and 500,000 emails per outbreak.

Through the FireEye Dynamic Threat Intelligence (DTI) cloud, FireEye Labs discovered that each and every major spike in email blasts brought a change in the attributes of their attack. These changes have made it difficult for anti-virus, IPS, firewalls and file-based sandboxes to keep up with the malware and effectively protect endpoints from infection. Worse, if past is prologue, we can expect other malicious, mass-targeting email operators to adopt this approach to bypass traditional defenses.

This blog will cover the trends of the campaign, as well as provide a short technical analysis of the payload.

Campaign Details

fig1

Figure 1: Attack Architecture

The campaign first appeared in late December of 2013 and has since been seen in fairly cyclical patterns each month. It appears that the threat actors behind this campaign are fairly responsive to published blogs and reports surrounding their malware techniques, tweaking their malware accordingly to continuously try and evade detection with success.

In late 2013, malware labeled as Kuluoz, the specific spam component of the Asprox botnet, was discovered to be the main payload of what would become the first malicious email campaign. Since then, the threat actors have continuously tweaked the malware by changing its hardcoded strings, remote access commands, and encryption keys.

Previously, Asprox malicious email campaigns targeted various industries in multiple countries and included a URL link in the body. The current version of Asprox includes a simple zipped email attachment that contains the malicious payload “exe.” Figure 2 below represents a sample message while Figure 3 is an example of the various court-related email headers used in the campaign.

fig2

Figure 2 Email Sample

fig3

Figure 3 Email Headers

Some of the recurring campaign that Asporox used includes themes focused around airline tickets, postal services and license keys. In recent months however, the court notice and court request-themed emails appear to be the most successful phishing scheme theme for the campaign.

The following list contains examples of email subject variations, specifically for the court notice theme:

  • Urgent court notice
  • Notice to Appear in Court
  • Notice of appearance in court
  • Warrant to appear
  • Pretrial notice
  • Court hearing notice
  • Hearing of your case
  • Mandatory court appearance

The campaign appeared to increase in volume during the month of May. Figure 4 shows the increase in activity of Asprox compared to other crimewares towards the end of May specifically. Figure 5 highlights the regular monthly pattern of overall malicious emails. In comparison, Figure 6 is a compilation of all the hits from our analytics.

fig4

Figure 4 Worldwide Crimeware Activity

fig5

Figure 5 Overall Asprox Botnet tracking

fig6

Figure 6 Asprox Botnet Activity Unique Samples

These malicious email campaign spikes revealed that FireEye appliances, with the support of DTI cloud, were able to provide a full picture of the campaign (blue), while only a fraction of the emailed malware samples could be detected by various Anti-Virus vendors (yellow).

fig7

Figure 7 FireEye Detection vs. Anti-Virus Detection

By the end of May, we observed a big spike on the unique binaries associated with this malicious activity. Compared to the previous days where malware authors used just 10-40 unique MD5s or less per day, we saw about 6400 unique MD5s sent out on May 29th. That is a 16,000% increase in unique MD5s over the usual malicious email campaign we’d observed. Compared to other recent email campaigns, Asprox uses a volume of unique samples for its campaign.

fig8

Figure 8 Asprox Campaign Unique Sample Tracking

fig9

Figure 9 Geographical Distribution of the Campaign

fig10

Figure 10 Distribution of Industries Affected

Brief Technical Analysis

fig11

Figure 11 Attack Architecture

Infiltration

The infiltration phase consists of the victim receiving a phishing email with a zipped attachment containing the malware payload disguised as an Office document. Figure 11 is an example of one of the more recent phishing attempts.

fig12

Figure 12 Malware Payload Icon

Evasion

Once the victim executes the malicious payload, it begins to start an svchost.exe process and then injects its code into the newly created process. Once loaded into memory, the injected code is then unpacked as a DLL. Notice that Asprox uses a hardcoded mutex that can be found in its strings.

  1. Typical Mutex Generation
    1. “2GVWNQJz1″
  2. Create svchost.exe process
  3. Code injection into svchost.exe

Entrenchment

Once the dll is running in memory it then creates a copy of itself in the following location:

%LOCALAPPDATA%/[8 CHARACTERS].EXE

Example filename:

%LOCALAPPDATA%\lwftkkea.exe

It’s important to note that the process will first check itself in the startup registry key, so a compromised endpoint will have the following registry populated with the executable:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

Exfiltration/Communication

The malware uses various encryption techniques to communicate with the command and control (C2) nodes. The communication uses an RSA (i.e. PROV_RSA_FULL) encrypted SSL session using the Microsoft Base Cryptographic Provider while the payloads themselves are RC4 encrypted. Each sample uses a default hardcoded public key shown below.

Default Public Key

—-BEGIN PUBLIC KEY—-

MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDCUAUdLJ1rmxx+bAndp+Cz6+5I’

Kmgap2hn2df/UiVglAvvg2US9qbk65ixqw3dGN/9O9B30q5RD+xtZ6gl4ChBquqw

jwxzGTVqJeexn5RHjtFR9lmJMYIwzoc/kMG8e6C/GaS2FCgY8oBpcESVyT2woV7U

00SNFZ88nyVv33z9+wIDAQAB

—-END PUBLIC KEY—-

First Communication Packet

Bot ID RC4 Encrypted URL

POST /5DBA62A2529A51B506D197253469FA745E7634B4FC

HTTP/1.1

Accept: */*

Content-Type: application/x-www-form-urlencoded

User-Agent: <host useragent>

Host: <host ip>:443

Content-Length: 319

Cache-Control: no-cache

<knock><id>5DBA62A247BC1F72B98B545736DEA65A</id><group>0206s</group><src>3</src><transport>0</transport><time>1881051166</time><version>1537</version><status>0</status><debug>none<debug></knock>

C2 Commands

In comparison to the campaign at the end of 2013, the current campaign uses one of the newer versions of the Asprox family where threat actors added the command “ear.”

if ( wcsicmp(Str1, L”idl”) )

{

if ( wcsicmp(Str1, L”run”) )

{

if ( wcsicmp(Str1, L”rem”) )

{

if ( wcsicmp(Str1, L”ear”)

{

if ( wcsicmp(Str1, L”rdl”) )

{

if ( wcsicmp(Str1, L”red”) )

{

if ( !wcsicmp(Str1, L”upd”) )

C2 commands Description
idl This commands idles the process to wait for commands
run Download from a partner site and execute from a specified path
rem Remove itself
ear Download another executable and create autorun entry
rdl Download, inject into svchost, and run
upd Download and update
red Modify the registry

C2 Campaign Characteristics

fig13

For the two major malicious email campaign spikes in April and May of 2014, separate sets of C2 nodes were used for each major spike.

April

May-June

94.23.24.58 192.69.192.178
94.23.43.184 213.21.158.141
1.234.53.27 213.251.150.3
84.124.94.52 27.54.87.235
133.242.134.76 61.19.32.24
173.45.78.226 69.64.56.232
37.59.9.98 72.167.15.89
188.93.74.192 84.234.71.214
187.16.250.214 89.22.96.113
85.214.220.78 89.232.63.147
91.121.20.71
91.212.253.253
91.228.77.15

Conclusion

The data reveals that each of the Asprox botnet’s malicious email campaigns changes its method of luring victims and C2 domains, as well as the technical details on monthly intervals. And, with each new improvement, it becomes more difficult for traditional security methods to detect certain types of malware.

Acknowledgements:

Nart Villeneuve, Jessa dela Torre, and David Sancho. Asprox Reborn. Trend Micro. 2013. http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-asprox-reborn.pdf

DLL Side-Loading: Another Blind-Spot for Anti-Virus

Last month, I presented a talk at the RSA USA Conference on an increasingly popular threat vector called “Dynamic-Link Library Side-Loading” (DLL Side-Loading). As with many vulnerabilities, this exploit has existed for a rather long time and is the result of Microsoft looking to make binary updates easier for Windows developers through the Windows side-by-side (WinSxS) assembly feature.

Now, though, advanced persistent threat (APT) developers are using the innocuous DLL Side-Loading method to sneak malware past anti-virus (AV) scanners as the infected files run in-memory. In doing-so, the malicious payload is using a benign application to be built in memory, meaning that the malware does not sit running in the file system where AV scans take place. In the figure below, you can see an example of how this all plays out:

DLLpic

For a real-life example: in 2013, attackers exploited the executable originally developed by Fortune 50 company using this technique in a highly targeted attack. In such an attacks, the malware places a spoofed, malicious DLL file in a Windows’ WinSxS directory so that the operating system loaded the spoofed DLL instead of the legitimate file. Furthermore, because the file in-question was white-listed by hash in a public database, AV simply ignores it altogether.

In response to the growing use of DLL Side-Loading in APTs, we have developed a full paper that describes the history of DLL Side-Loading and its role in the malware and software engineering arenas which you can review here: https://www.fireeyesolution.com/resources/pdfs/fireeye-dll-sideloading.pdf

 

 

Targeted Attack Trend Alert: PlugX the Old Dog With a New Trick

FireEye Labs has discovered a targeted attack towards Chinese political rights activists. The targets appear to be members of social groups that are involved in the political rights movement in China. The email turned up after the attention received in Beijing during the 12th National People’s Congress and the 12th National Committee of the Chinese People’s Political Consultative Conference, which is the election of a new core of leadership of the Chinese government, to determine the future of China’s five-year development plan [1].

The email contains a weaponized attachment that utilizes the Windows Office CVE-2012-0158 exploit to drop the benign payload components and decoy document. The Remote Access Tool (RAT) PlugX itself is known as a combination of benign files that build the malicious execution. The Microsoft file OInfoP11.exe also known as “Office Data Provider for WBEM” is a certified file found in the National Software Reference Library (NIST) and is a component from Microsoft Office 2003 suite. For integrity checking endpoint protection, this file would be deemed as a valid clean file. In Windows 7+ distributions, the svchost.exe will require user interaction by displaying a UAC prompt only if UAC is enabled. Although in Windows XP distributions, this attack does not require user interaction. The major problem is that this file is subject to DLL Sideloading. In previous cases, PlugX has been utilizing similar DLL Sideloading prone files such as a McAfee binary called mcvsmap.exe [2], Intel’s hkcmd.exe [3], and NVIDIA’s NvSmart.exe [4]. In this case, OInfoP11.exe loads a DLL file named OInfo11.ocx (payload loader posing as an ActiveX DLL) that decompresses and decrypts the malicious payload OInfo11.ISO. This technique can be used to evade endpoint security solution that relies on binary signing. Traditional anti-virus (AV) solutions will have a hard time to identify the encrypted and compressed payload. At the time of writing of this blog, there is only 1 out of 46 AV vendors can detect the OInfo11.ocx file. Continue reading »