🔒
There are new articles available, click to refresh the page.
Before yesterdayThreat Research

Executive Briefing in New York with Former Secretary of Homeland Security Michael Chertoff

2 April 2012 at 22:17

On March 15, Mandiant hosted an executive briefing over breakfast in New York City. The location in the W Hotel in Downtown NYC overlooked the 9/11 Memorial and the rising One World Trade Center-an arresting view and a unique setting for this event.

Former Secretary of Homeland Security Michael Chertoff kicked off the morning by discussing his perspective on the global threat landscape. He touched on Iran's cyber warfare capabilities in particular. He remarked on recent alleged Iranian attacks against the BBC and said that there is no point in debating the reality of cyber war. If one side believes they are engaged in such a battle, then that is reality-and "Iran clearly believes they are already participants in cyber war." He also noted that Iran's capabilities are already quite advanced. After being hit by Stuxnet, Iran views it as imperative to be prepared to respond in kind.

It is always nice to see someone like Mr. Chertoff connecting the dots so articulately on a technical level. At one point, he commented about how important it was to not just look for malware. Smart responders, he said, need to look for all trace evidence of compromise in order to fully understand the scope of an incident. Coincidentally, this is trend #1 in our recent M-Trends report, and Mr. Chertoff described the problem with a malware-centric approach perfectly.

Richard Bejtlich spoke next and used a role-playing exercise to help the audience understand the challenge of responding to targeted threats. His premise was simple: "Pretend I'm a law enforcement agent who comes to your office and tells you that you are compromised, and that I have your own internal documents as evidence. What do you do next?"

This provoked discussion and the audience started asking questions about the nature of the intrusion and what they should do to respond. As we explored the scenario through Q&A, it became clear that most organizations lack the visibility they need to adequately respond to attacks. What about your organization? If you found out today that you had been the victim of a substantial breach, where would you look first? How would you validate the intrusion? How could you discover the scopeor identify what had been stolen?

Those of you who have attended Mandiant events know that we are pretty light on the product pitches (we often don't mention our products at all). However, we do have a product that helps answer the questions that Richard was posing. Mandiant Intelligent Response has helped hundreds of companies answer the question "Now What??" when they are on the receiving end of the scenario Richard outlined in New York.

M-Trends #1: Malware Only Tells Half the Story

14 May 2012 at 20:45

When I joined Mandiant earlier this year, I was given the opportunity to help write our annual M-Trends report. This is the third year Mandiant has published the report, which is a summary of the trends we've observed in our investigations over the last twelve months.

I remember reading Mandiant's first M-Trends report when it came out in 2010 and recall being surprised that Mandiant didn't pull any punches. They talked about the advanced persistent threat or APT (they had been using that term for several years...long before it was considered a cool marketing, buzz word), and they were open about the origin of the attacks. The report summarized what I'd been seeing in industry, and offered useful insights for detection and response. Needless to say, I enjoyed the opportunity to work on the latest version.

In this year's report it details six trends we identified in 2011. We developed the six trends for the report very organically. That is, I spent quite a few days and nights reading all of the reports from our outstanding incident response team and wrote about what we saw-we didn't start with trends and then look for evidence to support them.

If you haven't picked up a copy of the report yet, you can do so here. I will be blogging on each of the six trends over the next two weeks; you can even view the videos we've developed for each trend as each blog post is published:

Malware Only Tells Half the Story.

Of the many systems compromised in each investigation, about half of them were never touched by attacker malware.

In so many cases, the intruders logged into systems and took data from them (or used them as a staging point for exfiltration), but didn't install tools. It is ironic that the very systems that hold the data targeted by an attacker are probably the least likely to have malware installed on them. While finding the malware used in an intrusion is important, it is impossible to understand the full scope of an intrusion if this is the focal point of the investigation. We illustrate actual examples of this in the graphical spread on pages 6-7 of the report.

What does this mean for victim organizations?

You could start by looking for malware, but don't end there! A smart incident response process will seek to fully understand the scope of compromise and find all impacted systems in the environment. This could mean finding the registry entries that identify lateral movement, traces of deleted .rar files in unallocated space, or use of a known compromised account. It turns out that Mandiant has a product that does all of this, but the footnote on page 5 is the only mention you'll see in the entire report (and even that was an afterthought).

Thoughts and questions about this trend or the M-Trends report?

Incident Response with NTFS INDX Buffers – Part 1: Extracting an INDX Attribute

18 September 2012 at 23:23

By William Ballenthin & Jeff Hamm

On August 30, 2012, we presented a webinar on how to use INDX buffers to assist in an incident response investigation. During the Q&A portion of the webinar we received many questions; however, we were not able to answer all of them. We're going to attempt to answer the remaining questions by posting a four part series on this blog. This series will address:

Part 1: Extracting an INDX Record

An INDX buffer in the NTFS file system tracks the contents of a folder. INDX buffers can be resident in the $MFT (Master File Table) as an index root attribute (attribute type 0x90) or non-resident as an index allocation attribute (attribute 0xA0) (non-resident meaning that the content of the attribute is in the data area on the volume.)

INDX root attributes have a dynamic size in the MFT, so as the contents change, the size of the attributes change. When an INDX root attribute shrinks, the surrounding attributes shift and overwrite any old data. Therefore, it is not possible to recover slack entries from INDX root attributes. On the other hand, the file system driver allocates INDX allocation attributes in multiples of 4096, even though the records may only be 40 bytes. As file system activity adds and removes INDX records from an allocation attribute, old records may still be recoverable in the slack space found between the last valid entry and the end of the 4096 chunk. This is very interesting to a forensic investigator. Fortunately, many forensic tools support extracting the INDX allocation attributes from images of an NTFS file system.

Scenario

Let's say that during your investigation you identified a directory of interest that you want to examine further. In the scenario we used during the webinar, we identified a directory as being of interest because we did a keyword search for "1.rar". The results of the search indicated that the slack space of an INDX attribute contained the suspicious filename "1.rar". The INDX attribute had the $MFT record number 49.

Before we can parse the data, we need to extract the valid index attribute's content. Using various forensic tools, we are capable of this as demonstrated below.

The SleuthKit

We can use the SleuthKit tools to extract both the INDX root and allocation data. To extract the INDX attribute using the SleuthKit, the first step is to identify the $MFT record IDs for the attributes of the inode. We want the content of the index root attribute (attribute type 0x90 or 144d) and the index allocation attribute (attribute type 0xA0 or 160d).

To identify the attribute IDs, run the command:

istat -f ntfs ntfs.dd 49

The istat command returns inode information from the $MFT. In the command we are specifying the NTFS file system with the "-f" switch. The tool reads a raw image named "ntfs.dd" and locates record number 49. The result of our output (truncated) was as follows:

....
Attributes:
Type: $STANDARD_INFORMATION (16-0) Name: Resident size: 72

...

Type: $I30 (144-6) Name: $I30 Resident size: 26

Type: $I30 (160-7) Name: $I30 Non-Resident size: 4096

The information returned for the attribute list includes the index root - $I30 (144-6) - and an index allocation - $I30 (160-7). The attribute identifier is the integer listed after the dash. Therefore, the index root attribute 144 has an identifier of 6, and the index allocation attribute 160 has an identifier of 7.

With this information, we can gather the content of the attributes with the SleuthKit commands:

icat -f ntfs ntfs.dd 49-144-6 > INDX_ROOT.bin

icat -f ntfs ntfs.dd 49-160-7 > INDX_ALLOCATION.bin

The icat command uses the NTFS module to identify the record (49) attribute (144-6 and 144-7), and outputs the attribute data into the respective files INDX_ROOT.bin and INDX_ALLOCATION.bin.

EnCase

We can use EnCase to extract the INDX allocation data. To use EnCase version 6.x to gather the content of the INDX buffers, in the explorer tree, right click the folder icon. The "Copy/UnErase..." option applied to a directory will copy the content of the INDX buffer as a binary file. Specify a location to save the file. Note that the "Copy Folders..." option will copy the directory and its contents and will NOT extract the INDX structure.

FTK

We can use the Forensic Toolkit (FTK) to extract the INDX allocation data. Using FTK or FTK Imager, the INDX allocation attributes appear in the file list pane. These have the name "$I30" because the stream name is identified as $I30 in the index root and index allocation attributes. To extract the content of an index attribute, in the explorer pane, highlight the folder. In the file list pane, right click the relevant $I30 file and choose the option to "export". This will prompt you for a location to save the binary content.

Mandiant Intelligent Response®

The Mandiant Intelligent Response® (MIR) agent v.2.2 has the ability to extract INDX records natively. To generate a list of INDX buffers in MIR, run a RAW file audit. One of the options in the audit is to "Parse NTFS INDX Buffers". You can run this recursively, or you can target specific directories. We recommend the latter because this option will generate numerous entries when done recursively.

To display a list of parsed INDX buffers, you can filter a file listing in MIR by choosing the "FileAttributes" are "like" "*INDX*". The MIR agent recognizes "INDX" as an attribute because the files listed in the indices may or may not be deleted.

Results

Regardless of which method is used, your binary file should begin with the string "INDX" if you grabbed the correct data stream. You can verify the results quickly in a hex editor. Ensure that the first four bytes of the binary data is the string "INDX".

Conclusion

This example demonstrates three ways to use various tools to extract INDX attribute content. Our next post will detail the internal structures of a file name attribute. A file name attribute will exist for each file tracked in a directory. These structures include the MACb (Modified, Accessed, Changed, and birth) times of a file and can be a valuable timeline source in an investigation.

Mandiant Exposes APT1 – One of China's Cyber Espionage Units & Releases 3,000 Indicators

19 February 2013 at 07:00

Today, The Mandiant® Intelligence Center™ released an unprecedented report exposing APT1's multi-year, enterprise-scale computer espionage campaign. APT1 is one of dozens of threat groups Mandiant tracks around the world and we consider it to be one of the most prolific in terms of the sheer quantity of information it has stolen.

Highlights of the report include:

  • Evidence linking APT1 to China's 2nd Bureau of the People's Liberation Army (PLA) General Staff Department's (GSD) 3rd Department (Military Cover Designator 61398).
  • A timeline of APT1 economic espionage conducted since 2006 against 141 victims across multiple industries.
  • APT1's modus operandi (tools, tactics, procedures) including a compilation of videos showing actual APT1 activity.
  • The timeline and details of over 40 APT1 malware families.
  • The timeline and details of APT1's extensive attack infrastructure.

Mandiant is also releasing a digital appendix with more than 3,000 indicators to bolster defenses against APT1 operations. This appendix includes:

  • Digital delivery of over 3,000 APT1 indicators, such as domain names, and MD5 hashes of malware.
  • Thirteen (13) X.509 encryption certificates used by APT1.
  • A set of APT1 Indicators of Compromise (IOCs) and detailed descriptions of over 40 malware families in APT1's arsenal of digital weapons.
  • IOCs that can be used in conjunction with Redline™, Mandiant's free host-based investigative tool, or with Mandiant Intelligent Response® (MIR), Mandiant's commercial enterprise investigative tool.

The scale and impact of APT1's operations compelled us to write this report. The decision to publish a significant part of our intelligence about Unit 61398 was a painstaking one. What started as a "what if" discussion about our traditional non-disclosure policy quickly turned into the realization that the positive impact resulting from our decision to expose APT1 outweighed the risk of losing much of our ability to collect intelligence on this particular APT group. It is time to acknowledge the threat is originating from China, and we wanted to do our part to arm and prepare security professionals to combat the threat effectively. The issue of attribution has always been a missing link in the public's understanding of the landscape of APT cyber espionage. Without establishing a solid connection to China, there will always be room for observers to dismiss APT actions as uncoordinated, solely criminal in nature, or peripheral to larger national security and global economic concerns. We hope that this report will lead to increased understanding and coordinated action in countering APT network breaches.

We recognize that no one entity can understand the entire complex picture that many years of intense cyber espionage by a single group creates. We look forward to seeing the surge of data and conversations a report like this will likely generate.

Dan McWhorter

Managing Director, Threat Intelligence

Utilities Industry in the Cyber Targeting Scope

17 June 2013 at 20:40

There's often a lot of rhetoric in the press and in the security community around threats to the utilities industry, and risk exposure surrounding critical infrastructure. We've determined that the utilities industry (power, water, waste) has been, and likely will continue to be, a target for cyber espionage primarily from Chinese APT groups. We also anticipate that U.S. utilities infrastructure is vulnerable to computer network attack (CNA) from a variety of threat actors motivated by a desire to disrupt, deny access, or destroy. It's important to recognize the difference between actors seeking to steal data or intellectual property, and actors seeking to destroy systems or cause mass destruction. Often the distinction between computer network exploitation (CNE) and CNA gets lost in media coverage that bundles diverse cyber activity together. The type of cyber activity has implications for how we tackle the problem, thus it's key to distinguish.

As part of our incident response and managed defense work, Mandiant has observed Chinese APT groups exploiting the computer networks of U.S. utilities enterprises servicing or providing electric power to U.S. consumers, industry, and government. The most likely targeted information for data theft in this industry includes smart grid technologies, water and waste management expertise, and negotiations information related to existing or pending deals involving Western utilities companies operating in China.

Why would Chinese APT Groups Seek to Exploit Utilities?

Since 2010, Mandiant has responded to what we assessed were Chinese cyber espionage incidents occurring at multiple utilities companies involved in electric power generation. We recognize the PRC's utilities sector for electric power development, construction, operations, and distribution is heavily concentrated on a select few state-owned enterprises (SOE) with close ties to the central government. We suspect these relationships provide APT groups with a fundamental incentive to conduct espionage to attain advanced technology and operations expertise.

By way of possible motivation, the PRC is in the midst of a historic makeover that involves the transformation of urban infrastructures, which, by 2025, is likely to produce 15 mega-cities with an average of 25 million inhabitants, or about the entire population of the United States.[i] The impacts from this transition are intensifying pressures on an already fragile and outdated utilities infrastructure in China that currently struggles to provide sufficient electric power, water, and waste treatment. We believe APT groups are stealing data that will allow them to improve historic PRC urbanization efforts and the modernization of infrastructure, which is receiving billions of government investment dollars for development.

While we have tracked multiple attributed Chinese APT groups active in the utilities industries, we certainly don't discount that other, non-Chinese state-sponsored (or independent) actors could be engaged in data theft related to utilities.

The Risk of Disruptive Cyber Attacks

Computer network attacks (CNA) - that is, offensive cyber operations meant to disrupt or destroy-are also a threat to the utilities industry from state actors in times of major conflict. Perpetrators may include hostile adversaries, possibly nation-states, during times of escalated tensions, or terrorist operatives who gain the required expertise. The threat of a state-sponsored actor or proxy targeting this industry using CNA is a growing concern, particularly in the case of Iran, though wide-scale data theft is the primary type of threat we've observed to this point. Several large US news outlets did recently report that Iranian-based actors infiltrated some of the US' industrial control systems, however, and some have speculated their motivation in doing so was to map the network or identify resources for future attack scenarios.

For more intelligence reporting and specific details related to data theft in the utilities industry, the involved actors, and other threats, consider subscribing to the Mandiant Intelligence Center.

The History of OpenIOC

17 September 2013 at 23:36

With the buzz in the security industry this year about sharing threat intelligence, it's easy to get caught up in the hype, and believe that proper, effective sharing of Indicators or Intelligence is something that can just be purchased along with goods or services from any security vendor.

It's really a much more complex problem than most make it out to be, and one that we've been working on for a while. A large part of our solution for managing Threat Indicators is using the OpenIOC standard format.

Since its founding, Mandiant sought to solve the problem of how to conduct leading-edge Incident Response (IR) - and how to scale that response to an entire enterprise. We created OpenIOC as an early step in tackling that problem. Mandiant released OpenIOC to the public as an Open Source project under the Apache 2 license in November of 2011, but OpenIOC had been used internally at Mandiant for several years prior.

IR is a discipline that usually requires highly trained professionals doing very resource-intensive work. Traditionally, these professionals would engage in time-intensive investigations on only a few hosts on a compromised network. Practical limitations on staffing, resources, time, and money would prevent investigations from covering anything other than a very small percentage of most enterprises. Responders would only be able to examine what they had direct access to, with their corresponding conclusions constrained by time and budget.

This level of investigation was almost never enough to give confidence on anything other than the hosts that had been examined - responders were unable to confirm whether other systems were still compromised, or whether the adversary still had footholds in other parts of the network.

Creating a standard way of recording Threat Intelligence into an Indicator was part of what allowed Mandiant to bring a new approach to IR, including the use of an automated solution, such as Mandiant for Intelligent Response® (MIR®). Mandiant's new strategy for IR enabled investigators, who previously could only get to a few hosts in an engagement, to now query entire enterprises in only slightly more time. Using OpenIOC as a standardized format, the Indicators of Compromise (IOCs) were recorded once, and then used to help gather the same information and conduct the same testing on every host across the enterprise via the automated solution. Incident Responders could now spend only a little more time, but cover an exponentially larger number of hosts during the course of an investigation.

Recording the IOCs in OpenIOC had other benefits as well. Indicators from one investigation could be shared with other investigations or organizations, and allow investigators to look for the exact same IOCs wherever they were, without having to worry about translation problems associated with ambiguous formats, such as lists or text documents. One investigator could create an IOC, and then share it with others, who could put that same IOC into their investigative system and look for the same evil as the first person, with little to no additional work.

The format grew organically over time. We always intended that the format be expandable and improvable. Instead of trying to map out every possible use case, Mandiant has updated the format and expanded the dictionaries of IOC Terms as new needs have arisen over time. The version we released in 2011 as "1.0" had already been revised and improved upon internally several times before its Open Source debut. We continue to update the standard as needed, allowing for features and requests that we have received over time from other users or interested parties.

Unlike traditional "signatures," OpenIOC provides the ability to use logical comparison of Indicators in an IOC, providing more flexibility and discrimination than simple lists of artifacts. An extensive library of Indicator Terms allows for a variety of information from hosts and networks to be recorded, and if something is not covered in the existing terms, additional terms may be added. Upcoming features like parameters will allow for further expansion of the standard, including customization for application or organization specific use cases.

Having the OpenIOC standard in place is tremendously powerful, providing benefits for scaling detection and investigation, both of which are key parts of managing the threat lifecycle. OpenIOC enables easy, standardized information sharing once implemented, without adding much to workloads or draining resources. And it is freely available as Open Source; so that others can benefit from some of the methods we have already found to work well in our practice. We hope that as we improve it, you can take even more advantage of what OpenIOC has to offer in your IR and Threat Intelligence workflows.

Next up in the Back to Basics: OpenIOC series, we'll talk about some of the basics of what OpenIOC is and what using it involves - and some of the upcoming things in the future of OpenIOC.

Another Darkleech Campaign

3 October 2013 at 17:23

Last week got us up close and personal with Darkleech and Blackhole with our external careers web site.

The fun didn’t end there, this week we saw a tidal wave of Darkleech activity linked to a large-scale malvertising campaign identified by the following URL:

hXXp://delivery[.]globalcdnnode[.]com/7f01baa99716452bda5bba0572c58be9/afr-zone.php

Again Darkleech was up to its tricks, injecting URLs and sending victims to a landing page belonging to the Blackhole Exploit Kit, one of the most popular and effective exploit kits available today. Blackhole wreaks havoc on computers by exploiting vulnerabilities in client applications like IE, Java and Adobe, computers that are vulnerable to exploits launched by Blackhole are likely to become infected with one of several flavors of malware including ransomware, Zeus/Zbot variants and clickfraud trojans like ZeroAccess.

We started logging hits at 21:31:00 UTC on Sunday 09/22/2013, the campaign has been ongoing, peaking Monday and tapered down through out the week.

During most of the campaign’s run, delivery[.]globalcdnnode[.]com appeared to have gone dark, no longer serving the exploit kit’s landing page as expected and then stopped resolving altogether, yet tons of requests kept flowing.

This left some scratching their heads as to whether the noise was a real threat.

Indeed, it was a real threat, as Blackhole showed up to the party a couple of days later; this was confirmed by actually witnessing a system get attacked on a subsequent visit to the URL.

 

globalcdn_BHEK

Figure 1. – Session demonstrating exploit via IE browser and Java.

 

The server returned the (obfuscated) Blackhole Landing page; no 404 this time.

Darkleech_LANDING

Figure 2 – request and response to to delivery[.]globalcdnnode[.]com.

 

The next stage was to load a new URL for the malicious jar file. At this point, the unpatched Windows XP system running vulnerable Java quickly succumbed to CVE-2013-0422.

Darkleech_JAVA

Figure 3 – Packet capture showing JAR file being downloaded.

Darkleech_Java_Classes

Figure 4. – Some of the Java class files visible in the downloaded Jar.

 

Even though our system was exploited and the browser was left in a hung state, it did not receive the payload. Given the sporadic availability during the week of both the host and exploit kit’s landing page, it’s possible the system is or was undergoing further setup and this is the prelude to yet another large-scale campaign.

We can’t say for sure but we know this is not the last time we will see it or the crimeware actor behind it.

Registrant:

Name: Alexey Prokopenko
Organization: home
Address: Lenina 4, kv 1
City: Ubileine
Province/state: LUGANSKA OBL
Country: UA
Postal Code: 519000
Email: alex1978a @bigmir.net

By the way, this actor has a long history of malicious activity online too.

The campaign also appears to be abusing Amazon Web Services.

globalcdnnode.com
Server:           ns-293.awsdns-36.com
Address:    205.251.193.37#53

globalcdnnode.com
origin = ns-293.awsdns-36.com
mail addr = awsdns-hostmaster.amazon.com

At time of this writing, the domain delivery[.]globalcdnnode[.]com was still resolving, using fast-flux DNS techniques to resolve to a different IP address every couple minutes, thwarting attempts at shutting down the domain by constantly being on the move.

GlobalCDN_PLESK

Figure 5. – The familiar Plesk control panel, residing on the server.

This was a widespread campaign, indirectly affecting many web sites via malvertising techniques. The referring hosts run the gamut from local radio stations to high profile news, sports, and shopping sites. Given the large amounts of web traffic these types of sites see, its not surprising there was a tidal wave of requests to delivery[.]globalcdnnode[.]com. Every time a page with the malvertisement was loaded, a request was made to hXXp://delivery.globalcdnnode.com/7f01baa99716452bda5bba0572c58be9/afr-zone.php, in the background.

To give an example of what this activity looked like from DTI, you can see the numbers in the chart below.

 

Darkleech_splunk

Figure 6. – DTI graph showing number of Darkleech detections logged each day.

By using malvertising and or posing as a legitimate advertiser or content delivery network, the bad guys infiltrate the web advertisement ecosystem. This results in their malicious content getting loaded in your browser, often times in the background, while you browse sites that have nothing to do with the attack (as was the case in our careers site).

Imagine a scenario where a good portion of enterprise users have a home page set to a popular news website. More than likely, the main web page has advertisements, and some of those ads could be served from 3rd party advertiser networks and or CDNs. If just one of those advertisements on the page is malicious, visitors to that page are at risk of redirection and or infection, even though the news website’s server is itself clean.

So, when everybody shows up to work on Monday and opens their browsers, there could be a wave of clients making requests to exploit kit landing pages, if Darkleech is lurking in those advertisement waters, you could end up with a leech or 2 attached to your network.

Critical Infrastructure Beyond the Power Grid

19 November 2013 at 21:26

The term "critical infrastructure" has earned its spot on the board of our ongoing game of cyber bingo--right next to "Digital Pearl Harbor," "Cyber 9/11," "SCADA" and "Stuxnet."

With "critical infrastructure" thrown about in references to cyber threats nearly every week, we thought it was time for a closer look at just what the term means-and what it means to other cyber threat actors.

The term "critical infrastructure" conjures up images of highways, electrical grids, pipelines, government facilities and utilities. But the U.S. government definition also includes economic security and public health. The Department of Homeland Security defines critical infrastructure as "Systems and assets, whether physical or virtual, so vital to the United States that the incapacity or destruction of such systems and assets would have a debilitating impact on security, national economic security, national public health or safety, or any combination of those matters."[1]

Certainly the U.S. definition is expansive, but some key cyber actors go a step further to include a more abstract "information" asset. Russian officials view information content, flow and influencers as an enormous component of critical infrastructure. Iran and China similarly privilege the security of their information assets in order to protect their governments.

The bottom line?

U.S. companies, who may have never considered themselves a plausible target for cyber threats, could become victims of offensive or defensive state cyber operations. Earlier this year several media outlets-including the New York Times and Washington Post-disclosed that they had been the victims of China-based intrusions. The Times and the Post linked the intrusions on their networks to their reporting on corruption in the upper echelons of the Chinese Communist Party and other issues.

These media outlets weren't sitting on plans for a new fighter jet or cutting edge wind turbines-information often assumed to be at risk for data theft. Rather, the reporters at the Times and Post were perched in key positions to influence U.S. government and public views of the Chinese leadership, possibly in a negative light. The Chinese government had conducted these intrusions against what it deemed critical infrastructure that supported the flow of valuable information.

Who's up next?

State actors motivated to target critical infrastructure (by their own definition or the U.S.') won't just be the usual attention grabbers in cyberspace. We estimate that Iran, Syria, and North Korea all have interest and would be able to conduct or direct some level of network operations. These states are also likely to conduct operations in the near term to identify red lines and gauge corporate and government reactions. With little reputational loss at stake, we expect actors sponsored by or associated with these states to target an array of critical infrastructure targets. Companies who serve as key information brokers-for the public or the U.S. government-should be particularly attuned to the criticality their work is assigned by a variety of cyber threat actors.

 


 

 

 

Leveraging the Power of Solutions and Intelligence

27 January 2014 at 20:40

Welcome to my first post as a FireEye™ employee! Many of you have asked me what I think of FireEye's acquisition of Mandiant. One of the aspects of the new company that I find most exciting is our increased threat intelligence capabilities. This post will briefly explore what that means for our customers, prospects, and the public.

By itself, Mandiant generates threat intelligence in a fairly unique manner from three primary sources. First, our professional services division learns about adversary tools, tactics, and procedures (TTPs) by assisting intrusion victims. This "boots on the ground" offering is unlike any other, in terms of efficiency (a small number of personnel required), speed (days or weeks onsite, instead of weeks or months), and effectiveness (we know how to remove advanced foes). By having consultants inside a dozen or more leading organizations every week of the year, Mandiant gains front-line experience of cutting-edge intrusion activity. Second, the Managed Defense™ division operates our software and provides complementary services on a multi-year subscription basis. This team develops long-term counter-intrusion experience by constantly assisting another set of customers in a managed security services model. Finally, Mandiant's intelligence team acquires data from a variety of sources, fusing it with information from professional services and managed defense. The output of all this work includes deliverables such as the annual M-Trends report and last year's APT1 document, both of which are free to the public. Mandiant customers have access to more intelligence through our software and services.

As a security software company, FireEye deploys powerful appliances into customer environments to inspect and (if so desired) quarantine malicious content. Most customers choose to benefit from the cloud features of the FireEye product suite. This decision enables community self-defense and exposes a rich collection of the world's worst malware. As millions more instances of FireEye's MVX technology expand to mobile, cloud and data center environments, all of us benefit in terms of protection and visibility. Furthermore, FireEye's own threat intelligence and services components generate knowledge based on their visibility into adversary software and activity. Recent examples include breaking news on Android malware, identifying Yahoo! systems serving malware, and exploring "cyber arms" dealers. Like Mandiant, FireEye's customers benefit from intelligence embedded into the MVX platforms.

Many have looked at the Mandiant and FireEye combination from the perspective of software and services. While these are important, both ultimately depend on access to the best threat intelligence available. As a combined entity, FireEye can draw upon nearly 2,000 employees in 40 countries, with a staff of security consultants, analysts, engineers, and experts not found in any other private organization. Stay tuned to the FireEye and Mandiant blogs as we work to provide an integrated view of adversary activity throughout 2014.

I hope you can attend the FireEye + Mandiant - 4 Key Steps to Continuous Threat Protection webinar on Wednesday, Jan 29 at 2pm ET. During the webinar Manish Gupta, FireEye SVP of Products, and Dave Merkel, Mandiant CTO and VP of Products will discuss why traditional IT security defenses are no longer the safeguards they once were and what's now needed to protect against today's advanced threats.

The 2013 FireEye Advanced Threat Report!

27 February 2014 at 14:00

FireEye has just released its 2013 Advanced Threat Report (ATR), which provides a high-level overview of the computer network attacks that FireEye discovered last year.

In this ATR, we focused almost exclusively on a small, but very important subset of our overall data analysis – the advanced persistent threat (APT).

APTs, due to their organizational structure, mission focus, and likely some level of nation-state support, often pose a more serious danger to enterprises than a lone hacker or hacker group ever could.

Over the long term, APTs are capable of cyber attacks that can rise to a strategic level, including widespread intellectual property theft, espionage, and attacks on national critical infrastructures.

The data contained in this report is gleaned from the FireEye Dynamic Threat Intelligence (DTI) cloud, and is based on attack metrics shared by FireEye customers around the world.

Its insight is derived from:

  • 39,504 cyber security incidents
  • 17,995 malware infections
  • 4,192 APT incidents
  • 22 million command and control (CnC) communications
  • 159 APT-associated malware families
  • CnC infrastructure in 206 countries and territories

FireEye 2013 Threat Report Final

Based on our data, the U.S., South Korea, and Canada were the top APT targets in 2013; the U.S., Canada, and Germany were targeted by the highest number of unique malware families.

The ATR describes attacks on 20+ industry verticals. Education, Finance, and High-Tech were the top overall targets, while Government, Services/Consulting, and High-Tech were targeted by the highest number of unique malware families.

In 2013, FireEye discovered eleven zero-day attacks. In the first half of the year, Java was the most common target for zero-days; in the second half, FireEye observed a surge in Internet Explorer (IE) zero-days that were used in watering hole attacks, including against U.S. government websites.

Last year, FireEye analyzed five times more Web-based security alerts than email-based alerts – possibly stemming from an increased awareness of spear phishing as well as a more widespread use of social media.

In sum, the 2013 ATR offers strong evidence that malware infections occur within enterprises at an alarming rate, that attacker infrastructure is global in scope, and that advanced attackers continue to penetrate legacy defenses, such as firewalls and anti-virus (AV), with ease.

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

16 June 2014 at 14:00

Executive Summary

FireEye Labs has been tracking a recent spike in malicious email detections that we attribute to a campaign that began in 2013. While malicious email campaigns are nothing new, this one is significant in that we are observing mass-targeting attackers adopting the malware evasion methods pioneered by the stealthier APT attackers. And this is certainly a high-volume business, with anywhere from a few hundred to ten thousand malicious emails sent daily – usually distributing between 50 and 500,000 emails per outbreak.

Through the FireEye Dynamic Threat Intelligence (DTI) cloud, FireEye Labs discovered that each and every major spike in email blasts brought a change in the attributes of their attack. These changes have made it difficult for anti-virus, IPS, firewalls and file-based sandboxes to keep up with the malware and effectively protect endpoints from infection. Worse, if past is prologue, we can expect other malicious, mass-targeting email operators to adopt this approach to bypass traditional defenses.

This blog will cover the trends of the campaign, as well as provide a short technical analysis of the payload.

Campaign Details

fig1

Figure 1: Attack Architecture

The campaign first appeared in late December of 2013 and has since been seen in fairly cyclical patterns each month. It appears that the threat actors behind this campaign are fairly responsive to published blogs and reports surrounding their malware techniques, tweaking their malware accordingly to continuously try and evade detection with success.

In late 2013, malware labeled as Kuluoz, the specific spam component of the Asprox botnet, was discovered to be the main payload of what would become the first malicious email campaign. Since then, the threat actors have continuously tweaked the malware by changing its hardcoded strings, remote access commands, and encryption keys.

Previously, Asprox malicious email campaigns targeted various industries in multiple countries and included a URL link in the body. The current version of Asprox includes a simple zipped email attachment that contains the malicious payload “exe.” Figure 2 below represents a sample message while Figure 3 is an example of the various court-related email headers used in the campaign.

fig2

Figure 2 Email Sample

fig3

Figure 3 Email Headers

Some of the recurring campaign that Asporox used includes themes focused around airline tickets, postal services and license keys. In recent months however, the court notice and court request-themed emails appear to be the most successful phishing scheme theme for the campaign.

The following list contains examples of email subject variations, specifically for the court notice theme:

  • Urgent court notice
  • Notice to Appear in Court
  • Notice of appearance in court
  • Warrant to appear
  • Pretrial notice
  • Court hearing notice
  • Hearing of your case
  • Mandatory court appearance

The campaign appeared to increase in volume during the month of May. Figure 4 shows the increase in activity of Asprox compared to other crimewares towards the end of May specifically. Figure 5 highlights the regular monthly pattern of overall malicious emails. In comparison, Figure 6 is a compilation of all the hits from our analytics.

fig4

Figure 4 Worldwide Crimeware Activity

fig5

Figure 5 Overall Asprox Botnet tracking

fig6

Figure 6 Asprox Botnet Activity Unique Samples

These malicious email campaign spikes revealed that FireEye appliances, with the support of DTI cloud, were able to provide a full picture of the campaign (blue), while only a fraction of the emailed malware samples could be detected by various Anti-Virus vendors (yellow).

fig7

Figure 7 FireEye Detection vs. Anti-Virus Detection

By the end of May, we observed a big spike on the unique binaries associated with this malicious activity. Compared to the previous days where malware authors used just 10-40 unique MD5s or less per day, we saw about 6400 unique MD5s sent out on May 29th. That is a 16,000% increase in unique MD5s over the usual malicious email campaign we’d observed. Compared to other recent email campaigns, Asprox uses a volume of unique samples for its campaign.

fig8

Figure 8 Asprox Campaign Unique Sample Tracking

fig9

Figure 9 Geographical Distribution of the Campaign

fig10

Figure 10 Distribution of Industries Affected

Brief Technical Analysis

fig11

Figure 11 Attack Architecture

Infiltration

The infiltration phase consists of the victim receiving a phishing email with a zipped attachment containing the malware payload disguised as an Office document. Figure 11 is an example of one of the more recent phishing attempts.

fig12

Figure 12 Malware Payload Icon

Evasion

Once the victim executes the malicious payload, it begins to start an svchost.exe process and then injects its code into the newly created process. Once loaded into memory, the injected code is then unpacked as a DLL. Notice that Asprox uses a hardcoded mutex that can be found in its strings.

  1. Typical Mutex Generation
    1. "2GVWNQJz1"
  2. Create svchost.exe process
  3. Code injection into svchost.exe

Entrenchment

Once the dll is running in memory it then creates a copy of itself in the following location:

%LOCALAPPDATA%/[8 CHARACTERS].EXE

Example filename:

%LOCALAPPDATA%\lwftkkea.exe

It’s important to note that the process will first check itself in the startup registry key, so a compromised endpoint will have the following registry populated with the executable:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

Exfiltration/Communication

The malware uses various encryption techniques to communicate with the command and control (C2) nodes. The communication uses an RSA (i.e. PROV_RSA_FULL) encrypted SSL session using the Microsoft Base Cryptographic Provider while the payloads themselves are RC4 encrypted. Each sample uses a default hardcoded public key shown below.

Default Public Key

-----BEGIN PUBLIC KEY-----

MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDCUAUdLJ1rmxx+bAndp+Cz6+5I'

Kmgap2hn2df/UiVglAvvg2US9qbk65ixqw3dGN/9O9B30q5RD+xtZ6gl4ChBquqw

jwxzGTVqJeexn5RHjtFR9lmJMYIwzoc/kMG8e6C/GaS2FCgY8oBpcESVyT2woV7U

00SNFZ88nyVv33z9+wIDAQAB

-----END PUBLIC KEY-----

First Communication Packet

Bot ID RC4 Encrypted URL

POST /5DBA62A2529A51B506D197253469FA745E7634B4FC

HTTP/1.1

Accept: */*

Content-Type: application/x-www-form-urlencoded

User-Agent: <host useragent>

Host: <host ip>:443

Content-Length: 319

Cache-Control: no-cache

<knock><id>5DBA62A247BC1F72B98B545736DEA65A</id><group>0206s</group><src>3</src><transport>0</transport><time>1881051166</time><version>1537</version><status>0</status><debug>none<debug></knock>

C2 Commands

In comparison to the campaign at the end of 2013, the current campaign uses one of the newer versions of the Asprox family where threat actors added the command “ear.”

if ( wcsicmp(Str1, L"idl") )

{

if ( wcsicmp(Str1, L"run") )

{

if ( wcsicmp(Str1, L"rem") )

{

if ( wcsicmp(Str1, L"ear")

{

if ( wcsicmp(Str1, L"rdl") )

{

if ( wcsicmp(Str1, L"red") )

{

if ( !wcsicmp(Str1, L"upd") )

C2 commands Description
idl idl This commands idles the process to wait for commands This commands idles the process to wait for commands
run run Download from a partner site and execute from a specified path Download from a partner site and execute from a specified path
rem rem Remove itself Remove itself
ear ear Download another executable and create autorun entry Download another executable and create autorun entry
rdl rdl Download, inject into svchost, and run Download, inject into svchost, and run
upd upd Download and update Download and update
red red Modify the registry Modify the registry

C2 Campaign Characteristics

fig13

For the two major malicious email campaign spikes in April and May of 2014, separate sets of C2 nodes were used for each major spike.

April May-June
94.23.24.58 94.23.24.58 192.69.192.178 192.69.192.178
94.23.43.184 94.23.43.184 213.21.158.141 213.21.158.141
1.234.53.27 1.234.53.27 213.251.150.3 213.251.150.3
84.124.94.52 84.124.94.52 27.54.87.235 27.54.87.235
133.242.134.76 133.242.134.76 61.19.32.24 61.19.32.24
173.45.78.226 173.45.78.226 69.64.56.232 69.64.56.232
37.59.9.98 37.59.9.98 72.167.15.89 72.167.15.89
188.93.74.192 188.93.74.192 84.234.71.214 84.234.71.214
187.16.250.214 187.16.250.214 89.22.96.113 89.22.96.113
85.214.220.78 85.214.220.78 89.232.63.147 89.232.63.147
91.121.20.71 91.121.20.71
91.212.253.253 91.212.253.253
91.228.77.15 91.228.77.15

Conclusion

The data reveals that each of the Asprox botnet’s malicious email campaigns changes its method of luring victims and C2 domains, as well as the technical details on monthly intervals. And, with each new improvement, it becomes more difficult for traditional security methods to detect certain types of malware.

Acknowledgements:

Nart Villeneuve, Jessa dela Torre, and David Sancho. Asprox Reborn. Trend Micro. 2013. http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-asprox-reborn.pdf

Havex, It’s Down With OPC

17 July 2014 at 14:00

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

The Five W’s of Penetration Testing

16 September 2014 at 20:49

Often in discussions with customers and potential customers, questions arise about our penetration testing services, as well as penetration testing in general. In this post, we want to walk through Mandiant's take on the five W's of penetration testing, in hopes of helping those of you who many have some of these same questions. For clarity, we are going to walk through these W's in a non-traditional order.

Why

First and foremost, it's important to be upfront with yourself with why you are having a penetration test performed (or at least considering one). If your organization's primary motivation is compliance and needing to "check the box," then be on the lookout for your people attempting to subtly (or not so subtly) hinder the test in order to earn an "easy pass" by minimizing the number of findings (and therefore the amount of potential remediation work required). Individuals could attempt to hinder a penetration test by placing undue restrictions on the scope of systems assessed, the types of tools that can be used, or the timing of the test.

Even if compliance is a motivating factor, we hope you're able to take advantage of the opportunity penetration testing provides to determine where vulnerabilities lie and make your systems more secure. That is the real value that penetration testing can provide.

Finally, if you are getting a penetration test to comply with requirements imposed on your organization, that will often drive some of the answers to later questions about the type and scope of the test. Keep in mind that standards only dictate minimum requirements, however, so you should also consider additional penetration testing activities beyond the "bare minimum."

Who

There are really two "who" questions to consider, but for now we will just deal with the first: Who are the attackers that concern you? Are they:

  1. Random individuals on the Internet?
  2. Specific threat actors, such as state-sponsored attackers, organized criminals, or hacktivist groups?
  3. An individual or malware that is behind the firewall and on your internal corporate network?
  4. Your own employees ("insider threats")?
  5. Your customers (or attackers who may compromise customers' systems/accounts)?
  6. Your vendors, service providers, and other business partners (or attackers who may have compromised their systems)?

The answer to this will help drive the type of testing to be performed and the types of test user accounts (if any) to provision. The next section will describe some possible penetration test types, but it's helpful to also discuss the types of attackers you would like the penetration test to simulate.

What

What type of penetration test do you want performed? For organizations new to penetration testing, we recommend starting with an external network penetration test, which will assess your Internet-accessible systems in the same way that an attacker anywhere in the world could access them. Beyond that, there are several options:

  1. Internal network penetration test - A penetration test of your internal corporate network. Typically we start these types of assessments with only a network connection on the corporate networks, but a common variant is what we call an "Insider Threat Assessment," where we start with one of your standard workstations and a standard user account.
  2. Web application security assessment - A review of custom web application code for security vulnerabilities such as access control issues, SQL injection, cross-site scripting (XSS) and others. These are best done in a test or development environment to minimize impact to the production environment.
  3. Social engineering - Using deceptive email, phone calls, and/or physical entry to gain access to systems.
  4. Wireless penetration test - A detailed security assessment of wireless network(s) at one or more of your locations. This typically includes a survey of the location looking for unauthorized ("rogue") wireless access points that have been connected to the corporate network and are often insecurely configured.

If budgets were not an issue, you would want to do all of the above, but in reality you will need to prioritize your efforts on what makes sense for your organization. Keep in mind that the best approach may change over time as your organization matures.

Where

In what physical location should the test take place? Many types of penetration testing can be done remotely, but some require the testers to visit your facility. Physical social engineering engagements and wireless assessments clearly need to be performed at one (or more) of your locations.

Some internal penetration tests can be done remotely via a VPN connection, but we recommend conducting them at your location whenever possible. If your internal network has segmentation in place (as we recommend), then you should work with your penetration testing organization to determine the best physical location for the test to be performed. Generally, you'll want to do the internal penetration test from a network segment that has broad access to other portions of the internal network in order to get the best coverage from the test.

Another "Where" to consider for remote testing is where the testers are physically located. When testers are in a different country than you, legal issues can arise with data provisioning and accessibility. Differences in language, culture, and time zones could also make coordination and interpretation of results more difficult.

When

We recommend that most organizations get some sort of security assessment on an annual basis, but that security assessment does not necessarily need to be a penetration test (see Penetration Testing Has Come Of Age - How to Take Your Security Program to the Next Level). Larger organizations may have multiple assessments per year, each focused in a different area.

Within the year, the timing of the penetration test is usually pretty flexible. You will want to make sure that the right people from your organization are available to initiate and manage the test - and to receive results and begin implementing changes. Based on your organization's change control procedures, you may need to work around system freezes or other activities. Testing in December can be difficult due to holidays and vacation, along with year-end closeout activities, especially for organizations in retail, e-commerce, and payment processing.

If you have significant upgrades planned for the systems that will be tested, it is typically best to schedule the test for a month or two after the upgrades are due to be finished. This will allow some time for the inevitable delays in deploying the upgrades as well give the upgraded systems (and their administrators) a bit of time to "settle in" and get fully configured before being tested.

Who (part 2)

The other "who" question to consider is who will perform the penetration test? We recommend considering the following when selecting a penetration testing provider:

  1. What are the qualifications of the organization and the individuals who will be performing the test? What differentiates them from other providers?
  2. To what degree does their testing rely on automated vulnerability scanners vs. hands on manual testing?
  3. How well do they understand the threat actors that are relevant to your environment? How well are they able to emulate real world attacks?
  4. What deliverables will you receive from the test? Are they primarily the output of an automated tool? Ask for samples.
  5. Are they unbiased? Do they use penetration tests as a means to sell or resell other products and services?

No doubt, there are other questions that you will want to consider when scoping a penetration test, but we hope that these will help you get started. If you'd like to read more about Mandiant's penetration testing (and other) services, you can do so here. Of course, also feel free to contact us if you'd like to talk about your situation and how Mandiant can best assess your organization's security.

New Tactics. New Motives. New Services.

8 October 2014 at 19:16

Every day at Mandiant we respond to some of the largest cyber security incidents around the world. This gives us a front-row seat to witness what works (and what doesn't) when it comes to finding attackers and preventing them from stealing our clients' data.

Attackers' tactics and motives are evolving and as a result our security strategies also need to adapt. Today, we announced two new service offerings that will further help our clients improve their protective, detective, and responsive security controls and leverage Mandiant's extensive experience responding to some of the most serious cyber security incidents.

Our first new service offering addresses attackers' expanding motives. We are starting to see attackers with destructive motives and what could be more damaging than attacking a nation's critical infrastructure. Security incidents at critical infrastructure such as electric power grids, utilities and manufacturing companies can affect the lives of hundreds of thousands of people. Our new Industrial Control Systems (ICS) Security Gap Assessment is specifically focused on helping these industries - and others that use SCADA systems - to assess their existing security processes for industrial control systems. The service helps identify security GAPs and provides specific recommendations to close those GAPs and safeguard critical infrastructure.

Our second new service offering is designed to help organizations address the challenges they face as they build out their own internal security operations program and incident response teams. Many organizations want to enhance their internal capabilities beyond the traditional security operations centers (SOCs). Our new Cyber Defense Center Development service helps organizations evolve their internal SOC by improving the visibility (monitoring and detection) and response capabilities (incident response) necessary to defend against advanced threats. This service looks at existing people, process, and technologies and identifies areas for improvement. It helps companies to identify and prioritize the alerts that require the most immediate action with the goal to reduce the mean time to remediation.

If either of these new services sound like something that could help your organization let us know.

Operation RussianDoll: Adobe & Windows Zero-Day Exploits Likely Leveraged by Russia’s APT28 in Highly-Targeted Attack

18 April 2015 at 16:10

FireEye Labs recently detected a limited APT campaign exploiting zero-day vulnerabilities in Adobe Flash and a brand-new one in Microsoft Windows. Using the Dynamic Threat Intelligence Cloud (DTI), FireEye researchers detected a pattern of attacks beginning on April 13th, 2015. Adobe independently patched the vulnerability (CVE-2015-3043) in APSB15-06. Through correlation of technical indicators and command and control infrastructure, FireEye assess that APT28 is probably responsible for this activity.

Microsoft is aware of the outstanding local privilege escalation vulnerability in Windows (CVE-2015-1701). While there is not yet a patch available for the Windows vulnerability, updating Adobe Flash to the latest version will render this in-the-wild exploit innocuous. We have only seen CVE-2015-1701 in use in conjunction with the Adobe Flash exploit for CVE-2015-3043. The Microsoft Security Team is working on a fix for CVE-2015-1701.

Exploit Overview

The high level flow of the exploit is as follows:

1.       User clicks link to attacker controlled website
2.       HTML/JS launcher page serves Flash exploit
3.       Flash exploit triggers CVE-2015-3043, executes shellcode
4.       Shellcode downloads and runs executable payload
5.       Executable payload exploits local privilege escalation (CVE-2015-1701) to steal System token

The Flash exploit is served from unobfuscated HTML/JS. The launcher page picks one of two Flash files to deliver depending upon the target’s platform (Windows 32 versus 64bits).

The Flash exploit is mostly unobfuscated with only some light variable name mangling. The attackers relied heavily on the CVE-2014-0515 Metasploit module, which is well documented. It is ROPless, and instead constructs a fake vtable for a FileReference object that is modified for each call to a Windows API.

The payload exploits a local privilege escalation vulnerability in the Windows kernel if it detects that it is running with limited privileges. It uses the vulnerability to run code from userspace in the context of the kernel, which modifies the attacker’s process token to have the same privileges as that of the System process.

CVE-2015-3043 Exploit

The primary difference between the CVE-2014-0515 metasploit module and this exploit is, obviously, the vulnerability. CVE-2014-0515 exploits a vulnerability in Flash’s Shader processing, whereas CVE-2015-3043 exploits a vulnerability in Flash’s FLV processing. The culprit FLV file is embedded within AS3 in two chunks, and is reassembled at runtime.

Vulnerability

A buffer overflow vulnerability exists in Adobe Flash Player (<=17.0.0.134) when parsing malformed FLV objects. Attackers exploiting the vulnerability can corrupt memory and gain remote code execution.

In the exploit, the attacker embeds the FLV object directly in the ActionScript code, and plays the video using NetStream class. In memory, it looks like the following:

0000000: 46 4c 56 01 05 00 00 00 09 00 00 00 00 12 00 00  FLV.............
0000010: f4 00 00 00 00 00 00 00 02 00 0a 6f 6e 4d 65 74  ...........onMet
0000020: 61 44 61 74 61 08 00 00 00 0b 00 08 64 75 72 61  aData.......dura
0000030: 74 69 6f 6e 00 40 47 ca 3d 70 a3 d7 0a 00 05 77  [email protected]=p.....w
0000040: 69 64 74 68 00 40 74 00 00 00 00 00 00 00 06 68  [email protected]
0000050: 65 69 67 68 74 00 40 6e 00 00 00 00 00 00 00 0d  [email protected]
0000060: 76 69 64 65 6f 64 61 74 61 72 61 74 65 00 00 00  videodatarate...
…..
0003b20: 27 6e ee 72 87 1b 47 f7 41 a0 00 00 00 3a 1b 08  'n.r..G.A....:..
0003b30: 00 04 41 00 00 0f 00 00 00 00 68 ee ee ee ee ee  ..A.......h.....
0003b40: ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee  ................
0003b50: ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee  ................
0003b60: ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee  ................

Files of the FLV file format contain a sequence of Tag structures. In Flash, these objects are created when parsing FLV Tags:

.text:1018ACE9 sub_1018ACE9    proc near               ; CODE XREF: sub_1018BBAC+2Bp
.text:1018ACE9                                         ; sub_10192797+1A1p ...
.text:1018ACE9
.text:1018ACE9 arg_0           = dword ptr  4
.text:1018ACE9
.text:1018ACE9                 mov     eax, ecx
.text:1018ACEB                 mov     ecx, [esp+arg_0]
.text:1018ACEF                 mov     dword ptr [eax], offset off_10BA771C
.text:1018ACF5                 mov     dword ptr [eax+24h], 1
.text:1018ACFC                 and     dword ptr [eax+14h], 0
.text:1018AD00                 mov     [eax+28h], ecx
.text:1018AD03                 mov     byte ptr [eax+20h], 0
.text:1018AD07                 retn    4
.text:1018AD07 sub_1018ACE9    endp

In the case of this exploit, a Tag structure begins at offset 0x3b2f into the FLV stream that, when parsed, populates the Tag structure as follows:

Tag 2:
UINT_8 type: 8
UINT_24 datasize: 1089
UINT_24 timestamp: 15
UINT_8 timestamphi: 0
UINT_24 streamid: 0
UINT_4 fmt: 6
UINT_2 sr: 2
UINT_1 bits: 0
UINT_1 channels: 0
UBYTE data[1088]: \xee\xee\xee\xee…
UINT_32 lastsize: 0xeeeeeeee

Beginning within the data field, all contents of the FLV stream become 0xEE. Consequently, the data and lastsize fields are mangled, and one final tag technically exists consisting exclusively of 0xEE:

Tag 3:
UINT_8 type: 0xEE
UINT_24 datasize: 0xEEEEEE

One can see the datasize field of Tag2 populated from the attacker's FLV stream below:


.text:10192943                 mov     eax, [ebx+24h]
.text:10192946                 mov     [esi+14h], eax
.text:10192949                 movzx   eax, byte ptr [ebx+19h] ; 00
.text:1019294D                 movzx   ecx, byte ptr [ebx+1Ah] ; 04
.text:10192951                 shl     eax, 8
.text:10192954                 or      eax, ecx
.text:10192956                 movzx   ecx, byte ptr [ebx+1Bh] ; 41
.text:1019295A                 shl     eax, 8
.text:1019295D                 or      eax, ecx
.text:1019295F                 mov     ecx, ebx
.text:10192961                 mov     [esi+0Ch], eax  ; 0x441
.text:10192964                 call    sub_1002E2B3

The buffer is allocated with fixed size 0x2000:

.text:101A647E                 push    2000h
.text:101A6483                 mov     ecx, esi
.text:101A6485                 call    sub_101A6257    ; alloc 0x2000 buffer, store in esi+0xDC
……
.text:101A627F                 push    0
.text:101A6281                 push    edi             ; 0x2000
.text:101A6282                 call    sub_105EBEB0
.text:101A6287                 pop     ecx
.text:101A6288                 pop     ecx
.text:101A6289                 mov     [esi+0DCh], eax

Since the size is controlled by the attacker, it’s possible to overflow the fixed size buffer with certain data.

A datasize of 0x441 results in a value here of 0x1100 passed to sub_100F88F8, which memcopies 0x2200 bytes in 0x11 chunks of 0x200. The last memcpy overflows the fixed size 0x2000 buffer into a adjacent heap memory.

Attackers spray the heap with array of Vector, 0x7fe * 4 + 8 == 0x2000, and create holes of such size, which will be allocated by the said object.

            while (_local_2 < this._bp35) // _bp35 == 0x2000
            {
               this._ok47[_local_2] = new Vector.<uint>(this._lb60); // _lb60 == 0x07FE
               _local_3 = 0x00;
              while (_local_3 < this._lb60)
              {
                  this._ok47[_local_2][_local_3] = 0x41414141;
                  _local_3++;
               };
               _local_2 = (_local_2 + 0x01);
             };
             _local_2 = 0x00;
            while (_local_2 < this._bp35)
            {
               this._ok47[_local_2] = null;
               _local_2 = (_local_2 + 0x02);
             };

As the previous picture demonstrated, the followed Vector object’s length field being overflowed as 0x80007fff, which enables the attacker to read/write arbitrary data within user space.

Shellcode

Shellcode is passed to the exploit from HTML in flashvars. The shellcode downloads the next stage payload, which is an executable passed in plaintext, to the temp directory with UrlDownloadToFileA, which it then runs with WinExec.

Payload & C2

This exploit delivers a malware variant that shares characteristics with the APT28 backdoors CHOPSTICK and CORESHELL malware families, both described in our APT28 whitepaper.  The malware uses an RC4 encryption key that was previously used by the CHOPSTICK backdoor.  And the C2 messages include a checksum algorithm that resembles those used in CHOPSTICK backdoor communications.  In addition, the network beacon traffic for the new malware resembles those used by the CORESHELL backdoor.  Like CORESHELL, one of the beacons includes a process listing from the victim host.  And like CORESHELL, the new malware attempts to download a second-stage executable.

One of the C2 locations for the new payload, 87.236.215[.]246, also hosts a suspected APT28 domain ssl-icloud[.]com.  The same subnet (87.236.215.0/24) also hosts several known or suspected APT28 domains, as seen in Table 1.

The target firm is an international government entity in an industry vertical that aligns with known APT28 targeting.

CVE-2015-1701 Exploit

The payload contains an exploit for the unpatched local privilege escalation vulnerability CVE-2015-1701 in Microsoft Windows. The exploit uses CVE-2015-1701 to execute a callback in userspace. The callback gets the EPROCESS structures of the current process and the System process, and copies data from the System token into the token of the current process. Upon completion, the payload continues execution in usermode with the privileges of the System process.

Because CVE-2015-3043 is already patched, this remote exploit will not succeed on a fully patched system. If an attacker wanted to exploit CVE-2015-1701, they would first have to be executing code on the victim’s machine. Barring authorized access to the victim’s machine, the attacker would have to find some other means, such as crafting a new Flash exploit, to deliver a CVE-2015-1701 payload.

Microsoft is aware of CVE-2015-1701 and is working on a fix. CVE-2015-1701 does not affect Windows 8 and later.

Acknowledgements

Thank you to all of the contributors to this blog!

  • The following people in FireEye: Dan Caselden, Yasir Khalid, James “Tom” Bennett, GenWei Jiang, Corbin Souffrant, Joshua Homan, Jonathan Wrolstad, Chris Phillips, Darien Kindlund
  • Microsoft & Adobe security teams

 

Citrix XenApp and XenDesktop Hardening Guidance

15 March 2016 at 12:00
A Joint Whitepaper from Mandiant and Citrix

Throughout the course of Mandiant’s Red Team and Incident Response engagements, we frequently identify a wide array of misconfigured technology solutions, including Citrix XenApp and XenDesktop.

We often see attackers leveraging stolen credentials from third parties, accessing Citrix solutions, breaking out of published applications, accessing the underlying operating systems, and moving laterally to further compromise the environment. Our experience shows that attackers are increasingly using Citrix solutions to remotely access victim environments post-compromise, instead of using traditional backdoors, remote access tools, or other types of malware. Using a legitimate means of remote access enables attackers to blend in with other users and fly under the radar of security monitoring tools.

Citrix provides extensive security hardening guidance and templates to their customers to mitigate the risk of these types of attacks. The guidance is contained in product-specific eDocs, Knowledge Base articles and detailed Common Criteria configurations. System administrators (a number of them wearing many hats and juggling multiple projects) may not have the time to review all of the hardening documentation available, so Mandiant and Citrix teamed up to provide guidance on the most significant risks posed to Citrix XenApp and XenDesktop implementations in a single white paper.

This white paper covers risks and official Citrix hardening guidance for the following topics:

  • Environment and Application Jailbreaking
  • Network Boundary Jumping
  • Authentication Weaknesses
  • Authorization Weaknesses
  • Inconsistent Defensive Measures
  • Non-configured or Misconfigured Logging and Alerting

The white paper is available here.

IRONGATE ICS Malware: Nothing to See Here...Masking Malicious Activity on SCADA Systems

2 June 2016 at 12:00

In the latter half of 2015, the FireEye Labs Advanced Reverse Engineering (FLARE) team identified several versions of an ICS-focused malware crafted to manipulate a specific industrial process running within a simulated Siemens control system environment. We named this family of malware IRONGATE.

FLARE found the samples on VirusTotal while researching droppers compiled with PyInstaller — an approach used by numerous malicious actors. The IRONGATE samples stood out based on their references to SCADA and associated functionality. Two samples of the malware payload were uploaded by different sources in 2014, but none of the antivirus vendors featured on VirusTotal flagged them as malicious.

Siemens Product Computer Emergency Readiness Team (ProductCERT) confirmed that IRONGATE is not viable against operational Siemens control systems and determined that IRONGATE does not exploit any vulnerabilities in Siemens products. We are unable to associate IRONGATE with any campaigns or threat actors. We acknowledge that IRONGATE could be a test case, proof of concept, or research activity for ICS attack techniques.

Our analysis finds that IRONGATE invokes ICS attack concepts first seen in Stuxnet, but in a simulation environment. Because the body of industrial control systems (ICS) and supervisory control and data acquisition (SCADA) malware is limited, we are sharing details with the broader community.

Malicious Concepts

Deceptive Man-in-the-Middle

IRONGATE's key feature is a man-in-the-middle (MitM) attack against process input-output (IO) and process operator software within industrial process simulation. The malware replaces a Dynamic Link Library (DLL) with a malicious DLL, which then acts as a broker between a PLC and the legitimate monitoring software. This malicious DLL records five seconds of 'normal' traffic from a PLC to the user interface and replays it, while sending different data back to the PLC. This could allow an attacker to alter a controlled process unbeknownst to process operators.

Sandbox Evasion

IRONGATE's second notable feature involves sandbox evasion. Some droppers for the IRONGATE malware would not run if VMware or Cuckoo Sandbox environments were employed. The malware uses these techniques to avoid detection and resist analysis, and developing these anti-sandbox techniques indicates that the author wanted the code to resist casual analysis attempts. It also implies that IRONGATE’s purpose was malicious, as opposed to a tool written for other legitimate purposes.

Dropper Observables

We first identified IRONGATE when investigating droppers compiled with PyInstaller — an approach used by numerous malicious actors. In addition, strings found in the dropper include the word “payload”, which is commonly associated with malware.

Unique Features for ICS Malware

While IRONGATE malware does not compare to Stuxnet in terms of complexity, ability to propagate, or geopolitical implications, IRONGATE leverages some of the same features and techniques Stuxtnet used to attack centrifuge rotor speeds at the Natanz uranium enrichment facility; it also demonstrates new features for ICS malware.

  • Both pieces of malware look for a single, highly specific process.
  • Both replace DLLs to achieve process manipulation.
  • IRONGATE detects malware detonation/observation environments, whereas Stuxnet looked for the presence of antivirus software.
  • IRONGATE actively records and plays back process data to hide manipulations, whereas Stuxnet did not attempt to hide its process manipulation, but suspended normal operation of the S7-315 so even if rotor speed had been displayed on the HMI, the data would have been static.

A Proof of Concept

IRONGATE’s characteristics lead us to conclude that it is a test, proof of concept, or research activity.

  • The code is specifically crafted to look for a user-created DLL communicating with the Siemens PLCSIM environment. PLCSIM is used to test PLC program functionality prior to in-field deployment. The DLLs that IRONGATE seeks and replaces are not part of the Siemens standard product set, but communicate with the S7ProSim COM object. Malware authors test concepts using commercial simulation software.
  • Code in the malicious software closely matched usage on a control engineering blog dealing with PLCSIM (https://alexsentcha.wordpress.com/using-s7-prosim-with-siemens-s7-plcsim/ and https://pcplcdemos.googlecode.com/hg/S7PROSIM/BioGas/S7%20v5.5/).
  • While we have identified and analyzed several droppers for the IRONGATE malware, we have yet to identify the code’s infection vector.
  • In addition, our analysis did not identify what triggers the MitM payload to install; the scada.exe binary that deploys the IRONGATE DLL payload appears to require manual execution.
  • We have not identified any other instances of the ICS-specific IRONGATE components (scada.exe and Step7ProSim.dll), despite their having been compiled in September of 2014.
  • Siemens ProductCERT has confirmed that the code would not work against a standard Siemens control system environment.

Implications for ICS Asset Owners

Even though process operators face no increased risk from the currently identified members of the IRONGATE malware family, IRONGATE provides valuable insight into adversary mindset.

Network security monitoring, indicator of compromise (IoC) matching, and good practice guidance from vendors and other stakeholders represent important defensive techniques for ICS networks.

To specifically counter IRONGATE’s process attack techniques, ICS asset owners may, over the longer term, implement solutions that:

  • Require integrity checks and code signing for vendor and user generated code. Lacking cryptographic verification facilitates file replacement and MitM attacks against controlled industrial processes.
  • Develop mechanisms for sanity checking IO data, such as independent sensing and backhaul, and comparison with expected process state information. Ignorance of expected process state facilitates an attacker’s ability to achieve physical consequence without alarming operators.

Technical Malware Analysis

IRONGATE Dropper Family

FireEye has identified six IRONGATE droppers: bla.exe, update.exe1, update_no_pipe.exe1, update_no_pipe.exe2, update_no_pipe.exe2, update.exe3. All but one of these Python-based droppers first checks for execution in a VMware or Cuckoo Sandbox environment. If found, the malware exits.

If not found, the IRONGATE dropper extracts a UPX-packed, publicly available utility (NirSoft NetResView version 1.27) to audiodg.exe in the same directory as the dropper. The dropper then executes the utility using the command audiodg.exe /scomma scxrt2.ini. This command populates the file scxrt2.ini with a comma-separated list of network resources identified by the host system.

The dropper iterates through each entry in scxrt2.ini, looking for paths named move-to-operational or move-to-operational.lnk. If a path is found, the dropper first extracts the Base64-encoded .NET executable scada.exe to the current directory and then moves the file to the path containing move-to-operational or move-to-operational.lnk. The path move-to-operational is interesting as well, perhaps implying that IRONGATE was not seeking the actual running process, but rather a staging area for code promotion. The dropper does not execute the scada.exe payload after moving it.

Anti-Analysis Techniques

Each IRONGATE dropper currently identified deploys the same .NET payload, scada.exe. All but one of the droppers incorporated anti-detection/analysis techniques to identify execution in VMware or the Cuckoo Sandbox. If such environments are detected, the dropper will not deploy the .NET executable (scada.exe) to the host.

Four of the droppers (update.exe1, update_no_pipe.exe1, update_no_pipe.exe2, and update.exe3) detect Cuckoo environments by scanning subdirectories of the %SystemDrive%. Directories with names greater than five, but fewer than ten characters are inspected for the subdirectories drop, files, logs, memory, and shots. If a matching directory is found, the dropper does not attempt to deploy the scada.exe payload.

The update.exe1 and update.exe3 droppers contain code for an additional Cuckoo check using the SysInternals pipelist program, install.exe, but the code is disabled in each.

The update.exe2 dropper includes a check for VMware instead of Cuckoo. The VMWare check looks for the registry key HKLM\SOFTWARE\VMware, Inc.\VMware Tools and the files %WINDIR%\system32\drivers\vmmouse.sys and %WINDIR%\system32\drivers\vmhgfs.sys. If any of these are found, the dropper does not attempt to deploy the scada.exe payload.

The dropper bla.exe does not include an environment check for either Cuckoo or VMware.

scada.exe Payload

We surmise that scada.exe is a user-created payload used for testing the malware. First, our analysis did not indicate what triggers scada.exe to run. Second, Siemens ProductCERT informed us that scada.exe is not a default file name associated with Siemens industrial control software.

When scada.exe executes, it scans drives attached to the system for filenames ending in Step7ProSim.dll. According to the Siemens ProductCERT, Step7ProSim.dll is not part of the Siemens PLCSIM software. We were unable to determine whether this DLL was created specifically by the malware author, or if it was from another source, such as example code or a particular custom ICS implementation. We surmise this DLL simulates generation of IO values, which would normally be provided by an S7-based controller, since the functions it includes appear derived from the Siemens PLCSIM environment.

If scada.exe finds a matching DLL file name, it kills all running processes with the name biogas.exe. The malware then moves Step7ProSim.dll to Step7ConMgr.dll and drops a malicious Step7ProSim.dll – the IRONGATE payload – to the same directory.

The malicious Step7ProSim.dll acts as an API proxy between the original user-created Step7ProSim.dll (now named Step7ConMgr.dll) and the application biogas.exe that loads it. Five seconds after loading, the malicious Step7ProSim.dll records five seconds of calls to ReadDataBlockValue. All future calls to ReadDataBlockValue return the recorded data.

Simultaneously, the malicious DLL discards all calls to WriteDataBlockValue and instead calls WriteInputPoint(0x110, 0, 0x7763) and WriteInputPoint(0x114, 0, 0x7763) every millisecond. All of these functions are named similarly to Siemens S7ProSim v5.4 COM interface. It appears that other calls to API functions are passed through the malicious DLL to the legitimate DLL with no other modification.

Biogas.exe

As mentioned previously, IRONGATE seeks to manipulate code similar to that found on a blog dealing with simulating PLC communications using PLCSIM, including the use of an executable named biogas.exe.

Examination of the executable from that blog’s demo code shows that the WriteInputPoint function calls with byte indices 0x110 and 0x114 set pressure and temperature values, respectively:

IRONGATE:

         WriteInputPoint(0x110, 0, 0x7763)
WriteInputPoint(0x114, 0, 0x7763)

 Equivalent pseudo code from Biogas.exe: 

        S7ProSim.WriteInputPoint(0x110, 0, (short)this.Pressure.Value)
     S7ProSim.WriteInputPoint(0x114, 0, (short)this.Temperature.Value)

We have been unable to determine the significance of the hardcoded value 0x7763, which is passed in both instances of the write function.

Because of the noted indications that IRONGATE is a proof of concept, we cannot conclude IRONGATE’s author intends to manipulate specific temperature or pressure values associated with the specific biogas.exe process, but find the similarities to this example code striking.

Artifacts and Indicators

PyInstaller Artifacts

The IRONGATE droppers are Python scripts converted to executables using PyInstaller. The compiled droppers contain PyInstaller artifacts from the system the executables were created on. These artifacts may link other samples compiled on the same system. Five of the six file droppers (bla.exe, update.exe1, update_no_pipe.exe1, update_no_pipe.exe2 and update.exe3) all share the same PyInstaller artifacts listed in Table 1.

Table 1: Pyinstaller Artifacts

The remaining dropper, update.exe2, contains the artifacts listed in Table 2.

Table 2: Pyinstaller Artifacts for update.exe2

Unique Strings

Figure 1 and 2 list the unique strings discovered in the scada.exe and Step7ProSim.dll binaries.

Figure 1: Scada.exe Unique Strings

Figure 2: Step7ProSim.dll Unique Strings

File Hashes

Table 3 contains the MD5 hashes, file and architecture type, and compile times for the malware analyzed in this report.

Table 3: File MD5 Hashes and Compile Times

FireEye detects IRONGATE. A list of indicators can be found here.

Special thanks to the Siemens ProductCERT for providing support and context to this investigation.

Connected Cars: The Open Road for Hackers

10 June 2016 at 14:00

As vehicles become both increasingly complex and better connected to the Internet, their newfound versatility may be manipulated for malicious purposes. Three of the most concerning potential threats looking ahead to the next few years are those posed by manipulating vehicle operation, ransomware and using vehicular systems as command and control (C2) infrastructure for illicit cyber activity.

Car Hacking?

Vehicles have come a long way in terms of the high-tech features and connectivity that come standard in most new models. Modern cars are controlled almost entirely by software, and many drivers don’t realize the most complex digital device they own may be in their driveway. Of the growing number of devices in the “Internet of Things” (IoT), vehicles are among the most significant additions to the global Internet. An ever-growing list of features—including web browsing, Wi-Fi access points, and remote-start mobile phone apps—enhance user enjoyment, but also greatly expand vehicles’ attack surface, rendering them potentially vulnerable to advanced attacks. During the past year especially, numerous proof-of-concept demonstrations have revealed connected-car vulnerabilities that malicious actors can exploit, ranging from unauthorized entry to commandeering the vehicle’s operation. Unfortunately, as consumer demand drives ever more features, the opportunities for compromise will increase as well.

Ransomware

The scourge of ransomware has so far affected thousands of systems belonging to ordinary individuals, hospitals, and police stations. A vehicle’s increased connectivity, ever-expanding attack surface, and high upfront cost make them attractive ransomware targets. In contrast to ransomware that infects ordinary computer systems, vehicles are more likely susceptible to ransomware attacks when their disablement causes knock-on effects.

For example, where a single driver might be able to reinstall his car’s software with the help of a mechanic to remedy a ransomware infection, a group of vehicles disabled on a busy highway could cause far more serious disruption. Victims or municipal authorities may have little choice but to pay the ransom to reopen a busy commuting route. Alternatively, a logistics company might suddenly find a large portion of its truck fleet rendered useless by ransomware. The potential for lost revenue due to downtime might pressure the company to pay the ransom rather than risk more significant financial losses.

Malicious C2 and Final Hop Points

One effective law enforcement tactic in countering cyber espionage and criminal campaigns is identifying, locating and seizing the systems threat actors use to route malicious traffic through the Internet. Since many modern vehicles can be better described as a computer attached to four wheels and an engine, their mobility and power present challenges to this means of countering threat activity. We have already witnessed malware designed to hijack IoT devices for malicious purposes; vehicular systems’ greater computing power, compared to connected home thermostats, can significantly enhance their value as a C2 node.

Locating vehicles used to route malicious traffic would present a major challenge to law enforcement investigation, largely due to their mobility. We have not yet observed threat actors using connected vehicle systems to route malicious traffic, but it is most likely that a vehicle would be used as a final hop point to the intended target network. The perpetrators may use the vehicle only once, choosing to hijack the connectivity of a different vehicle on their next operation, and so on. This ever-changing roster of potential last-hop nodes situated on highly mobile platforms may allow threat actors to elude law enforcement for extended periods of time.

Understanding the Risk Landscape

The impact of cyber threats is most often considered in financial terms—the cost of a breach, whether direct financial losses or indirect costs of investigation, remediation, and improved security. As computers increasingly control vehicles, among other critical devices and systems, the potential for malfunction or manipulation that causes human harm rises dramatically. Automobile manufacturers may face greater liability, not only for the car’s physical components, but its software as well. How long before vehicles need a “cyber security rating,” similar to that awarded for crash testing and fuel economy?

These new risks point to the need for automotive manufacturers and suppliers to not only ensure the traditional operational safety of their vehicles, but to also secure both the vehicle's operations and occupant privacy. This requires an ongoing understanding about the nature of threats and vulnerabilities in a rapidly evolving landscape, and building in strong proactive security measures to protect against these risks. FireEye explores these risks to automotive safety in our latest FireEye iSIGHT Intelligence and Mandiant Consulting report: Connected Cars: The Open Road for Hackers. The report is available for download here.

FireEye Capabilities

FireEye combines our industry leading threat intelligence, incident response and red team capabilities with our ICS domain expertise to help the automotive industry improve their prevention, detection and response capabilities. FireEye’s Red Team Operations and Penetration Tests can provide firms in the automotive industry experience responding to real-world attacks without the risk of negative headlines. A one-time risk assessment is not enough, because threat attackers are consistently evolving.

For more information, contact FireEye.

FireEye iSIGHT Intelligence’s Horizons Team conducts strategic forecasting to anticipate risks posed by emerging technologies and geopolitical developments, helping clients and the public better assess their exposure to a dynamic cyber threat landscape.

Cerber: Analyzing a Ransomware Attack Methodology To Enable Protection

18 July 2016 at 12:00

Ransomware is a common method of cyber extortion for financial gain that typically involves users being unable to interact with their files, applications or systems until a ransom is paid. Accessibility of cryptocurrency such as Bitcoin has directly contributed to this ransomware model. Based on data from FireEye Dynamic Threat Intelligence (DTI), ransomware activities have been rising fairly steadily since mid-2015.

On June 10, 2016, FireEye’s HX detected a Cerber ransomware campaign involving the distribution of emails with a malicious Microsoft Word document attached. If a recipient were to open the document a malicious macro would contact an attacker-controlled website to download and install the Cerber family of ransomware.

Exploit Guard, a major new feature of FireEye Endpoint Security (HX), detected the threat and alerted HX customers on infections in the field so that organizations could inhibit the deployment of Cerber ransomware. After investigating further, the FireEye research team worked with security agency CERT-Netherlands, as well as web hosting providers who unknowingly hosted the Cerber installer, and were able to shut down that instance of the Cerber command and control (C2) within hours of detecting the activity. With the attacker-controlled servers offline, macros and other malicious payloads configured to download are incapable of infecting users with ransomware.

FireEye hasn’t seen any additional infections from this attacker since shutting down the C2 server, although the attacker could configure one or more additional C2 servers and resume the campaign at any time. This particular campaign was observed on six unique endpoints from three different FireEye endpoint security customers. HX has proven effective at detecting and inhibiting the success of Cerber malware.

Attack Process

The Cerber ransomware attack cycle we observed can be broadly broken down into eight steps:

  1. Target receives and opens a Word document.
  2. Macro in document is invoked to run PowerShell in hidden mode.
  3. Control is passed to PowerShell, which connects to a malicious site to download the ransomware.
  4. On successful connection, the ransomware is written to the disk of the victim.
  5. PowerShell executes the ransomware.
  6. The malware configures multiple concurrent persistence mechanisms by creating command processor, screensaver, startup.run and runonce registry entries.
  7. The executable uses native Windows utilities such as WMIC and/or VSSAdmin to delete backups and shadow copies.
  8. Files are encrypted and messages are presented to the user requesting payment.

Rather than waiting for the payload to be downloaded or started around stage four or five of the aforementioned attack cycle, Exploit Guard provides coverage for most steps of the attack cycle – beginning in this case at the second step.

The most common way to deliver ransomware is via Word documents with embedded macros or a Microsoft Office exploit. FireEye Exploit Guard detects both of these attacks at the initial stage of the attack cycle.

PowerShell Abuse

When the victim opens the attached Word document, the malicious macro writes a small piece of VBScript into memory and executes it. This VBScript executes PowerShell to connect to an attacker-controlled server and download the ransomware (profilest.exe), as seen in Figure 1.

Figure 1. Launch sequence of Cerber – the macro is responsible for invoking PowerShell and PowerShell downloads and runs the malware

It has been increasingly common for threat actors to use malicious macros to infect users because the majority of organizations permit macros to run from Internet-sourced office documents.

In this case we observed the macrocode calling PowerShell to bypass execution policies – and run in hidden as well as encrypted mode – with the intention that PowerShell would download the ransomware and execute it without the knowledge of the victim.

Further investigation of the link and executable showed that every few seconds the malware hash changed with a more current compilation timestamp and different appended data bytes – a technique often used to evade hash-based detection.

Cerber in Action

Initial payload behavior

Upon execution, the Cerber malware will check to see where it is being launched from. Unless it is being launched from a specific location (%APPDATA%\&#60GUID&#62), it creates a copy of itself in the victim's %APPDATA% folder under a filename chosen randomly and obtained from the %WINDIR%\system32 folder.

If the malware is launched from the specific aforementioned folder and after eliminating any blacklisted filenames from an internal list, then the malware creates a renamed copy of itself to “%APPDATA%\&#60GUID&#62” using a pseudo-randomly selected name from the “system32” directory. The malware executes the malware from the new location and then cleans up after itself.

Shadow deletion

As with many other ransomware families, Cerber will bypass UAC checks, delete any volume shadow copies and disable safe boot options. Cerber accomplished this by launching the following processes using respective arguments:

Vssadmin.exe "delete shadows /all /quiet"

WMIC.exe "shadowcopy delete"

Bcdedit.exe "/set {default} recoveryenabled no"

Bcdedit.exe "/set {default} bootstatuspolicy ignoreallfailures

Coercion

People may wonder why victims pay the ransom to the threat actors. In some cases it is as simple as needing to get files back, but in other instances a victim may feel coerced or even intimidated. We noticed these tactics being used in this campaign, where the victim is shown the message in Figure 2 upon being infected with Cerber.

Figure 2. A message to the victim after encryption

The ransomware authors attempt to incentivize the victim into paying quickly by providing a 50 percent discount if the ransom is paid within a certain timeframe, as seen in Figure 3.

 

 

Figure 3. Ransom offered to victim, which is discounted for five days

Multilingual Support

As seen in Figure 4, the Cerber ransomware presented its message and instructions in 12 different languages, indicating this attack was on a global scale.

Figure 4.   Interface provided to the victim to pay ransom supports 12 languages

Encryption

Cerber targets 294 different file extensions for encryption, including .doc (typically Microsoft Word documents), .ppt (generally Microsoft PowerPoint slideshows), .jpg and other images. It also targets financial file formats such as. ibank (used with certain personal finance management software) and .wallet (used for Bitcoin).

Selective Targeting

Selective targeting was used in this campaign. The attackers were observed checking the country code of a host machine’s public IP address against a list of blacklisted countries in the JSON configuration, utilizing online services such as ipinfo.io to verify the information. Blacklisted (protected) countries include: Armenia, Azerbaijan, Belarus, Georgia, Kyrgyzstan, Kazakhstan, Moldova, Russia, Turkmenistan, Tajikistan, Ukraine, and Uzbekistan.

The attack also checked a system's keyboard layout to further ensure it avoided infecting machines in the attackers geography: 1049—Russian, ¨ 1058—Ukrainian, 1059—Belarusian, 1064—Tajik, 1067—Armenian, 1068—Azeri, (Latin), 1079—Georgian, 1087—Kazakh, 1088—Kyrgyz (Cyrillic), 1090—Turkmen, 1091—Uzbek (Latin), 2072—Romanian (Moldova), 2073—Russian (Moldova), 2092—Azeri (Cyrillic), 2115—Uzbek (Cyrillic).

Selective targeting has historically been used to keep malware from infecting endpoints within the author’s geographical region, thus protecting them from the wrath of local authorities. The actor also controls their exposure using this technique. In this case, there is reason to suspect the attackers are based in Russia or the surrounding region.

Anti VM Checks

The malware searches for a series of hooked modules, specific filenames and paths, and known sandbox volume serial numbers, including: sbiedll.dll, dir_watch.dll, api_log.dll, dbghelp.dll, Frz_State, C:\popupkiller.exe, C:\stimulator.exe, C:\TOOLS\execute.exe, \sand-box\, \cwsandbox\, \sandbox\, 0CD1A40, 6CBBC508, 774E1682, 837F873E, 8B6F64BC.

Aside from the aforementioned checks and blacklisting, there is also a wait option built in where the payload will delay execution on an infected machine before it launches an encryption routine. This technique was likely implemented to further avoid detection within sandbox environments.

Persistence

Once executed, Cerber deploys the following persistence techniques to make sure a system remains infected:

  • A registry key is added to launch the malware instead of the screensaver when the system becomes idle.
  • The “CommandProcessor” Autorun keyvalue is changed to point to the Cerber payload so that the malware will be launched each time the Windows terminal, “cmd.exe”, is launched.
  • A shortcut (.lnk) file is added to the startup folder. This file references the ransomware and Windows will execute the file immediately after the infected user logs in.
  • Common persistence methods such as run and runonce key are also used.
A Solid Defense

Mitigating ransomware malware has become a high priority for affected organizations because passive security technologies such as signature-based containment have proven ineffective.

Malware authors have demonstrated an ability to outpace most endpoint controls by compiling multiple variations of their malware with minor binary differences. By using alternative packers and compilers, authors are increasing the level of effort for researchers and reverse-engineers. Unfortunately, those efforts don’t scale.

Disabling support for macros in documents from the Internet and increasing user awareness are two ways to reduce the likelihood of infection. If you can, consider blocking connections to websites you haven’t explicitly whitelisted. However, these controls may not be sufficient to prevent all infections or they may not be possible based on your organization.

FireEye Endpoint Security with Exploit Guard helps to detect exploits and techniques used by ransomware attacks (and other threat activity) during execution and provides analysts with greater visibility. This helps your security team conduct more detailed investigations of broader categories of threats. This information enables your organization to quickly stop threats and adapt defenses as needed.

Conclusion

Ransomware has become an increasingly common and effective attack affecting enterprises, impacting productivity and preventing users from accessing files and data.

Mitigating the threat of ransomware requires strong endpoint controls, and may include technologies that allow security personnel to quickly analyze multiple systems and correlate events to identify and respond to threats.

HX with Exploit Guard uses behavioral intelligence to accelerate this process, quickly analyzing endpoints within your enterprise and alerting your team so they can conduct an investigation and scope the compromise in real-time.

Traditional defenses don’t have the granular view required to do this, nor can they connect the dots of discreet individual processes that may be steps in an attack. This takes behavioral intelligence that is able to quickly analyze a wide array of processes and alert on them so analysts and security teams can conduct a complete investigation into what has, or is, transpiring. This can only be done if those professionals have the right tools and the visibility into all endpoint activity to effectively find every aspect of a threat and deal with it, all in real-time. Also, at FireEye, we go one step ahead and contact relevant authorities to bring down these types of campaigns.

Click here for more information about Exploit Guard technology.

❌