Category Archives: FireEye

  • 0

Resolve security incidents quickly, efficiently and at scale

Category : FireEye

Your business is your top priority. At best, attacks are a distraction. At their worst, they can cripple your operations.

Mandiant, a FireEye company, has dedicated incident responders in over 30 countries to help you quickly investigate and thoroughly remediate attacks, so you can get back to what matters most: your business. Mandiant helps protect you with more than a decade of experience responding to thousands of incidents and conducting intrusion investigations.

Our consultants combine their expertise with industry-leading threat intelligence and network and endpoint technology to help you with a wide range of activities — from technical response to crisis management. Whether you have 1,000 or 100,000 endpoints, our consultants can be up and running in a matter of hours, analyzing your networks for malicious activity.


  • 0

Behind the CARBANAK Backdoor

Category : FireEye

In this blog, we will take a closer look at the powerful, versatile backdoor known as CARBANAK (aka Anunak). Specifically, we will focus on the operational details of its use over the past few years, including its configuration, the minor variations observed from sample to sample, and its evolution. With these details, we will then draw some conclusions about the operators of CARBANAK. For some additional background on the CARBANAK backdoor, see the papers by Kaspersky and Group-IB and Fox-It.

Technical Analysis

Before we dive into the meat of this blog, a brief technical analysis of the backdoor is necessary to provide some context. CARBANAK is a full-featured backdoor with data-stealing capabilities and a plugin architecture. Some of its capabilities include key logging, desktop video capture, VNC, HTTP form grabbing, file system management, file transfer, TCP tunneling, HTTP proxy, OS destruction, POS and Outlook data theft and reverse shell. Most of these data-stealing capabilities were present in the oldest variants of CARBANAK that we have seen and some were added over time.

Monitoring Threads

The backdoor may optionally start one or more threads that perform continuous monitoring for various purposes, as described in Table 1.

Thread Name Description
Key logger Logs key strokes for configured processes and sends them to the command and control (C2) server
Form grabber Monitors HTTP traffic for form data and sends it to the C2 server
POS monitor Monitors for changes to logs stored in C:\NSB\Coalition\Logs and nsb.pos.client.log and sends parsed data to the C2 server
PST monitor Searches recursively for newly created Outlook personal storage table (PST) files within user directories and sends them to the C2 server
HTTP proxy monitor Monitors HTTP traffic for requests sent to HTTP proxies, saves the proxy address and credentials for future use

Table 1: Monitoring threads


In addition to its file management capabilities, this data-stealing backdoor supports 34 commands that can be received from the C2 server. After decryption, these 34 commands are plain text with parameters that are space delimited much like a command line. The command and parameter names are hashed before being compared by the binary, making it difficult to recover the original names of commands and parameters. Table 2 lists these commands.

Command Hash Command Name Description
0x0AA37987 loadconfig Runs each command specified in the configuration file (see the Configuration section).
0x007AA8A5 state Updates the state value (see the Configuration section).
0x007CFABF video Desktop video recording
0x06E533C4 download Downloads executable and injects into new process
0x00684509 ammyy Ammyy Admin tool
0x07C6A8A5 update Updates self
0x0B22A5A7 Add/Update klgconfig (analysis incomplete)
0x0B77F949 httpproxy Starts HTTP proxy
0x07203363 killos Renders computer unbootable by wiping the MBR
0x078B9664 reboot Reboots the operating system
0x07BC54BC tunnel Creates a network tunnel
0x07B40571 adminka Adds new C2 server or proxy address for pseudo-HTTP protocol
0x079C9CC2 server Adds new C2 server for custom binary protocol
0x0007C9C2 user Creates or deletes Windows user account
0x000078B0 rdp Enables concurrent RDP (analysis incomplete)
0x079BAC85 secure Adds Notification Package (analysis incomplete)
0x00006ABC del Deletes file or service
0x0A89AF94 startcmd Adds command to the configuration file (see the Configuration section)
0x079C53BD runmem Downloads executable and injects directly into new process
0x0F4C3903 logonpasswords Send Windows accounts details to the C2 server
0x0BC205E4 screenshot Takes a screenshot of the desktop and sends it to the C2 server
0x007A2BC0 sleep Backdoor sleeps until specified date
0x0006BC6C dupl Unknown
0x04ACAFC3 Upload files to the C2 server
0x00007D43 vnc Runs VNC plugin
0x09C4D055 runfile Runs specified executable file
0x02032914 killbot Uninstalls backdoor
0x08069613 listprocess Returns list of running processes to the C2 server
0x073BE023 plugins Change C2 protocol used by plugins
0x0B0603B4 Download and execute shellcode from specified address
0x0B079F93 killprocess Terminates the first process found specified by name
0x00006A34 cmd Initiates a reverse shell to the C2 server
0x09C573C7 runplug Plugin control
0x08CB69DE Autorun Updates backdoor

Table 2: Supported Commands


A configuration file resides in a file under the backdoor’s installation directory with the .bin extension. It contains commands in the same form as those listed in Table 2 that are automatically executed by the backdoor when it is started. These commands are also executed when the loadconfig command is issued. This file can be likened to a startup script for the backdoor. The state command sets a global variable containing a series of Boolean values represented as ASCII values ‘0’ or ‘1’ and also adds itself to the configuration file. Some of these values indicate which C2 protocol to use, whether the backdoor has been installed, and whether the PST monitoring thread is running or not. Other than the state command, all commands in the configuration file are identified by their hash’s decimal value instead of their plain text name. Certain commands, when executed, add themselves to the configuration so they will persist across (or be part of) reboots. The loadconfig and state commands are executed during initialization, effectively creating the configuration file if it does not exist and writing the state command to it.

Figure 1 and Figure 2 illustrate some sample, decoded configuration files we have come across in our investigations.

Figure 1: Configuration file that adds new C2 server and forces the data-stealing backdoor to use it

Figure 2: Configuration file that adds TCP tunnels and records desktop video

Command and Control

CARBANAK communicates to its C2 servers via pseudo-HTTP or a custom binary protocol.

Pseudo-HTTP Protocol

Messages for the pseudo-HTTP protocol are delimited with the ‘|’ character. A message starts with a host ID composed by concatenating a hash value generated from the computer’s hostname and MAC address to a string likely used as a campaign code. Once the message has been formatted, it is sandwiched between an additional two fields of randomly generated strings of upper and lower case alphabet characters. An example of a command polling message and a response to the listprocess command are given in Figure 3 and Figure 4, respectively.

Figure 3: Example command polling message

Figure 4: Example command response message

Messages are encrypted using Microsoft’s implementation of RC2 in CBC mode with PKCS#5 padding. The encrypted message is then Base64 encoded, replacing all the ‘/’ and ‘+’ characters with the ‘.’ and ‘-’ characters, respectively. The eight-byte initialization vector (IV) is a randomly generated string consisting of upper and lower case alphabet characters. It is prepended to the encrypted and encoded message.

The encoded payload is then made to look like a URI by having a random number of ‘/’ characters inserted at random locations within the encoded payload. The malware then appends a script extension (php, bml, or cgi) with a random number of random parameters or a file extension from the following list with no parameters: gif, jpg, png, htm, html, php.

This URI is then used in a GET or POST request. The body of the POST request may contain files contained in the cabinet format. A sample GET request is shown in Figure 5.

Figure 5: Sample pseudo-HTTP beacon

The pseudo-HTTP protocol uses any proxies discovered by the HTTP proxy monitoring thread or added by the adminka command. The backdoor also searches for proxy configurations to use in the registry at HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings and for each profile in the Mozilla Firefox configuration file at %AppData%\Mozilla\Firefox\<ProfileName>\prefs.js.

Custom Binary Protocol

Figure 6 describes the structure of the malware’s custom binary protocol. If a message is larger than 150 bytes, it is compressed with an unidentified algorithm. If a message is larger than 4096 bytes, it is broken into compressed chunks. This protocol has undergone several changes over the years, each version building upon the previous version in some way. These changes were likely introduced to render existing network signatures ineffective and to make signature creation more difficult.

Figure 6: Binary protocol message format

Version 1

In the earliest version of the binary protocol, we have discovered that the message bodies that are stored in the <chunkData> field are simply XORed with the host ID. The initial message is not encrypted and contains the host ID.

Version 2

Rather than using the host ID as the key, this version uses a random XOR key between 32 and 64 bytes in length that is generated for each session. This key is sent in the initial message.

Version 3

Version 3 adds encryption to the headers. The first 19 bytes of the message headers (up to the <hdrXORKey2> field) are XORed with a five-byte key that is randomly generated per message and stored in the <hdrXORKey2> field. If the <flag> field of the message header is greater than one, the XOR key used to encrypt message bodies is iterated in reverse when encrypting and decrypting messages.

Version 4

This version adds a bit more complexity to the header encryption scheme. The headers are XOR encrypted with <hdrXORKey1> and <hdrXORKey2> combined and reversed.

Version 5

Version 5 is the most sophisticated of the binary protocols we have seen. A 256-bit AES session key is generated and used to encrypt both message headers and bodies separately. Initially, the key is sent to the C2 server with the entire message and headers encrypted with the RSA key exchange algorithm. All subsequent messages are encrypted with AES in CBC mode. The use of public key cryptography makes decryption of the session key infeasible without the C2 server’s private key.

The Roundup

We have rounded up 220 samples of the CARBANAK backdoor and compiled a table that highlights some interesting details that we were able to extract. It should be noted that in most of these cases the backdoor was embedded as a packed payload in another executable or in a weaponized document file of some kind. The MD5 hash is for the original executable file that eventually launches CARBANAK, but the details of each sample were extracted from memory during execution. This data provides us with a unique insight into the operational aspect of CARBANAK and can be downloaded here.

Protocol Evolution

As described earlier, CARBANAK’s binary protocol has undergone several significant changes over the years. Figure 7 illustrates a rough timeline of this evolution based on the compile times of samples we have in our collection. This may not be entirely accurate because our visibility is not complete, but it gives us a general idea as to when the changes occurred. It has been observed that some builds of this data-stealing backdoor use outdated versions of the protocol. This may suggest multiple groups of operators compiling their own builds of this data-stealing backdoor independently.

Figure 7: Timeline of binary protocol versions

*It is likely that we are missing an earlier build that utilized version 3.

Build Tool

Most of CARBANAK’s strings are encrypted in order to make analysis more difficult. We have observed that the key and the cipher texts for all the encrypted strings are changed for each sample that we have encountered, even amongst samples with the same compile time. The RC2 key used for the HTTP protocol has also been observed to change among samples with the same compile time. These observations paired with the use of campaign codes that must be configured denote the likely existence of a build tool.

Rapid Builds

Despite the likelihood of a build tool, we have found 57 unique compile times in our sample set, with some of the compile times being quite close in proximity. For example, on May 20, 2014, two builds were compiled approximately four hours apart and were configured to use the same C2 servers. Again, on July 30, 2015, two builds were compiled approximately 12 hours apart.

What changes in the code can we see in such short time intervals that would not be present in a build tool? In one case, one build was programmed to execute the runmem command for a file named wi.exe while the other was not. This command downloads an executable from the C2 and directly runs it in memory. In another case, one build was programmed to check for the existence of the domain in the trusted sites list for Internet Explorer while the other was not. Blizko is an online money transfer service. We have also seen that different monitoring threads from Table 1 are enabled from build to build. These minor changes suggest that the code is quickly modified and compiled to adapt to the needs of the operator for particular targets.

Campaign Code and Compile Time Correlation

In some cases, there is a close proximity of the compile time of a CARBANAK sample to the month specified in a particular campaign code. Figure 8 shows some of the relationships that can be observed in our data set.

Campaign Code Compile Date
Aug 7/30/15
dec 12/8/14
julyc 7/2/16
jun 5/9/15
june 5/25/14
june 6/7/14
junevnc 6/20/14
juspam 7/13/14
juupd 7/13/14
may 5/20/14
may 5/19/15
ndjun 6/7/16
SeP 9/12/14
spamaug 8/1/14
spaug 8/1/14

Figure 8: Campaign code to compile time relationships

Recent Updates

Recently, 64 bit variants of the backdoor have been discovered. We shared details about such variants in a recent blog post. Some of these variants are programmed to sleep until a configured activation date when they will become active.


The “Carbanak Group”

Much of the publicly released reporting surrounding the CARBANAK malware refers to a corresponding “Carbanak Group”, who appears to be behind the malicious activity associated with this data-stealing backdoor. FireEye iSIGHT Intelligence has tracked several separate overarching campaigns employing the CARBANAK tool and other associated backdoors, such as DRIFTPIN (aka Toshliph). With the data available at this time, it is unclear how interconnected these campaigns are – if they are all directly orchestrated by the same criminal group, or if these campaigns were perpetrated by loosely affiliated actors sharing malware and techniques.


In all Mandiant investigations to date where the CARBANAK backdoor has been discovered, the activity has been attributed to the FIN7 threat group. FIN7 has been extremely active against the U.S. restaurant and hospitality industries since mid-2015.

FIN7 uses CARBANAK as a post-exploitation tool in later phases of an intrusion to cement their foothold in a network and maintain access, frequently using the video command to monitor users and learn about the victim network, as well as the tunnel command to proxy connections into isolated portions of the victim environment. FIN7 has consistently utilized legally purchased code signing certificates to sign their CARBANAK payloads. Finally, FIN7 has leveraged several new techniques that we have not observed in other CARBANAK related activity.

We have covered recent FIN7 activity in previous public blog posts:

The FireEye iSIGHT Intelligence MySIGHT Portal contains additional information on our investigations and observations into FIN7 activity.

Widespread Bank Targeting Throughout the U.S., Middle East and Asia

Proofpoint initially reported on a widespread campaign targeting banks and financial organizations throughout the U.S. and Middle East in early 2016. We identified several additional organizations in these regions, as well as in Southeast Asia and Southwest Asia being targeted by the same attackers.

This cluster of activity persisted from late 2014 into early 2016. Most notably, the infrastructure utilized in this campaign overlapped with LAZIOK, NETWIRE and other malware targeting similar financial entities in these regions.


DRIFTPIN (aka Spy.Agent.ORM, and Toshliph) has been previously associated with CARBANAK in various campaigns. We have seen it deployed in initial spear phishing by FIN7 in the first half of 2016.  Also, in late 2015, ESET reported on CARBANAK associated attacks, detailing a spear phishing campaign targeting Russian and Eastern European banks using DRIFTPIN as the malicious payload. Cyphort Labs also revealed that variants of DRIFTPIN associated with this cluster of activity had been deployed via the RIG exploit kit placed on two compromised Ukrainian banks’ websites.

FireEye iSIGHT Intelligence observed this wave of spear phishing aimed at a large array of targets, including U.S. financial institutions and companies associated with Bitcoin trading and mining activities. This cluster of activity continues to be active now to this day, targeting similar entities. Additional details on this latest activity are available on the FireEye iSIGHT Intelligence MySIGHT Portal.

Earlier CARBANAK Activity

In December 2014, Group-IB and Fox-IT released a report about an organized criminal group using malware called “Anunak” that has targeted Eastern European banks, U.S. and European point-of-sale systems and other entities. Kaspersky released a similar report about the same group under the name “Carbanak” in February 2015. The name “Carbanak” was coined by Kaspersky in this report – the malware authors refer to the backdoor as Anunak.

This activity was further linked to the 2014 exploitation of ATMs in Ukraine. Additionally, some of this early activity shares a similarity with current FIN7 operations – the use of Power Admin PAExec for lateral movement.


The details that can be extracted from CARBANAK provide us with a unique insight into the operational details behind this data-stealing malware. Several inferences can be made when looking at such data in bulk as we discussed above and are summarized as follows:

  1. Based upon the information we have observed, we believe that at least some of the operators of CARBANAK either have access to the source code directly with knowledge on how to modify it or have a close relationship to the developer(s).
  2. Some of the operators may be compiling their own builds of the backdoor independently.
  3. A build tool is likely being used by these attackers that allows the operator to configure details such as C2 addresses, C2 encryption keys, and a campaign code. This build tool encrypts the binary’s strings with a fresh key for each build.
  4. Varying campaign codes indicate that independent or loosely affiliated criminal actors are employing CARBANAK in a wide-range of intrusions that target a variety of industries but are especially directed at financial institutions across the globe, as well as the restaurant and hospitality sectors within the U.S.


Authors: James T. Bennett, Barry Vengerik

  • 0

SMB Exploited: WannaCry Use of “EternalBlue”

Category : FireEye

Server Message Block (SMB) is the transport protocol used by Windows machines for a wide variety of purposes such as file sharing, printer sharing, and access to remote Windows services. SMB operates over TCP ports 139 and 445. In April 2017, Shadow Brokers released an SMB vulnerability named “EternalBlue,” which was part of the Microsoft security bulletin MS17-010.

The recent WannaCry ransomware takes advantage of this vulnerability to compromise Windows machines, load malware, and propagate to other machines in a network. The attack uses SMB version 1 and TCP port 445 to propagate.


SMB provides support for what are known as SMB Transactions. Using SMB Transactions enables atomic read and write to be performed between an SMB client and server. If the message request is greater than the SMB MaxBufferSize, the remaining messages are sent as Secondary Trans2 requests. This vulnerability affects the srv2.sys kernel driver and is triggered by malformed Secondary Trans2 requests.


After the initial SMB handshake, which consists of a protocol negotiate request/response and a session setup request/response, the ransomware connects to the IPC$ share on the remote machine. Another related aspect of this attack is that the malware is configured to connect to a hardcoded local IP, as shown in Figure 1.

Figure 1: Connecting to the IPC$ share

Next it sends out an initial NT Trans request, which is a huge payload size and consists of a sequence of NOPs, as shown in Figure 2. What it essentially does is move the SMB server state machine to a point where the vulnerability exists so that the attacker can then exploit it using a special crafted packet.

Figure 2: Preparing server for exploit via NT Trans

Speaking the SMB language, the large NT Trans request leads to multiple Secondary Trans2 Requests to accommodate for the large request size. These Secondary Trans2 requests are malformed, as seen in the Figure 3. They act as a trigger point for the vulnerability, and the request data portion contains the shellcode and encrypted payload, which is the launcher for the malware on the remote machine.

Figure 3: Overflow via Malformed Trans2

Post Exploitation & Full Cycle

On successfully triggering the vulnerability, an encrypted payload containing the stager for the malware is loaded on the remote machine. The payload delivered to the remote machine launches a service “mssecsvc” from within the lsass process. This service scans the local network and the internet for machines that are accessible and have exposed SMB ports. The service then uses the aforementioned vulnerability to gain access to a remote machine and deliver the malware payload, thus completing the full cycle. All of these activities happen very quickly and the attack penetrates all machines in a typical LAN within minutes.

The ransomware contains two parts, the main executable file containing the code for scanning the network and triggering the SMB vulnerability on accessible machines. Within the resource section of this executable is another executable file embedded in a section named “R”, which contains the ransomware code. The executable containing the ransomware code has an encrypted ZIP file embedded in the resource section named “XIA”. The encrypted ZIP file contains encrypted keys, image files, Tor client and two other executables: taskdl.exe and tasse.exe. The ZIP file contents can be extracted using the password WNcry@2ol7 embedded within the malware code


There are anomalies and patterns in the NT Trans, Trans2 requests and responses packets that analysts and researchers can use to create useful network level detection. A couple of example signatures that can be deployed are found here and here.

  • 0

Watch FireEye Endpoint Security Detect and Prevent a WannaCry Attack

Category : FireEye

Since May 12, 2017, a highly prolific WannaCry ransomware campaign has been observed impacting organizations globally. WannaCry (aka WCry or WanaCryptor) malware is self-propagating (worm-like) ransomware that spreads through internal networks and over the public internet by exploiting a vulnerability in Microsoft Server Message Block (SMB) protocol. The malware appends encrypted data files with the .WCRY extension, drops and executes a decryptor tool, and demands $300 or $600 USD (via Bitcoin) to decrypt the data.

The following video demonstrates how FireEye Endpoint Security (HX) detects and prevents the WannaCry ransomware threat.

This demonstration first shows how HX Exploit Guard (ExG) can detect and prevent threats. It then goes into the details of how it detected and prevented a WannaCry ransomware attack, and walks the viewer through the exact process that it took and how ExG is able to deal with threats in real-time. The demo exposes how ransomware works, and how the overall design of ExG and HX can effectively deal with these and other types of threats.

  • 0

How to Avoid Being the Next Victim of Ransomware

Category : FireEye

Ransomware is one of the most prevalent and feared forms of security attack these days. Organisations worry about ransomware because it is extremely difficult to detect in advance, hard to stop spreading once it strikes, and potentially disastrous in terms of data destruction. Add to this the ignominy of having to pay the ransom to criminals and a possible fine from data protection regulators, and ransomware becomes a critical threat to organisations of all types and sizes.

Ransomware is often introduced into an organisation through phishing emails, but it may also be introduced via exploits, USB drives and other media containing malware. It functions quickly. For example, one organisation we know experienced 30,000 files being corrupted within four minutes. It spreads from machine to machine via the corporate network, affecting endpoint devices (PCs, laptops) and servers, and can also spread to storage media on the network. Once files are encrypted it is (for all intents and purposes) impossible to unlock them. Good practice suggests that for an organisation to be well prepared for this kind of attack, it will require good backups from which it can restore data. But data is rarely backed up in real time, so some degree of data loss is usually inevitable.

The consequences of ransomware will increase with the introduction of GDPR in 2018. A personal data breach includes the “unlawful destruction” of data, which could lead to a fine of up to 2 percent of global annual revenue. This clearly represents a significant increase in risk to enterprises, both from a financial perspective, but also in terms of brand reputation.

What can organisations do to protect themselves against ransomware? We think there are five areas where organisations should seek to minimise the risk of the threat.

The first approach is to minimise the likelihood that a phishing campaign will be successful, by educating users of the importance of knowing the provenance of an email or website. Building awareness of the attributes of a fake email or website is useful, as is encouraging behaviour such as referring suspicious or unknown content to an administrator or other experienced individual. While these approaches will not eliminate people clicking on bad URLs, good education is a sound place to start.

The second level of protection is to implement technology on email and web gateways that scans for known or suspicious URLs. Such solutions are useful in sorting legitimate content from malware or unknown but suspicious sites.

The third layer of defence is to have technology installed on the endpoint. This typically monitors the behaviour of processes and detects activity that indicates ransomware behaviour. For example, a process that is sequentially encrypting files is likely to be ransomware. However, it is possible that this is also a legitimate process used for data protection purposes. In these cases, the process can be whitelisted. Other approaches involve application control, where applications themselves are whitelisted, but whereby unlisted or blacklisted applications cannot launch.

The fourth level is the use of network security solutions that can detect ransomware before it executes and can quarantine the suspicious process or detonate it in a sandbox. Or it may be able to detect the likelihood of the ransomware process from its download source or other attributes.

Finally, suspicious file activity on the server should be detected using similar technologies that are on endpoints. In addition, servers are typically backed up on a daily or more frequent basis according to good data governance procedures. As long as this backup plan involves storage that is inaccessible to ransomware, this is an essential step in ransomware protection.

None of these approaches are particularly new or innovative, but it is rare to see all of them deployed in any single organisation. Therefore, this collection of technologies maps well on our cyber maturity analysis discussed in recent blogs. More mature organisations are more likely to have implemented this layered approach to a variety of attacks, and will therefore be better protected against ransomware.

Complete the IDC Cyber Risk Assessment for help making informed decisions around cyber risk strategy and to understand the benefits associated with increasing your readiness in the face of evolving threats.

  • 0

How Intelligence Enriches Security Consulting Services

Category : FireEye

Join Jeff Berg, Sr. Manager of Cyber Threat Intelligence, and Brad Bell, Mandiant Principal Consultant, as they share the role of cyber threat intelligence in strategic security consulting services and why services based on compliance-based best practices and industry standards may not be an effective way to protect your organization against a rapidly evolving threat landscape.

Key takeaways:

  • The role cyber threat intelligence plays in strategic security consulting services.
  • Why services rooted in compliance-based best practices and industry standards aren’t effective
  • Case studies where different types of intelligence added value to service portfolio

Featured Speakers

Jeff Berg
Sr. Manager of Cyber Threat Intelligence
Mandiant , a FireEye company

Brad Bell

Principal Consultant
Mandiant , a FireEye company
SCHEDULED TIME May 24 2017 1:00 pm  
DURATION 60 mins

  • 1

Make Your Cyber Risk Escalation Framework a Stairway to (Security) Heaven

Category : FireEye

Security is a board-level issue. While the high media focus on data breaches in recent years has played a role in dragging security up the agenda, there are some far more pragmatic and impactful drivers behind this trend: failing to deal with security in the manner that is appropriate to the enterprise’s operational context and appetite for risk results in the potential to damage brand reputation, customer numbers and the share price.

It is no wonder that security risk management is dealt with at the highest levels. In fact, as shown in a recent survey conducted by IDC, FireEye and DXC featuring 500 senior European IT and security decision makers, more than 80 percent of respondents involve the CEO as part of the cyber risk escalation framework. But who else does best practice indicate ought to be involved in this process?

IDC’s survey indicates that there are two roles in particular whose involvement have an impact on driving up maturity levels: the COO, and a non-executive board member focused on risk/security/compliance.

Let’s look at the role of COO in the cyber escalation process first. At the lowest levels of maturity, the majority of respondents (60 percent) do not involve the COO in this framework. After all, the COO is concerned with the operations of the business lines, not “back-office” activities such as security, right? However, as we move up through the maturity levels a different picture emerges. When we move up to the midrange maturity categories, two-thirds of respondents involve the COO. For the most mature respondents, this figure rises to 87 percent.

So what is the story here? The answer starts to become clear when we consider the responses to another question in our survey. Specifically, our study shows that the more mature an organisation is, the earlier that security will be involved in any new business initiative. In fact, IDC would suggest that best practice is to involve security right from the very beginning. By extension, this makes the COO within a “cyber-mature” enterprise a key stakeholder in the handling of security. This provides support when launching and handling new projects within the lines of business, in a fashion that reduces exposure to risk. It also allows them the flexibility to react if and when a breach occurs. Importantly, COOs ask different questions. They can embed security — or at least secure thinking — in the day-to-day business operations, thus significantly improving overall exposure to threats.

The second key role to highlight here is the non-executive board member that is focused on risk/security/compliance. For the sake of brevity, let’s refer to them as the non-executive subject matter expert (or non-exec SME). As with the COO, there is a marked increase in the involvement of such a role as we move up the maturity chain. In this case, it is an even starker contrast – where 29 percent of respondents at the lowest level of maturity involve such a role in the cyber risk escalation framework, this rises to 91 percent at the highest level.

The reason for this distinction is perhaps less clear than for the COO, but there does appear to be one key explanation. This time, it is a question of communication and prioritisation within the escalation framework. Specifically, there remains a risk of a disconnect between the technically minded security specialists and the more business-orientated people who populate the rest of the escalation framework. This is particularly evident at the board level, which as we’ve seen tends to sit at the top of this process.

An enduring challenge for security professionals is the ability to “speak business”, of being able to express the nature and severity of a cyber threat to those without a technical background. When the non-exec SME comes into the picture, they bring the ability to act as a bridge between the board and the security team. Individuals possessing these skills – of leadership and communication, and being able to span the gap between the technical experts and the lines of business – are rare. Consequently, they play a key role for respondents at the upper end of the cyber maturity spectrum.

To conclude, the CEO, COO and non-exec SME are by no means the only roles to sit within a cyber escalation framework. In fact, our survey would indicate that the more mature an enterprise is in its approach to security, the more key stakeholders they are likely to involve in this process. However, that is not to say that senior executives ought to be thrown at the framework willy-nilly, which runs the risk of making the escalation process too complex. Ultimately, the burden of responsibility must fall on the CEO. However, consideration must be given to how this escalation framework ought to be shaped so that the CEO is presented with the right information with which to make a decision, and in a format that is interpretable, so it can then be disseminated across the business in a consistent fashion.

Complete the IDC Cyber Risk Assessment for help making informed decisions around cyber risk strategy and to understand the benefits associated with increasing your readiness in the face of evolving threats.

  • 0

Dridex and Locky Return Via PDF Attachments in Latest Campaigns

Category : FireEye

Dridex and Locky, two prolific malware families that made waves in 2016 after being distributed in several high-volume spam campaigns, have returned after a brief hiatus. FireEye observed a decline in the volume of Dridex and Locky in the latter half of 2016, but we recently observed two new large campaigns.

While the PDF downloader described in this post is responsible for spreading both Dridex and Locky, for the purposes of this blog, we will be discussing the PDF downloader and the Dridex binary.

The larger of the two campaigns (Figure 1) involved a “payment receipt” theme and, according to our telemetry, primarily affected the insurance industry in the U.S.

Figure 1: Telemetry for the larger campaign

In the smaller of the two campaigns (Figure 2), the attachment was claimed to be an alert from a printer for a scanned document. This campaign primarily affected the government sector in the Middle East, U.S., and Japan.

Figure 2: Telemetry for the smaller campaign

Execution Flow

As seen in Figure 3, at a high-level, the execution flow consists of:

  • Spam campaign email containing a malicious PDF file
  • Attached PDF file drops and executes a DOCM document
  • Dropped document file contains a macro which launches a PowerShell script upon execution.
  • PowerShell script then fetches an encrypted binary from the command and control (C2) server
  • Encrypted Binary is decrypted and executed, and malicious payload is dropped and launched

Figure 3: Full Execution Flow

Spam Campaign

We observed two patterns of subject lines used in these campaigns. One is Payment_XXX, where XXX refers to any random number, while the other one is Scanned image from MX-2600N. Figure 4 shows sample spam emails from both campaigns.

Figure 4: Spam Email Examples

The Attachments

Attached PDF File:

The PDF attachment contains several objects, but the most relevant ones are an embedded DOCM file (a macro enabled doc file) and a JavaScript object that drops and launches the DOCM file. Figure 5 shows the embedded DOCM file, and Figure 6 shows a snippet of the JavaScript that drops the DOCM file.


Figure 5: DOCM file header in Object 3

Figure 6: Dropper JavaScript snippet with reference to DOCM file to be dropped and executed

When the PDF document is opened, Adobe Reader displays a warning as shown in Figure 7, clearly stating that the attached file may be harmful.

Figure 7: Security Warning by Adobe

If the user ignores the warning and clicks OK, the DOCM file is written to %temp% and then launched.

Dropped Document File:

The document file opens in read only or protected mode, which means the macro inside the document file is not able to execute. To bypass this mechanism, the document displays a message prompting the user toEnable Editing”, as seen in Figure 8.

Figure 8: Protected Document Asking for Permission to Enable Editing

Once a victim clicks “Enable Editing”, the embedded macro executes. In Figure 9, we can see that the command to be executed is hidden in the caption of form1. This macro executes a PowerShell command to communicate with the C2 server and downloads the next payload.

Figure 9: Embedded Macro

Figure 10 shows how the command is hidden a form.

Figure 10: Command Hidden a Form

PowerShell Script

The powershell is obfuscated and it can be de-obfuscated with the algorithm in Figure 11. Once executed, the scripts main function is to connect with the C2 server to retrieve a payload. The script contains an array of URIs, and it tries each one until it successfully receives a valid response from the server.

Figure 11: De-obfuscation routine for the obfuscated Powershell script

After de-obfuscating the script, it appears to be divided into two parts:

  1. C2 Communication: In this step, the script generates the C2 domains and sends requests to them via HTTP. It checks for the response received, and if the response is not OK [200], it then re-tries the communication with another host.
  2. Decryption of received data: If the server is alive, it responds with the data. The data is encrypted before being sent and then decrypted by the script via simple XOR. Figure 12 shows the C2 server communication details.

Figure 12: C2 Communication

During a sample run, the script requests the resource “/dfv45” from and and successfully receives a response from the second host.

The response is XOR encrypted. Figure 13 shows the response header.

Figure 13: C2 Response Header

The PowerShell script decodes the response and writes the decoded executable into %temp%. A python script to decode the response is shown in Figure 14.

Figure 14: Decryption Routine Code Snippet

The Final Payload

Up to this point, the process for distributing Dridex and Locky payloads has been the same. The malware that is delivered depends on the C2 server that is contacted.

In this case, the sample fetched the Dridex payload. When executed, Dridex unpacks and runs itself within the context of svchost.exe or spoolsv.exe via process hallowing to evade detection.


Dridex and Locky have been highly active and prolific in the past several months, and although the delivery mechanism often changes, the core behavior of the family remains unchanged. Dridex is one of the most active banking Trojans from the last few years, and Locky is one of the most active ransomware families. If the past year is any indication, Dridex and Locky distributors will continue to search for ways to evade detection. FireEye is committed to remaining vigilant against these efforts.

URLs seen distributing Dridex

URLs seen distributing Locky

Dridex C2 Servers



Due to the widespread nature of these phishing campaigns, organizations can better protect themselves by addressing several key areas:

  • Implement a web proxy: By deploying a web proxy, organizations will have the capability to craft rules which block outbound access to the unique URI parameters “/dvf45/” and “kjv783r/” used by Dridex and Locky. Note that this is a mitigation with limited durability and will require an increased awareness of these campaigns.
  • Develop egress firewall policies: Develop and understanding of the necessary outbound traffic your organizations requires and, combined with a web proxy, block all unnecessary outbound traffic while forcing web and other authorized traffic through the proxy. By monitoring for violations, an organization can develop additional detection capabilities.

FireEye Multi Vector Execution (MVX) engine is able to recognize and block this threat.

  • Enable enhanced PowerShell logging: Improving your organizations visibility into PowerShell logging has numerous benefits, one of which being the ability to determine malicious use of PowerShell such as is leveraged in this campaign.

  • 1

Smarter Endpoint Security: How to go Beyond Prevention

Category : FireEye

Today’s endpoint security products do what they were designed to do, but they still leave gaps in protection. Comprehensive endpoint protection requires prevention, AV, endpoint detection and response (EDR) and other capabilities. Even when organizations adopt multiple point products, there are still gaps in their endpoint protection.

Some companies tout “next-generation endpoint security,” but what does that mean? Jim Waggoner, Sr. Director of Endpoint Product Management at FireEye will tell you how to make sure your next-generation endpoint security solution is delivering a comprehensive. In this webinar, you will:

  • Learn about the current endpoint security landscape and the challenges it poses.
  • Find out what makes EDR capabilities valuable.
  • Understand why threat intelligence is important and how it affects endpoint threat detection and prevention.
  • Discover why a single endpoint agent should include:
    • Multiple detection and prevention engines.
    • Integrated workflows from detection to investigation to remediation.
    • Scalable, multiple form factors and breadth of OS support.



  • 0

Securing Finance: Lessons Learnt So Far

Category : FireEye

In 2016 FireEye observed an increase in the number of advanced targeted attacks leveraged against financial institutions in Europe and the Middle East. Much of the activity involved sophisticated financially motivated attackers targeting poorly defended institutions, and centred on the interbanking messaging system.

Join Mandiant’s live webinar and hear real world experts as they discuss recent interbanking messaging system breaches, what lessons should be learnt, and how to avoid such pitfalls in the future.

Live online May 16 9:00 am United States – New York
or after on demand 45 mins