Category Archives: IOCs

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. 

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!

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.