Category Archives: indicators of compromise

Investigating with Indicators of Compromise (IOCs) – Part II

Written by Will Gibb & Devon Kerr

In our blog post "Investigating with Indicators of Compromise (IOCs) - Part I," we presented a scenario involving the "Acme Widgets Co.," a company investigating an intrusion, and its incident responder, John. John's next objective is to examine the system "ACMWH-KIOSK" for evidence of attacker activity. Using the IOCs containing the tactics, techniques and procedures (TTPs) he developed during the analysis of "ACM-BOBBO," John identifies the following IOC hits:

Table 1: IOC hit summary

After reviewing IOC hits in Redline™, John performs Live Response and put together the following timeline of suspicious activity on "ACMWH-KIOSK".

Table 2: Summary of significant artifacts

John examines the timeline in order to surmise the following chain of activities:

  • On October 15, 2013, at approximately 16:17:56 UTC, the attacker performed a type 3 network logon, described here, to "ACMWH-KIOSK" from "ACM-BOBBO" using the ACME domain service account, "backupDaily."
  • A few seconds later, the attacker copied two executables, "acmCleanup.exe" and "msspcheck.exe," from "ACM-BOBBO" to "C:$RECYCLE.BIN."

By generating MD5 hashes of both files, John determines that "acmCleanup.exe" is identical to the similarly named file on "ACM-BOBBO", which means it won't require malware analysis. Since the MD5 hash of "msspcheck.exe" was not previously identified, John sends binary to a malware analyst, whose analysis reveals that "msspcheck.exe" is a variant of the "acmCleanup.exe" malware.

  • About a minute later, at 16:19:02 UTC, the attacker executed the Sysinternals PsExec remote command execution utility, which ran for approximately three minutes.
  • During this time period, event logs recorded the start and stop of the "WCE SERVICE" service, which corresponds to the execution of the Windows Credentials Editor (WCE).

John can assume PsExec was used to execute WCE, which is reasonable given the timeline of events and artifacts present on the system.

About seven minutes, later the registry recorded the modification of a Run key associated with persistence for "msspcheck.exe." Finally, at 16:48:11 UTC, the attacker logged off from "ACMWH-KIOSK".

John found no additional evidence of compromise. Since the IOCs are living documents, John's next step is to update his IOCs with relevant findings from his investigation of the kiosk system. John updates the "acmCleanup.exe (BACKDOOR)" IOC with information from the "msspcheck.exe" variant of the attacker's backdoor including:

  • File metadata like filename and MD5.
  • A uniquely named process handle discovered by John's malware analyst.
  • A prefetch entry for the "msspcheck.exe" binary.
  • Registry artifacts associated with persistence of "msspcheck.exe."

From there, John double-checks the uniqueness of the additional filename with some search engine queries. He can confirm that "msspcheck.exe" is a unique filename and update his "acmCleanup.exe (BACKDOOR)" IOC. By updating his existing IOC, John ensures that he will be able to identify evidence attributed to this specific variant of the backdoor.

Changes to the original IOC have been indicated in green.

The updated IOC can be seen below:

Figure 1: Augmented IOC for acmCleanup.exe (BACKDOOR)

John needs additional information before he can start to act. He knows two things about the attacker that might be able to help him out:

  • The attacker is using a domain service account to perform network logons.
  • The attacker has been using WCE to obtain credentials and the "WCE SERVICE" service appears in event logs.

John turns to his security event and incident management (SEIM) system, which aggregates logs from his domain controllers, enterprise antivirus and intrusion detection systems. A search of type 3 network logons using the "backupDaily" domain account turns up 23 different systems accessed using that account. John runs another query for the "WCE SERVICE" and sees that logs from 3 domain controllers contain that service event. John needs to look for IOCs across all Acme machines in a short period of time.

OpenIOC Series: Investigating with Indicators of Compromise (IOCs) – Part I

Written by Devon Kerr & Will Gibb

The Back to Basics: OpenIOC blog series previously discussed how Indicators of Compromise (IOCs) can be used to codify information about malware or utilities and describe an attacker's methodology. Also touched on were the parts of an IOC, such as the metadata, references, and definition sections. This blog post will focus on writing IOCs by providing a common investigation scenario, following along with an incident response team as they investigate a compromise and assemble IOCs.

Our scenario involves a fictional organization, "Acme Widgets Co.", which designs, manufactures and distributes widgets. Last week, this organization held a mandatory security-awareness training that provided attendees with an overview of common security topics including password strength, safe browsing habits, email phishing and the risks of social media. During the section on phishing, one employee expressed concern that he may have been phished recently. Bob Bobson, an administrator, indicated that some time back he'd received a strange email about a competitor's widget and was surprised that the PDF attachment wouldn't open. A member of the security operations staff, John Johnson, was present during the seminar and quickly initiated an investigation of Bob's system using the Mandiant Redline™ host investigation tool. John used Redline to create a portable collectors configured to obtain live response data from Bob's system which included file system metadata, the contents of the registry, event logs, web browser history, as well as service information.

John ran the collectors on Bob's system and brought the data back to his analysis workstation for review. Through discussions with Bob, John learned that the suspicious e-mail likely arrived on October 13, 2013.

After initial review of the evidence, John assembled the following timeline of suspicious activity on the system.

Table 1: Summary of significant artifacts

Based on this analysis, John pieced together a preliminary narrative: The attacker sent a spear-phishing email to Bob which contained a malicious PDF attachment, "Ultrawidget.pdf", which Bob saved to the desktop on October 10, 2013, at 20:19:07 UTC. Approximately five minutes later, at 20:24:44 UTC, the file "C:WINDOWSSysWOW64acmCleanup.exe" was created as well as a Run key used for persistence. These events were likely the result of Bob opening the PDF. John sent the PDF to a malware analyst to determine the nature of the exploit used to infect Bob's PC.

The first IOC John writes describes the malware identified on Bob's PC, "acmCleanup.exe", as well as the malicious PDF. IOCs sometimes start out as rudimentary - looking for the known file hashes, filenames and persistence mechanisms of the malware identified. Here is what an initial IOC looks like:

Figure 1: Initial IOC for acmCleanup.exe (BACKDOOR)

As analysis continues, these IOCs are updated and improved - incorporating indicator terms from malware and intelligence analysis as well as being refined based on the environment. In this sense, the IOC is a living document. For example, additional analysis may reveal more registry key information, additional files which may be written to disk, or information for identifying the malware in memory. Here is the same IOC, after augmenting it with the results of malware analysis:

Figure 2: Augmented IOC for acmCleanup.exe (BACKDOOR)

The augmented IOC will continue to identify the exact malware discovered on Bob's PC. This improved IOC will also identify malware which has things in common with that backdoor:

  • Malware which uses the same Mutex, a process attribute that will prevent the machine from being infected multiple times with the same backdoor
  • Malware which performs DNS queries for the malicious domain "23vsx.evil.com"
  • Malware which has a specific set of import functions; in this case which correspond to reverse shell and keylogger functionality

Beginning on October 11, the attacker accessed the system and executed the Windows command "ipconfig" at 20:24:00 UTC, resulting in the creation of a prefetch file. Approximately five minutes later, the attacker began uploading files to "C:$RECYCLE.BIN". Based on review of their MD5 hashes, three files ("wce.exe", "getlsasrvaddr.exe", "update.exe") were identified as known credential dumping utilities while others ("filewalk32.exe", "rar.exe") were tools for performing file system searches and creating WinRAR archives. These items should be recorded in an IOC, as a representation of an attacker's tools, techniques and procedures (TTPs). It is important to know that an attacker is likely to have interacted with many more systems than were infected with malware; for this reason it is crucial to look for evidence that an attacker has accessed systems. Some of the most common activities attackers perform on these systems include password-dumping, reconnaissance and data theft.

Seeing that the attacker had staged file archives and utilities in the "$Recycle.Bin" folder, John also created an IOC to find artifacts present there. This IOC was designed to identify files in the root of the "$Recycle.Bin" directory; or to identify if a user (notably, the attacker) tried to access the "$Recycle.Bin" folder by manually typing it in the address bar of Explorer by checking TypedPaths in the Registry. This is an example of encapsulating an attacker's TTPs in an OpenIOC form.

Figure 3: IOC for Unusual Files in "C:RECYCLER" and "C:$RECYCLE.BIN" (Methodology)

On October 15, 2013, at 12:15:37 UTC, the Sysinternals PsExec utility was created in "C:$RECYCLE.BIN". Approximately four hours later, at 16:11:03 UTC, the attacker used the Internet Explorer browser to access text files located in "C:$RECYCLE.BIN". Between 16:11:03 UTC and 16:11:06 UTC, the attacker accessed two text files which were no longer present on the system. At 16:17:55 UTC, the attacker mounted the remote hidden share "\10.20.30.101C$". At 16:20:29 UTC, the attacker executed the Windows "tree" command, resulting in the creation of a prefetch file, a command which produces a filesystem listing. At 17:37:37 UTC, the attacker created one WinRAR archive, "C:$Recycle.Bina.rar" which contained two text files, "c.txt" and "a.txt". These text files contained output from the Windows "tree" and "ipconfig" commands. No further evidence was present on the system. John noted that the earliest event log entries present on the system start approximately two minutes after the creation of "a.rar". It is likely that the attacker cleared the event logs before disconnecting from the system.

John identified the lateral movement to the 10.20.30.101 host, from "ACM-BOBBO" through registry keys that recorded the mount of the hidden C$ share. By recording this type of artifact in an IOC, John will be able to quickly see if the attacker has pivoted to another part of the Acme Widgets Co. network when investigating 10.20.30.101. He included artifacts looking for other common hidden shares such as IPC$ and ADMIN$. The effectiveness of an IOC may be influenced by the environment the IOC was created for. This IOC, for example, may generate a significant number of false-positives in an environment where these hidden shares are legitimately used. At Acme Widgets Co., however, the use of hidden shares is considered highly suspicious.

Figure 4 IOC for Lateral Movement (Methodology)Figure 4 IOC for Lateral Movement (Methodology)

At the end of the day, John authored three new IOCs based on his current investigation. He knows that if he records the artifacts he identified from his investigation into the "ACM-BOBBO" system, he can apply that knowledge to the investigation of the host at 10.20.30.101. Once he collects information on 10.20.30.101 with his Redline portable collector, he'll be able to match IOCs against the Live Response data, which will let him identify known artifacts quickly prior to beginning Live Response analysis. Although John is using these IOCs to search systems individually, these same IOCs could be used to search for evidence of attacker activity across the enterprise. Armed with this set of IOCs, John sets out to hunt for evil on the host at "10.20.30.101".

Stay tuned for our next blog post, seeing how this investigation develops.

OpenIOC: Back to the Basics

Written by Will Gibb & Devon Kerr

One challenge investigators face during incident response is finding a way to organize information about an attackers' activity, utilities, malware and other indicators of compromise, called IOCs. The OpenIOC format addresses this challenge head-on. OpenIOC provides a standard format and terms for describing the artifacts encountered during the course of an investigation. In this post we're going to provide a high-level overview of IOCs, including IOC use cases, the structure of an IOC and IOC logic.

Before we continue, it's important to mention that IOCs are not signatures, and they aren't meant to function as a signature would. It is often understated, but an IOC is meant to be used in combination with human intelligence. IOCs are designed to aid in your investigation, or the investigations of others with whom you share threat intelligence.

IOC Use Cases:

There are several use cases for codifying your IOCs, and these typically revolve around your objectives as an investigator. The number of potential use cases is quite large, and we've listed some of the most common use cases below:

  • Find malware/utility: This is the most common use case. Essentially, this is an IOC written to find some type of known malware or utility, either by looking for attributes of the binary, itself, or for some artifact created upon execution, such as a prefetch file or registry key.
  • Methodology: Unlike an IOC written to identify malware or utilities, these IOCs find things you don't necessarily know about, in order to generate investigative leads. For example, if you wanted to identify any service DLL that wasn't signed and which was loaded from any directory that did not include the path "windowssystem32", you could write an IOC to describe that condition. Another good example of a methodology IOC is an IOC that looks for the Registry text value of all "Run" keys for a string ending ".jpg". This represents an abnormal condition which upon investigation may lead to evidence of a compromise.
  • Bulk: You may already be using this kind of IOC. Many organizations subscribe to threat intelligence feeds that deliver a list of MD5s or IP addresses; a bulk IOC can represent a collection of those indicators. These kinds of IOCs are very black and white and are typically only good for an exact match.
  • Investigative: As you investigate systems in an environment and identify evidence of malicious activity such as metadata related to the installation of backdoors, execution of tools, or files being staged for theft, you can track that information in an IOC. These IOCs are similar to bulk IOCs; however, an investigative IOC only contains indicators from a single investigation. Using this type of IOC can help you to prioritize which systems you want to analyze.

IOC components:

An IOC is made up of three main parts: IOC metadata, references and the definition. Let's examine each one of these more closely, noting that we're using the Mandiant IOC Editor (IOCe) downloadable from the Mandiant website:

Metadata: IOC metadata describes information like the author of the IOC (jsmith@domain.tld), the name of the IOC (Evil.exe (BACKDOOR) and a brief description such as "This variant of the open source Poison Ivy backdoor has been configured to beacon to 10.127.10.128 and registers itself as "Microsoft 1atent time services".

References: Within the IOC, references can find information like the name of an investigation or case number, comments and information on the maturity of the IOC such as Alpha, Beta, Release, etc. This data can help you to understand where the IOC fits in your library of threat intelligence. One common use for references is to associate an IOC with a particular threat group. It is not uncommon for certain references to be removed from IOCs when sharing IOCs with third parties.

Definition: This is the content of the IOC, containing the artifacts that an investigator decided to codify in the IOC. For example, these may include the MD5 of a file, a registry path or something found in process memory. Inside the definition, indicators are listed out or combined into expressions that consist of two terms and some form of Boolean logic.

One thing about the OpenIOC format that makes it particularly useful is the ability to combine similar terms using Boolean AND & OR logic. The previous example shows how this type of logic can be used. This type of IOC describes three possible scenarios:

  1. The name of a service is "MS 1atent time services" - OR -
  2. The ServiceDLL name for any service contains "evil.exe" - OR -
  3. The filename is "bad.exe" AND the filesize attribute of that file is within the range 4096 to 10240 bytes.

When you use Boolean logic, remember the following:

  • An AND requires that both sides of the expression are true
  • An OR requires that one side of the expression is true

Understanding that the Boolean statements, such as 'The name of a service is "MS 1atent time services", OR "filename is "bad.exe" AND the filesize attribute of that file is within the range 4096 to 10240 bytes"', are evaluated separately is an important aspect understanding how the logic within an IOC works. These statements are not if-else statements, nor do they both have to exist in order for the IOC to have a match. When investigating a host, if the "MS 1atent time services" service is present, this IOC would have a match; regardless of whether or not the malicious file the IOC described was present on the host as well.

In our next post we're going to have a crash course in writing IOC definitions using the Mandiant IOC editor, IOCe. 

The History of OpenIOC

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.

Back to Basics Series: OpenIOC

Over the next few months, a few of my colleagues and I will be touching on various topics related to Mandiant and computer security. As part of this series, we are going to be talking about OpenIOC - how we got where we are today, how to make and use IOCs, and the future of OpenIOC. This topic can't be rolled into a single blog post, so we have developed a brief syllabus to outline the topics that we will be covering in the near future.

The History of OpenIOC

In this post we're going to focus on the past state of threat intelligence sharing and how it has evolved up to this point in the industry. We'll specifically focus on how we implemented OpenIOC at Mandiant as a way to codify threat intelligence.

Back to the Basics

What are indicators of compromise? What is an OpenIOC? What goes into an IOC? How do you read these things? What can you include in them? We will address all of these questions and more.

Investigating with Indicators of Compromise (IOCs)

In this post, we will model an actual incident response and walk through the creation of IOCs to detect malware (and attacker activity) related to the incident presented. Multiple blog posts and IOCs will come out of this exercise.

IOCs at Scale

So far, we will have touched on using Redline™ to deploy OpenIOC when investigating a single host. To deploy IOCs across an enterprise, we use Mandiant for Intelligent Response® (MIR®). Briefly, we will show how we can use MIR to deploy the IOCs built in the previous exercise across an enterprise scenario, expediting the incident response process.

The Future of OpenIOC

What is next? OpenIOC was open sourced in the fall of 2011, and it is time for an upgrade! With the soft-launch of the draft OpenIOC 1.1 spec at Black Hat USA, we've since released a draft of the OpenIOC 1.1 schema. We'll discuss what we changed and why, as well as some of the exciting possibilities that this update makes possible.

Integrating OpenIOC 1.1 into tools

With the release of the OpenIOC 1.1 draft, we also released a tool, ioc writer, which can be used to create or modify OpenIOC 1.1 IOCs. We will detail the capabilities of this library and how you could use it to add OpenIOC support to your own applications. We will also discuss the potential for using parameters to further define application behavior that is not built into the OpenIOC schema itself.

We have several goals for this series:

  • Introduce OpenIOC for people that are not already familiar with OpenIOC
  • Show how you can use OpenIOC to record artifacts identified during an investigation
  • Show how OpenIOC can be deployed to investigate a single host - or a whole enterprise
  • Discuss the future of OpenIOC & the upcoming specification, OpenIOC 1.1
  • Show how OpenIOC 1.1 support can be added to tools, and future capabilities of the standard

Stay tuned for our next post in the series!

Q&A Webinar Follow-Up – State of the Hack: Back to the Remediation

As a follow-up to our recently held State of the Hack: Back to the Remediation webinar, questions answered by presenter Jim Aldridge are listed below. 

  1. How do you develop a business case for resources for security incident management, remediation, and log analysis?
    This is an area with which many organizations that have not experienced an incident struggle with. I would recommend conducting a realistic incident simulation to exercise the organization's incident response plan. This should go beyond a table-top exercise and actually test responders' capabilities to use logs to identify and track attacker activity. This approach should provide the organization a good understanding of weaknesses in these areas. For example, I assisted a bank with planning and executing this type of exercise. They were concerned about targeted threats and had never experienced a security breach. After a series of meetings to better understand their environment, we designed a scenario based on an incident we had worked on in the past. In their scenario, picture a blank screen with a SQL Server and a question mark on it. We would give them a clue, and then we would on and say, "Okay, so what would you do if you got this information?" And then we provided a little bit more of the diagram. It was in the style of a choose your own adventure.
  2. During incident response what tools do you use for networking indicators; are any of them open source?
    Typically, we like to deploy our network sensors, which we don't offer as a standalone product at this time. That intelligence is only available as part of our Managed Defense™ service, in large part due to the back end processing that's involved. I would categorize those as proprietary. They do a lot for us, but we also leverage whatever the client has in place.
    t
    Sources of helpful information include:
    • Firewall logs (established connection information)
    • DNS logs (which host resolved a given domain name at a given time)
    • NetFlow (connection information)

    One of the more mature security organizations that I've worked an incident with has a particularly effective network monitoring set up. They collect NetFlow information from across the environment. This enables them to rapidly identify lateral movement.

  3.  

  4. Is the Mandiant incident response tool available to the public?
    Mandiant for Intelligent Response® is a commercial product. As I mentioned, Redline™ is a free tool that I encourage you to take a look at. It is very similar to MIR in terms of the capabilities on individual hosts, but it's designed to be executed against one host versus an enterprise.
  5. What are your thoughts on best countermeasures against pass the hash tactics?
    It is most important to prevent the attacker from getting access to that hash in the first place. That's one reason why I like application whitelisting so much, particularly on domain controllers, because this can prevent even a domain admin from running the hash dumper. Unfortunately, once the attacker has that hash, it's not good. Another strategy is to reduce the number of places where an attacker could readily obtain privileged users' hashes. First, privileged users should operate with non-privileged accounts for their day-to-day activities. This helps reduce the impact of a spear phishing email or strategic web compromise that impacts that user. To conduct administration activities, connect to a jump server using two-factor authentication. Maybe incorporate a password vault so that the vault connects the user to the jump server, after a two-factor authentication process, and the password is never divulged to the user (or present on the admin's PC). Then lock down the jump server with application whitelisting, implement enhanced logging and monitoring. Configure firewalls and systems to only accept inbound connections on administrative services from the jump servers and not from the network at large. Each of these countermeasures helps to mitigate a part of the attack lifecycle; implementing them together can help greatly strengthen the security posture.
  6. What kind of back door were the attackers using on the first infected systems?
    That varies widely. On some cases I worked recently we've seen Gh0st RAT, we've seen Poison Ivy, we've seen a custom back door that doesn't really have a name because it's something that this one particular group uses. The particular tool there wasn't the point, just more the fact that they were infected. We're seeing a lot more use of publicly available back doors. They can be pretty effective, and can also be hard to detect.
  7. How would one ever determine the true scope of a foothold in a global environment if it's using multiple command and control points?
    To answer that question, you have to start by comprehensively surveying the environment for indicators of compromise (IOC). You start by taking the pieces of information you know, e.g. the backdoors the attacker is known to use, known compromised accounts, and command-and-control IP addresses. Perhaps this yields you two systems that are initially suspected of being compromised. You then you ask the question, "Well, where did they go from those two systems? How did they get on those two systems?" You conduct forensic analysis to understand all the facts related to those systems: how did they gain access, what did they do, where did they go, and what tools did they use. Then you follow those threads, identifying more systems. This can be challenging in a large environment, which is one of the really helpful use cases for Mandiant for Intelligent Response. The largest organization where I have conducted this type of incident response had around 135,000 hosts. With a team of five or six people and about eight weeks, we could get a handle on that environment.
  8. How do we balance the need to contain and respond and the need to preserve forensic evidence?
    It depends on whether you think that it's likely to go to court or in litigation. You want to make sure that your procedures are as least intrusive as possible, but typically in most APT-type cases, we don't really worry as much about formal chain of custody for systems or preserving every system in its original state. The way I would look at it is, I would develop a set of procedures for your organization to talk about how you determine when you need to preserve and what that means and what your standard operating procedures are, so that you can explain and minimize - both explain what you're doing as well as minimize - the impact on systems.

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

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

M-Unition Podcast: Mandiant’s Redline Tool Makes Incident Response Easy for Experts and Beginners

On today's podcast, Kristen Cooper talks with Lucas Zaichkowsky on the latest version of Redline, a free tool from Mandiant.

The podcast will explain in detail what Redline is capable of, highlighting two features that set it apart from other tools. First, the tool is intuitive enough to be used by novice incident responders, without compromising capabilities that advanced incident responders utilize in the tool. Secondly, the tool is capable of applying Indicators of Compromise (IOC) to data that it collects. This allows Redline to detect evidence of attacks, even though there may be no evidence of active malware on additional computers.

Listen along as Lucas details the product demonstration he performed at Black Hat 2012 that really showcases Redline's unique value.

To listen to the full podcast and learn more about Redline click here.

Investigating Indicators of Compromise In Your Environment With Latest Version of Redline

Recently, Mandiant® released a new version of Redline. If you are not familiar with Redline, it is a great tool for investigating a specific Windows host in depth. We will have a more thorough look into Redline in the next month or so. What I wanted to touch on today is one of Redline's brand new features: you can now use Indicators of Compromise (IOCs) to drive your Redline investigations.

If you are not familiar with IOCs, I urge to you take a moment and head over to http://OpenIOC.org and have a look around. IOCs are the best way for finding indications of compromise and/or intrusion throughout your enterprise. IOCs are one of the main technologies that power Mandiant Intelligent Response, Mandiant's flagship IR appliance, and have previously been accessible in free products with IOC Editor & IOC Finder. Some blog entries that might help bring you up to speed are Ryan Kazanciyan's recent post on using Redline for investigation and to create an IOC, and Carrie Jung's post on investigations into the Duqu worm, including looking at Duqu with Redline and creating an IOC to help you find Duqu.

Previously, if you wanted to look for an IOC, you would create an IOC using IOC Editor, and then collect data from a host using IOC Finder. As an additional step, you would run a match against that data and generate a report using IOC Finder in a different configuration. With the latest release of Redline you will still start making your IOC in the Editor, but you can collect the data from a host and match against it in a much simpler manner.

When you first fire up the latest version of Redline with IOC support (Version 1.5) you will see options that look very similar to previous versions:

For the sake of simplicity, we will analyze the machine that Redline is running on. In most instances, if you are using Redline to look at any real cases, you will NOT want to analyze the machine that Redline is running on. You will want to dedicate a workstation to running Redline analysis, and then you will want to collect data from suspect machines through a method such as creating a portable agent from Redline (which is discussed in the Redline User Guide). By doing this you do not have to install Redline on every machine you want to investigate, and thus are not potentially contaminating machines that you need to do real investigations on.

Clicking on the link that says "By Analyzing this Computer" will open a new window in Redline entitled "Start your Analysis Session." Another nice feature of Redline is that you can do more than one thing at a time -- a useful feature once you have some investigation data saved. In this new window, you can choose to add IOCs to your investigation. You can still use Redline the old fashioned way by clicking "Next" and bypassing this screen, but what fun would that be? Instead we are going to select the check box that says "Indicators of Compromise Location:"

and then "Browse" to the folder that you are keeping your IOCs in. Assuming that you select a folder that has valid IOCs in it, you should quickly see a listing of the IOCs you populated Redline with.

Following the prompt "Choose an Indicator from the list on the left to see full details," if you click on one of the Indicator Names, you will see information about that Indicator. If you want to use only one Indicator, or a specific subset of the Indicators in your IOC directory, click the check box at the top next to Name, and then select the specific Indicator(s) that you want to use by checking just those checkboxes:

So, what if you are new to this? What if you do not have any IOCs on hand? Well, as a shortcut, you can go to http://openioc.org/ and grab a few sample ones that we have available. Ideally, you will eventually build your own IOCs from the investigation data that you discover, but these samples will help you get started for learning purposes. Find Windows is a great test IOC, as it requires no malware on your system - it is an IOC designed to find various components of Windows that are common across several different versions of the operating system. Grab one IOC, or grab them all, put them in a directory you can write to, and you will be ready to investigate.

Let us keep moving along towards conducting an investigation. In the lower right hand corner of Redline, we are going to click the "Next" button, which will take us to a page that says "Configure your Script." You will note that the "Custom" radio button is currently selected. Please do not touch any of the buttons or checks on this page until you read a little further down.

So, what is going on here? The way the Mandiant investigative workflow functions is around the idea of gathering data from a host and then analyzing it. With IOC Finder running in the default configuration, you would gather ALL the possible information from a host -- a process that could take hours depending on the type of computer and how much you were gathering. While desirable for real, in- depth investigations, it may be a bit frustrating if you are trying to learn how to use the tools or just try things out. We revealed that it is possible to script IOC Finder to limit the amount of data that is being collected, but you still had to know what types of audits you wanted to complete on the host, write the script to limit those audits, and then make sure that everything still ran correctly. That is a lot more than most folks want to worry about when they are trying to conduct a quick investigation.

With Redline, this process has gotten a lot easier. Redline looks at the IOCs that you have selected, and determines the audits that have to be run to gather the data that you need to match those IOCs. Thus, assuming you do not change anything on the "Configure your Script" screen, Redline builds the appropriate script to gather the information for the audits that you need. Redline still always gathers enough information to do a full memory audit - but now IOC audit information required to match IOCs is added to that, including items like disk and registry audits.

If you want to customize the audits being done, you can do so on this screen. If you deselect options that are needed for your IOCs, you will get a warning letting you know that what you deselected is in fact needed for your IOCs to match properly.

This warning is down at the bottom of the screen near the "Previous" & "OK" buttons. If you click on the link to "fix," Redline will restore the audit choices to the state they were in when you first arrived at this screen, displaying the "Custom Audit" based on your IOCs.

If you are using Redline for IOC-driven investigation, you can just move on to the next step and have all the information you need for your current IOCs included in the script that will run and collect information without having to do any additional work. Click the "OK" button to run the collection script with the options that Redline has selected for you.

You will see the script fire up, and you should (unless you have disabled UAC) be asked to allow the script to run with elevated privileges:

Once you give permission to the script, it will continue to run. If you do not give permissions, it will usually error out (since the script Redline generates cannot write its results or conduct most of the audits without being granted elevated privileges).

You can watch it run, but likely you will want to go do something else and come back a bit later, since for any decent sized collection of IOCs it is going to take a while, unless you are doing a very small IOC or very simple IOCs. For the sample IOCs on http://openioc.org/ it took around two hours on a Windows 7 VM with 2 Gigs of RAM allocated. Faster machines with more resources are going to usually run faster, with Disk I/O being the main bottleneck, along with Processor. RAM is less of an issue. If you want to have things run faster, you can also try using the Portable Agent version of Redline. We will cover that more next week in an upcoming post on Redline Pro Tips.

Once you have the items you need, you can look through the results of the audit data gathered as you would a normal Redline analysis -- but you will notice another task running - "Redline is Creating an IOC Report," matching the audit data against IOCs just like IOC Finder would have -- but with no need to run any additional tools!

Once the IOC report is done, you will see it in the "IOC Reports Tab" of the Redline results.

Click on the IOC Report that you just ran (by date/time) to see any matches that were turned up from those IOCs. In this case, there was a hit on the "Find Windows" IOC. Click on the "Find Windows" title to expand the findings.

The IOC matches are displayed in a format that will look very familiar, if you have ever used IOC Finder in reporting mode. You can click on the "i" icon by any matches indicated in the results for details that show much more in depth information on what matched and why.

You will see the IOC that matched listed in the Definition section of the details, and you will see the particular piece of the IOC that hit highlighted in yellow. Clicking the Details tab again will hide this window.

 

Using IOCs with Redline in investigative workflows:

If you are currently using Redline to do host-based investigations, and you have already amassed a large amount of data for hosts that you test against, or you want to gather all the data you can from hosts so you can have it for future reference instead of having to go back to the host again should you expand the scope of your investigation, and still want to use the new IOC feature, fear not! The new version of Redline allows this as well.

If you have standard audit sets that you capture, or if you capture all of the audit data on hosts as a matter of course, you can add IOCs in after the fact. However, be aware that if you do not have the audit data for a given element of an IOC, obviously the IOC will not be able to match (at least for that element).

Load the audit data as you normally would in Redline depending on the audit type, and then in the "IOC Reports Tab," look for a button at the bottom that says "Create a New IOC Report."

Clicking on this will open up a new "Start your Analysis Session" window, which you can then select the directory that houses your IOCs and generate a report on that set of IOCs.

Conclusion

We've looked at the new feature in Redline 1.5 that allows you to use it to create audits and match IOCs against that audit data. This is only scratching the surface of what you can do with either Redline or with IOCs. Next week, we'll have another blog post with some "Pro Tips" on using Redline 1.5 (including discussing Portable Agents), and there will be an upcoming webinar that focuses on Redline more in depth in May.

For more information on IOCs and OpenIOC, you can visit the OpenIOC.org website. Will Gibb and I will also be doing a webinar, Fresh Prints of Mal-ware: IOCing Red, on Thursday, April 19 on IOCs and Redline where we will discuss writing a real world IOC from an investigation. We hope you can tune in!

The Latest Version of Redline Finds Indicators of Compromise and More

We are on a roll with our freeware. The latest version of Redline is now available! For those who are not familiar with Redline - you may be asking, what is it? Simply put, Redline brings together analysis tools which help you perform a guided investigation of a potentially compromised system. And did we mention that it is free?

This latest and greatest version of Redline includes some awesome new features, courtesy of recommendations from our strong and growing user base and input from internal users here at Mandiant. For those who have been loyal Redline users, you will find that it is no longer just a memory forensics tool! It has grown into a multi-purpose product for creating Indicators of Compromise (IOC) and matching them across all types of host data, while maintaining all the traditional memory forensics capabilities that you're used to.

Get the data that matters, and do it faster

  • With Redline, you can now include and search for Indicators of Compromise and create a searchable report detailing any suspicious activity found matching those IOCs. Need more on what IOCs are? Click here for more information.
  • Specify a set of IOCsbefore collection and Redline will now help tailor the configuration to provide meaningful search resultsand ensure that all the data required by the chosen IOCs is collected, speeding up your time to completion.
  • Not sure if the IOCs you have chosen are the ones you want? Not to worry! When choosing indicators to search for, there is now a handy preview window to see the detailed information of each indicator.
  • You are no longer limited to just memory data. Redline now enables you to configure and collect a much broader range of data about the target host, such as event logs and file listings. This data will in turn be searchable using the new Indicator of Compromise search options, providing you with better overall search results.

Multi-task with the best

  • With Redline you can now perform investigations while searching for indicators - at the same time! For example, while the session is still matching IOCs, you can start diving into the Malware Risk Indicator (MRI) Scores and start anew investigation or even continue an existing investigation.
  • Now there's no guessing where you are in the process. You can check the progress of your investigation at any time via "Background Tasks" in the main menu. You will also receive a notification when one of your background tasks has been scheduled.

For our current users, be sure to upgrade to this latest version of Redline to take advantage of the new features. For new users, don't wait another minute to download Redline and get your hands on this great set of analysis tools.