Monthly Archives: September 2013

How Will I Fill This Web Historian-Shaped Hole in My Heart?

With the recent integration of Mandiant Web Historian™ into Mandiant Redline™, you may be asking "How do I review my Web History using Redline?" If so, then follow along as I explain how to collect and review web history data in Redline - with a focus on areas where the workflow and features differ from that of Web Historian.

For those of you unfamiliar with Redline, it is Mandiant's premier free tool, providing host investigative capabilities to help users find signs of malicious activity through memory and file analysis and the development of a threat assessment profile.

Configuring Web History Data Collection

Web Historian provided three options for choosing how to find web history data that you want to analyze: scan my local system, scan a profile folder, and parse an individual history file. Redline allows you to accomplish all three of these operations using a single option, Analyze this Computer, which is found under the Main Menu in the upper left corner. Specifying the path to a profile folder or a history file will require some additional configuration:

Figure 1: Finding your web history data Web Historian (Left) vs. Redline (Right)

Click on Analyze this Computer to begin configuring your analysis session. To ensure that Redline collects your desired web history data, click the link to Edit your script . On the View and Edit Your Script window are several options; take a look around and turn on any and all data that might interest you. For our purposes, we will be focusing on the Browser History options underneath the Network tab. This section contains all of the familiar options from Web Historian; simply select the boxes corresponding to the data you wish to collect.

One difference you may notice is the absence of an option to specify the browser(s) you would like to target. You can now find that option by selecting Show Advanced Parameters from the upper right corner of the window. Once advanced parameters are enabled, simply type the name of any browser(s) you would like to target, each on its own separate line in the Target Browser field. To have Redline collect any web history data regardless of browser, just leave this field empty.

You may also notice that enabling advanced parameters activates a field for History Files Location. As you may have guessed, this is where you can specify a path to a profile folder or history file to analyze directly, as you were able to do in Web Historian.

Figure 2: Configuring Redline to Collect Browser History Data

Now that you have finished configuring your script, choose a location to save your analysis session and then hit OK . Redline will run the script, which will require Administrator privileges and may trigger a UAC prompt before running depending on how your system is configured. After a brief collecting and processing time, your web history data will be ready for review.

Reviewing your Data

For the actual review of your web history data, you should feel right at home in Redline. Just like Web Historian, Redline uses a sortable, searchable, configurable table view for each of the individual categories of web history data.

Figure 3: Displaying your web history data for review in both Web Historian (behind) and Redline (front)

Although similar, Redline does have a few minor differences in how it visualizes your data:

  • Redline does not break the data into pages; instead it will discretely page in large data sets (25k+ rows) automatically as you scroll down through the list.
  • To configure the table view, you will need to manipulate the column headers for ordering and resizing, and right-click on a column header to show and hide columns - as opposed to using the column configuration menu in Web Historian.
  • Searching and simple filtering is done in each individual table view and is not applied globally. To access the find options, either press the magnifying glass in the bottom right corner, or press Ctrl-f while a table view is selected.
  • To export your data to a CSV (comma separated values) format file, click on export in the bottom right corner. Like Web Historian, Redline will only export data currently in the table view. If you applied any filtering or tags, those will affect the data as it is exported.

In addition to the features that have always been available in Web Historian, Redline also allows you to review your web history with its full suite of analytical capabilities and investigative tools. Check out the Redline user guide for a full description of these capabilities. Here are just a few of the most popular:

  • Timeline provides a chronological listing of all web-based events (e.g., URL last browsed to, File Download Started, etc.) in a single heterogeneous display. You can employ this to follow the activities of a user or attacker as they played out on the system. You can also quickly reduce your target investigative scope using the Timeline's powerful filtering capabilities.
  • Use tags and comments to mark-up your findings as you perform your investigation, making it easier to keep track of what you have seen while moving forward. You can then go back and export those results into your favorite reporting solution.
  • Use Indicators of Compromise (IOCs) as a quick way to determine if your system contains any potential security breaches or other evidence of compromise. Visit http://www.openioc.org/ to learn more about IOCs.
  • Last but not least, Redline gives you the ability to examine an entire system worth of metadata. With Redline, you are not simply restricted to Web History related data; you can investigate security incidents with the scope and context of the full system.

If your favorite feature from Web Historian has not yet been included in Redline (Graphing, Complex Filtering, etc.), feel free to make a request using one of the contact methods specified below. We will be taking feedback into consideration when choosing what the Redline team works on in the future.

As always, feel free to contact us with send any additional questions. And just in case you do not already have it, the latest version of Redline (v1.10 as of the time of this writing) can always be found here.

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!