Category Archives: Redline

Using Real-Time Events in Investigations

To understand what a threat actor did on a Windows system, analysts often turn to the tried and true sources of historical endpoint artifacts such as the Master File Table (MFT), registry hives, and Application Compatibility Cache (AppCompat). However, these evidence sources were not designed with detection or incident response in mind; crucial details may be omitted or cleared through anti-forensic methods. By looking at historical evidence alone, an analyst may not see the full story.

Real-time events can be thought of as forensic artifacts specifically designed for detection and incident response, implemented through Enterprise Detection and Response (EDR) solutions or enhanced logging implementations like Sysmon. During active-attacker endpoint investigations, FireEye Mandiant has found real-time events to be useful in filling in the gaps of what an attacker did. These events record different types of system activities such as process execution, file write activity, network connections, and more.

During incident response engagements, Mandiant uses FireEye Endpoint Security to track endpoint system events in real-time. This feature allows investigators to track an attacker on any system by alerting on and reviewing these real-time events. An analyst can use our solution’s built-in Audit Viewer or Redline to review real-time events.

Let’s look at some examples of Windows real-time events available on our solution and how they can be leveraged during an investigation. Let’s assume the account TEST-DOMAIN\BackupAdmin was an inactive Administrator account compromised by an attacker. Please note the examples provided in this post are based on real-time events observed during engagements but have been recreated or altered to preserve client confidentiality.

Process Execution Events

There are many historical process execution artifacts including AppCompat, AmCache, WMI CCM_RecentlyUsedApps, and more. A single artifact rarely covers all the useful details relating to a process's execution, but real-time process execution events change that. Our solution’s real-time process execution events record execution time, full process path, process identification number (PID), parent process path, parent PID, user, command line arguments, and even the process MD5 hash.

Table 1 provides an example of a real-time process execution event recorded by our solution.



Timestamp (UTC)

2020-03-10 16:40:58.235

Sequence Number




Process Path




Parent PID


Parent Process Path





"C:\Windows\Temp\legitservice.exe"  -b -m

Process MD5 Hash


Table 1: Example real-time process execution event

Based on this real-time process execution event, the process C:\Windows\System32\cmd.exe with PID 9103 executed the file C:\Windows\Temp\legitservice.exe with PID 9392 and the MD5 hash a823bc31395539816e8e4664e884550f. This new process used the command line arguments -b -m under the user context of TEST-DOMAIN\BackupAdmin.

We can compare this real-time event with what an analyst might see in other process execution artifacts. Table 2 provides an example AppCompat entry for the same executed process. Note the recorded timestamp is for the last modified time of the file, not the process start time.



File Last
Modified (UTC)

2020-03-07 23:48:09

File Path


Executed Flag


Table 2: Example AppCompat entry

Table 3 provides an example AmCache entry. Note the last modified time of the registry key can usually be used to determine the process start time and this artifact includes the SHA1 hash of the file.



Registry Key
Last Modified (UTC)

2020-03-10 16:40:58

File Path


File Sha1 Hash


Table 3: Example AmCache entry

Table 4 provides an example Windows Event Log process creation event. Note this artifact includes the PID in hexadecimal notation, details about the parent process, and even a field for where the process command line arguments should be. In this example the command line arguments are not present because they are disabled by default and Mandiant rarely sees this policy enabled by clients on investigations.



Write Time (UTC)

2020-03-10 16:40:58




Microsoft Windows security




A new process has been created.

Creator Subject:
      Security ID:             TEST-DOMAIN\BackupAdmin
      Account Name:            BackupAdmin
      Account Domain:          TEST-DOMAIN
      Logon ID:                0x6D6AD

Target Subject:
      Security ID:             NULL SID
      Account Name:            -
      Account Domain:          -
      Logon ID:                0x0

Process Information:
      New Process ID:          0x24b0
      New Process Name:        C:\Windows\Temp\legitservice.exe
      Token Elevation Type:    %%1938
      Mandatory Label:         Mandatory Label\Medium Mandatory Level
      Creator Process ID:      0x238f
      Creator Process Name:    C:\Windows\System32\cmd.exe
      Process Command Line:    

Table 4: Example Windows event log process creation event

If we combine the evidence available in AmCache with a fully detailed Windows Event Log process creation event, we could match the evidence available in the real-time event except for a small difference in file hash types.

File Write Events

An attacker may choose to modify or delete important evidence. If an attacker uses a file shredding tool like Sysinternal’s SDelete, it is unlikely the analyst will recover the original contents of the file. Our solution’s real-time file write events are incredibly useful in situations like this because they record the MD5 hash of the files written and partial contents of the file. File write events also record which process created or modified the file in question.

Table 5 provides an example of a real-time file write event recorded by our solution.



Timestamp (UTC)

2020-03-10 16:42:59.956

Sequence Number




Process Path




Device Path


File Path


File MD5 Hash


Num Bytes Seen Written






Event reason

File closed



Base64 Encoded
Data At Lowest Offset


Text At Lowest Offset

Creating 'WindowsServiceNT.log' logfile : OK....mimikatz(command

Table 5: Example real-time file write event

Based on this real-time file write event, the malicious executable C:\Windows\Temp\legitservice.exe wrote the file C:\Windows\Temp\WindowsServiceNT.log to disk with the MD5 hash 30a82a8a864b6407baf9955822ded8f9. Since the real-time event recorded the beginning of the written file, we can determine the file likely contained Mimikatz credential harvester output which Mandiant has observed commonly starts with OK....mimikatz.

If we investigate a little later, we’ll see a process creation event for C:\Windows\Temp\taskassist.exe with the MD5 file hash 2b5cb081721b8ba454713119be062491 followed by several file write events for this process summarized in Table 6.


File Path

File Size

2020-03-10 16:53:42.351



2020-03-10 16:53:42.351



2020-03-10 16:53:42.351



2020-03-10 16:53:42.351





2020-03-10 16:53:42.382



2020-03-10 16:53:42.382



2020-03-10 16:53:42.382



Table 6: Example timeline of SDelete File write events

Admittedly, this activity may seem strange at a first glance. If we do some research on the its file hash, we’ll see the process is actually SDelete masquerading as C:\Windows\Temp\taskassist.exe. As part of its secure deletion process, SDelete renames the file 26 times in a successive alphabetic manner.

Network Events

Incident responders rarely see evidence of network communication from historical evidence on an endpoint without enhanced logging. Usually, Mandiant relies on NetFlow data, network sensors with full or partial packet capture, or malware analysis to determine the command and control (C2) servers with which a malware sample can communicate. Our solution’s real-time network events record both local and remote network ports, the leveraged protocol, and the relevant process.

Table 7 provides an example of a real-time IPv4 network event recorded by our solution.



Timestamp (UTC)

2020-03-10 16:46:51.690

Sequence Number




Process + Path




Local IP Address

Local Port


Remote IP Address

Remote Port




Table 7: Example real-time network connection event

Based on this real-time IPv4 network event, the malicious executable C:\Windows\Temp\legitservice.exe made an outbound TCP connection to

Registry Key Events

By using historical evidence to investigate relevant timeframes and commonly abused registry keys, we can identify malicious or leveraged keys. Real-time registry key events are useful for linking processes to the modified registry keys. They can also show when an attacker deletes or renames a registry key. This is useful to an analyst because the only available timestamp recorded in the registry is the last modified time of a registry key, and this timestamp is updated if a parent key is updated.

Table 8 provides an example of a real-time registry key event recorded by our solution.



Timestamp (UTC)

2020-03-10 16:46:56.409

Sequence Number




Process + Path




Event Type




Key Path


Original Path


Value Name


Value Type


Base64 Encoded




Table 8: Example real-time registry key event

For our solution's real-time registry events, we can map the event type to the operation performed using Table 9.

Event Type Value







PostCreateKey, PostCreateKeyEx, PreCreateKeyEx





Table 9: FireEye Endpoint Security real-time registry key event types

Based on this real-time registry key event, the malicious executable C:\Windows\Temp\legitservice.exe created the Windows service LegitWindowsService. If we investigated the surrounding registry keys, we might identify even more information about this malicious service.


The availability of real-time events designed for forensic analysis can fill in gaps that traditional forensic artifacts cannot on their own. Mandiant has seen great value in using real-time events during active-attacker investigations. We have used real-time events to determine the functionality of attacker utilities that were no longer present on disk, to determine users and source network addresses used during malicious remote desktop activity when expected corresponding event logs were missing, and more.

Check out our FireEye Endpoint Security page and Redline page for more information (as well as Redline on the FireEye Market), and take a FireEye Endpoint Security tour today.

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.

Best of the Best in 2013: The Armory

Everyone likes something for free. And there is no better place to go to get free analysis, intelligence and tools than The Armory on M-Unition. During the past year, we've offered intelligence and analysis on new threat activity, sponsored open source projects and offered insight on free tools like Redline™, all of which has been highlighted on our blog.

In case you've missed it, here are some of our most popular posts:

Challenges in Malware and Intelligence Analysis: Similar Network Protocols, Different Backdoors and Threat Groups

In this post, Mandiant's Intel shares insight on threat activity. Specifically, two separate APT groups, using two different backdoors that had very similar networking protocols. Read more to learn what they found.

New Release: OWASP Broken Web Applications Project VM Version 1.1

Chuck Willis overviews version 1.1 of the Mandiant-sponsored OWASP Broken Web Applications Project Virtual Machine (VM). If you are not familiar with this open source project, it provides a freely downloadable VM containing more than 30 web applications with known or intentional security vulnerabilities. Many people use the VM for training or self-study to learn about web application security vulnerabilities, including how to find them, exploit them, and fix them. It can also be used for other purposes such as testing web application assessment tools and techniques or understanding evidence of web application attacks.

Back to Basics Series: OpenIOC

Will Gibb and a few of his colleagues at Mandiant embark on a series going back to the basics and looking deeper at OpenIOC - how we got where we are today, how to make and use IOCs, and the future of OpenIOC.

Check out related posts here: The History of OpenIOC, Back to the Basics, OpenIOC, IOC Writer and Other Free Tools.

Live from Black Hat 2013: Redline, Turbo Talk, and Arsenal

Sitting poolside at Black Hat USA 2013, Mandiant's Kristen Cooper chats with Ted Wilson about Redline in this latest podcast. Ted leads the development of Redline where he provides innovative investigative features and capabilities enabling both the seasoned investigator and those with considerably less experience to answer the question, "have you been compromised?"

Utilities Industry in the Cyber Targeting Scope

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

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 ""
  • 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 "\$". 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 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 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 Once he collects information on 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 "".

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 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. 

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 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.

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!

Mandiant @ Black Hat USA 2013

In just a few short weeks we'll be boarding a flight to Las Vegas, NV for Black Hat USA 2013. In addition to clothes and toiletries, I want to make sure you go to the annual conference with a full list of Mandiant's activities at the show.

Black Hat Exhibitor Floor:

  • Visit Mandiant at booth #325
  • Pick-up a t-shirt and talk to some Mandiant folks



Join Mandiant for an unforgettable evening at the famed Shadow Bar, in Caesars Palace. The evening will showcase silhouetted performances by the shadow dancers, and libations will be served up by the venues world-class bartenders who are known to juggle bottles, toss limes, twirl glasses and even do back-flips.

Books & Beer Signing:

  • Richard Bejtlich: "The Practice of Network Security Monitoring"
    Wednesday, July 31
    4:30 - 5:00 PM
    M Lair: Verona Room, The Promenade Level

Book signing with Richard Bejtlich for his new release, "The Practice of Network Security Monitoring", and happy hour. The first five people in line for the book signing will win an invitation to a very special VIP dinner with Richard Bejtlich and Michael Sikorski, and will receive a free copy of their books. The first 30 people in line receive a FREE copy of Richard's book!

  • Michael Sikorski: "Practical Malware Analysis"
    Thursday, Aug 1
    4:30 - 5:00 PM
    M Lair: Verona Room, The Promenade Level

Book signing with Michael Sikorski for his 2012 release, "Practical Malware Analysis", and happy hour. The first 30 people in line receive a FREE copy of Michael's book!

A Day in the Life Presentations

  • Mandiant Labs (M-Labs)
    Wednesday, July 31
    12:45-1:30 PM

Mandiant's Michael Sikorski and Stephen Davis will walk attendees through a typical day for a malware analyst and how they have successfully integrated machine learning into their research.

  • Mandiant MCIRT Analysts
    Thursday, August 1
    12:45 - 1:30 PM

Mandiant's James Condon and Mike Scutt will walk attendees through a typical day as an MCIRT Analyst, using an attack scenario to highlight the tools and processes used by MCIRT Analysts to successfully investigate a compromise.


  • IOCWriter_11
    Presented by William (Will) Gibb
    Thursday, August 1
    10:00 AM - 12:30 PM
    Station 7

With the impending release of the OpenIOC 1.1 format for sharing threat intelligence, Mandiant will be releasing a set of open source tools for creating and manipulating OpenIOC objects and moving data in and out of the OpenIOC format.

Demonstrations will cover how the tools can be used to create and modify OpenIOC documents, show how it is possible to store Snort and Yara signatures in OpenIOC format and convert those OpenIOC documents back into their native formats. In addition, the integration of these tools into other open source applications will be demonstrated with tools that can automatically extract IOCs from unstructured content.

  • Mandiant Redline™
    Presented by Theodore (Ted) Wilson
    Thursday, August 1
    12:45 - 3:15 PM
    Station 7

Redline, Mandiant's premier free tool, provides host investigative capabilities to users to find signs of malicious activity through memory and file analysis, and the development of a threat assessment profile. With Redline, users can:

- Thoroughly audit and collect all run processes, audit data, and memory images.

- Analyze and view imported audit data, including narrowing and filtering results around a given timeframe using Redline's - Timeline functionality with the TimeWrinkle™ and TimeCrunch™ features.

- Streamline memory analysis with a proven workflow for analyzing malware based on relative priority.

- Identify processes more likely worth investigating based on the Redline Malware Risk Index (MRI) score.

- Perform Indicator of Compromise (IOC) analysis. Supplied with a set of IOCs, the Redline Portable Agent is automatically configured to gather the data required to perform the IOC analysis and an IOC hit result review.

  • OWASP Broken Web
    Presented by Chuck Willis
    Thursday, August 1
    12:45 - 3:15 PM
    Station 8

The Open Web Application Security Project (OWASP) Broken Web Applications project ( provides a free and open source virtual machine loaded with web applications containing security vulnerabilities. This session will showcase the project VM and exhibit how it can be used for training, testing, and experimentation by people in a variety of roles.

Demonstrations will cover how the project can be used by penetration testers who discover and exploit web application vulnerabilities, by developers and others who prevent and defend against web application attacks, and by individuals who respond to web application incidents. New features and applications in the recently released version 1.1 of the VM will also be highlighted.

Let us know if you'll be at Black Hat USA 2013!

Redline: Answering Your Questions

Those of you who attended the "Tools of Engagement: Redline™ - We've Got the Tool, If You've Got the Time" webinar last month by David Ross and myself will recall that we ran short on time while answering all of your questions. The webinar covered the latest updates to Redline, Mandiant's free tool for investigating hosts for signs of malicious activity through memory and file analysis, and subsequently developing a threat assessment profile.

If your question was one of those we did not get to, don't worry. We are going to cover all of those unanswered questions in this post, as well as retread some of those which were covered during the Q&A for people who were unable to catch it live. 

Without further ado, following are your answers in no particular order:

Does Redline support disk images for collection and analysis?

At the moment, Redline only works on memory images and live hosts. We are currently focusing on providing the best possible set of analysis tools for incident response.

Does Redline work for Macs or Mac Memory images? Does it work on Linux?

Redline officially supports data collected with Mandiant Intelligent Response® (MIR), Mandiant Memoryze™, or a Redline Collector.

Unfortunately, all of those currently only support collection on the various Windows platforms. However, I have heard of people having success getting audits collected with Memoryze™ for the Mac to at least import into Redline. Be careful to note that if attempting this, the MRI scores and other analyses may be incorrect or invalid, as the scoring in Redline assumes it is operating against data collected from a Windows host.

Is there a specific audit you need to run in order to do Timeline Analysis?

Short answer: no. The timeline analysis will parse any and all data with timestamps available for collection. The comprehensive collector option in Redline is the recommended starting place if timeline analysis is your goal as the standard collector collects very little in the way of timestamps.

How valuable would Redline be against a virtual machine created from a forensic image?

As long as you can log in to the virtual machine with administrator rights to run the collection, Redline should have no problem importing and analyzing the data (provided it is one of the supported operating systems).

Is Redline free when used on an enterprise environment?

Redline is free to use in any sized environment, although the collection aspect of Redline quickly becomes challenging with large scale and globally distributed networks. This leads to the next question...

Can Redline collection be run on a remote machine?

Redline does not itself support remote collection. We recommend purchasing Mandiant Intelligent Response® if you would like centralized remote collection of your hosts' data over an enterprise sized network.

Can you demonstrate how to use TimeWrinkles™ for events that occur over multiple days and put them all into one view?

The easiest way to view timeline windows that are separated by greater than an hour is to create multiple manual TimeWrinkles around the points of time you are specifically interested in.

Using item based TimeWrinkles you can also potentially see time entries that occur over multiple days. For instance, you could see the actions that happened around the creating of a file, as well as when that same file was last accessed a few days later all in one view, just by creating a TimeWrinkle around that file.

How do you get a TimeWrinkle based on a file?

If you select any row within the Timeline and right click on it, Redline will give you the option to create a TimeWrinkle based on that item. In this case, you would just need to find the file in question within your timeline, select it, and choose "Add a New TimeWrinkle" from its right click menu.

Can Redline be used to pull strings from a memory image? We would like to pull info from the csrss process to see what commands might have run on a box.

Redline can be configured to collect strings using the process listing audit against both a memory image and a live machine. You can collect strings from files with the File listing audit, but this option is only available against a live machine.

We do recommend restricting string collection to a single process or file at a time though, as turning strings collection on for a full process or file listing will significantly increase the amount of data returned and the time it takes to collect it.

Can I export the data to a file?

Copy and Pasting from any of the list views (including Timeline), will place up to 20k selected rows onto your clipboard in CSV format. Using the right-click menu's copy options also allows you to specify if you would like to include a header row in your data or not. Full list CSV export directly to a file will be available in the next release of Redline.

Is the timeline feature available in Mandiant Intelligent Response ® (MIR ® )?

Timeline as it exists in Redline is not available in MIR. But using the "open with..." feature in the MIR Console on any audit result will allow you to import your data you would like to timeline directly into Redline for analysis.

Is there a way to get external data sources in to Redline that are not host-based? (ex. IDS, flow, etc.)

At the moment Redline only supports analysis of the xml data which is collected by the various Mandiant products listed above. Full schema definitions for those formats can be found here.

How much alteration is being done to the suspect system by Redline?

Depending on if the collector is being run from the host's hard disk as opposed to an external drive, the collection and log files have the potential to overwrite some amount disk slack space. Also if the "Preserve Timestamps" option is not configured on your collector, some audits may modify the timestamps for files they touch. You can find the "Preserve Timestamps" option at Main Menu -> Redline Options->Default Script Options->General->Preserve Timestamps". Redline defaults this option on.

Prior to re-image, what is a good Redline collector that can quickly get information to sift through later?

If the next immediate action is to re-image the box, I tend to err on the side of collecting as much information as time permits, since there will be no second chance to go back and recollect additional data. But for a little bit faster collection time, I suggest starting with the comprehensive collector and scaling back or removing the larger audits: files, registry, and processes.

While the collector run times depend heavily on machine in question, it is not unheard of for the comprehensive collector to run 1-2 hours. By limiting the files audit to a specific base path like the Windows directory or the System32 directory, and limiting your registry audit to a few specific keys (i.e. HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRun) you can significantly reduce the time that your collection will take to run. If you need to collect even quicker, consider turning off the various hashes like MD5.

Can I run this tool via command line?

The collector runs as a batch script via the command line, but the analysis and visualization portions are only available through the graphical user interface.

Are you limited to the types of variants/intrusions you can scan for?

The Malware Risk Index (MRI) scoring configuration is limited in the types of things it allows you to look for, but within those confines you can add or tweak to your heart's content. Indicators of Compromise (IOC) provide a much more flexible definition format to describe what malware you would like to search for. The first Tools of Engagement: Redline webinar walks through an example of creating a new MRI rule and an Indicator of Compromise in the course of performing the investigation and applying them to a Redline analysis.

Can you tell if the attacker has manipulated the time stamps of the files?

Redline does not automatically detect timestamp manipulation. But often an experienced eye can pick it out by looking for things such as every potentially suspect files encountered having "00" for their seconds place, or similar statistically improbable occurrences.

Is there any known malware that targets Redline? Have you had any difficulties with attackers running their tools inside rootkit protection?

We have yet to encounter any malware that has specifically attempted to avoid collection or detection by Redline and its various analysis techniques. As for general rootkit protection, Redline uses raw disk access by default where possible to avoid being subverted by rootkits.

What metadata shows how many times an executable has executed?

Prefetch files (.pf) are windows specific cache files to improve application startup performance. They contain the first and last run time as well as how many executions have occurred in total. These files are parsed and their relevant data captured by the Prefetch audit available in the Redline Collector setup.

That wraps up all of unanswered (as well as answered) questions! And just in case you do not already have it, the latest version of Redline (1.7 as of the time of this writing) can always be found here.




Carving Station – RAR Files

This post will discuss the technique of carving files from unallocated disk space. "Carving" simply means extracting a specific section of bytes from an area of disk space; ideally those bytes make up a complete file. You can carve any kind of file, but in this post we will specifically address how to carve RAR archives from unallocated disk space.

Why RAR files? In many of Mandiant's investigations of targeted attacks, an attacker will collect data and compress it into a RAR archive prior to taking it from the targeted network. Advanced attackers go a step further and attempt to hide their tracks by deleting the archive tool, the archive itself and other artifacts we will discuss in future blog posts.

RAR Carvin'

What can you do when the attacker deletes the archive? In our example case, we know the attacker executed "rar.exe" a.k.a. "WinRAR" because the evidence contained a prefetch file named "". At this point, the easiest investigative step is to search for files with the extension ".rar" or - even better - conduct file signature analysis in the event the attacker changed the file extension. If you don't find any files, does this mean the attacker executed WinRAR just for fun? Most likely not.

Since we know the attacker used WinRAR, but deleted the resulting files, conduct a search for RAR file headers in unallocated space (the "deleted" files graveyard). A "file header" is the signature placed at the beginning of a file. Most RAR files start with the ASCII characters "Rar!···" or "52 61 72 21 1A 07 00" in hex. Older versions of WinRAR may create files with different values in the last three header bytes. To reduce false negatives, it's best to search for "52 61 72 21" or "52 45 7E 5E" to find older RAR formats (see Forensics Wiki).

In this case, we will conduct a search for "Rar!" in unallocated space and find a section of the disk that looks especially interesting.

Figure 1: RAR Header in Unallocated Space

As with any keyword search, be careful of false positives! Some antivirus vendors, such as Symantec, use RAR files for signature updates. There may also be false positives due to the random nature of the data in unallocated space. To help counteract the false positives, you can narrow search results by identifying the position of the header in the data cluster and/or the composition of the data after the header. The position in the data cluster is important because when a file is created on disk, the beginning of the file will be at the start of the data cluster. Data clusters are a portion of logical disk space allocated for a file. Notice the data in Figure 1 is condensed, which is expected for an archive file. If the composition of the data after the header is condensed and randomized, this offers more evidence that the search result is a legitimate RAR file. Compare Figure 1 to the result in Figure 2 below, which has partial cleartext and breaks in the data. The result in Figure 2 is not a valid RAR archive.

Figure 2: False positive RAR Header in Unallocated Space

Once a legitimate header is identified, carve the data from unallocated space starting with "Rar!". Since a RAR file does not have a footer, or a defined end of the file, we have to guess the size. A raw view of the unallocated space may help visually define the file size. There is normally a clear demarcation at the end of the RAR file, a "RAR end" if you will, as shown in Figure 3 below.

Figure 3: RAR End in Unallocated Space

If you have no idea of the file size, 5MB is a good size to start with; but you will most likely have to increase or decrease the size until there is no more contiguous data or the data is overwritten/fragmented. EnCase or FTK can be used to manually export the data, or free tools such as Foremost or Scalpel. FTK also has a built in capability to automatically carve files based on a defined header and/or footer.

Once the RAR file is carved out, you can open it with your favorite file archive tool such as WinRAR, 7-Zip, or WinZIP. If you are unable to open the file, try carving files with different sizes. Bigger is usually better; a valid RAR archive generally won't open if there is too little data rather than too much. If the file is a legitimate RAR with enough data, you should be able to extract the archive (even if it's a partial file). In this example, a password prompt appears. Now you know this is an interesting file!

Figure 4: Password prompt

How can we find the password? Your chances depend on several factors, such as the age of attacker activity, level of general activity on the system and size of memory. If you are lucky enough to have a memory image, you can search the strings in memory using a tool such as Mandiant Redline™. Otherwise, you can search unallocated space and the Windows pagefile for WinRAR command line switches such as "-hp". This switch enables the creation of a password protected archive. After removing the inevitable false positives, your results will look similar to Figure 5 shown below.

Figure 5: RAR command in pagefile.sys

The Windows pagefile shown in Figure 5 also retained a directory listing of potential files that were in the archive. This shows you can still glean information from RAR command searches even if the RAR file is unrecoverable. If the password search doesn't work, you can try to crack the password using brute force or dictionary attacks. However, if you are not the NSA, you may have limited success with this.

RAR file content indicators

Worst case scenario, if you can't find or crack the RAR password, remember the ultimate goal: to determine what is inside the archive. Following are four ways - with brief explanations - for how to retrieve additional information on what was inside an archive.

  1. Prefetch file
    If you are fortunate enough to have a prefetch file for rar.exe, that may show accessed files. The prefetch file contains a large amount of data, such as first and last run dates, path to the executable and accessed file. NirSoft's Winprefetchview is a useful free tool you can use to extract prefetch data. Figure 6: Files accessed by rar.exe shown in WinPrefetchView
  2. WinRAR directory
    What if there is no prefetch file? You may be able to determine whether RAR was executed if a "WinRAR" directory is present on the file system. The default directories are "%APPDATA%WinRAR" on Windows XP and "%APPDATA%RoamingWinRAR" on Windows 7. Depending on the version, WinRAR may create this directory by default when the program executes. If you're lucky enough to have this evidence, you can create a timeline around the creation and modification dates of the "WinRAR" directory to find corresponding files of interest.
  3. Shellbags
    Windows creates "shellbags" when a user logs into a system locally or interactively. They track information for Explorer. A helpful attribute of Shellbags is that they track previously navigated directories, even deleted directories. So, if an attacker gathered information in a staging directory prior to compressing into a RAR file, you could potentially see that directory in Shellbags. Willi Ballenthin created a nice python script to parse Shellbags which can be found here.
  4. Internet History
    Internet Explorer not only records Internet browsing, but internal system navigation as well. If an attacker was logged on interactively, the IE history could reveal the targeted files. Attackers are aware of this and will delete internet history, especially on an account that is not used frequently. By the way, you can also carve deleted internet history, but that's a topic for another day.

These four techniques are just the first step. You may need to create and search for additional keywords, conduct timeline analysis, or even analyze an entirely different system if the original location of the targeted files was external.

If you would like to practice carving different types of files, including RAR files, NIST recently released forensic images intended for testing file carving capabilities of software, There are many file carving tools out there, so if you have any recommendations, feel free to direct message me on Twitter @marycheese.

A Look Back at 2012: The Armory

 As we are mere hours away from celebrating 2013, we'd like to focus today on M-Unition's Armory channel. The Armory is the place to be if you want to be the first to find out about the latest releases, free tools and of course, our ever popular M-Trends report. The most popular posts in this category are listed below for your reading pleasure.

New Product Offering: Mandiant Cloud Alert

This past year we made several product announcements, but this one was especially rewarding. When you deal with cybersecurity risks on a daily basis you need tools to help you see activity in real time. At MIRcon ™ 2012, we announced our newest product offering: Mandiant Cloud Alert™. Mandiant Cloud Alert is a powerful tool, enabling organizations to identify malicious communication, audit existing security measures, monitor how the organization is trending over time, and track incidents in their network.

Unibody Memory Analysis - Introducing Memoryze™ for the Mac 1.0

Memoryze™ for the Mac 1.0, which brings memory imaging and analysis to the Mac, joins a growing list of freeware tools Mandiant provided this past year.

Memoryze for the Mac 1.0 brings many of the features of Memoryze™ to the Apple Macintosh platform. This new tool enables acquisition of memory images via the command-line or a simple GUI. In addition, Memoryze for the Mac 1.0 can perform offline analysis against memory images or live analysis on a running system.

Leveraging the Application Compatibility Cache in Forensic Investigations

Freeware tool, Shim Cache Parser™, was developed in the course of our incident response investigations, according to Mandiant's Andrew Davis.

During keyword searches of compromised systems, the Mandiant team discovered known malicious file names in the Windows Registry. Further research showed the cache data was generated by the Windows Application Compatibility Database. Along with these file names, other types of file metadata can be recovered such as file size, file last modified times, and last execution time, depending on the operating system version. This data can be very useful during an incident response. It helps identify which systems an attacker may have executed malware on and can also provide information about the time that it may have occurred.

Shim Cache Parser is the proof-of-concept tool we developed to extract this useful forensic evidence. You can download it here.

Mandiant Introduces Reverse-Proxy Open Source Tool

Mandiant's Sean Cunningham and Mark Thomas discuss the availability of a highly efficient reverse HTTP(S) proxy called simply 'RProxy™'. Mandiant released RProxy as an open sources tool to encourage the general community to participate in its evolution. You can download the tool here.

M-Trends: The One Threat Report You Need to Read

Each year Mandiant takes a look back at engagements we've responded to and puts together trends that help you fight back against targeted threats. On March 6th, we released our latest M-Trends report, An Evolving Threat, which revealed key insights, statistics and case studies illustrating how the tools and tactics of targeted attackers, including the Advanced Persistent Threat (APT), have evolved over the last year. We're currently working on the 2013 edition of M-Trends and plan to release it at RSA 2013.

Freeware Release: Redline 1.7

Redline™ is Mandiant's free tool for investigating hosts for signs of malicious activity through memory and file analysis, and subsequently developing a threat assessment profile. It combines configurable collection of Mandiant's full range of forensic artifacts (the same set available to our enterprise product, Mandiant Intelligent Response®, guided analysis, Mandiant's Custom Malware Risk Index (MRI) scoring, and Indicator of Compromise (IOC) matching) to provide you with the tools needed to rapidly triage a potentially compromised host.

Recently, we released Redline version 1.7. To make this the most compelling release to date, we focused on two of the most frequently requested features: Timeline and Search.


With Timeline, we wanted to do more than just slap together all date related items into a staggering list that buries you under more data than is humanly possible to review. Even on infrequently used systems, hundreds of thousands of dated artifacts are collected using the Redline Comprehensive Collector. To help narrow a complete timeline down to a manageable subset of data we have provided you with a trio of powerful filtering capabilities: Field Filters, TimeWrinkle™ and TimeCrunch™.

You can use these filters to shave down your timeline to a manageable number of events . We have made it simple to quickly scan your list for suspicious activity by providing you with a summary column that highlights valuable information about any given event. But do not fear, if you need to investigate any item in further detail, you can select that event and choose the "Show Details" button to view everything we have collected.

Figure 1: The new Timeline view in Redline

Field Filters

Field filters are a straightforward means of excluding or including entire categories of time related events from your view by simply checking those that you care about. For example, we often find that File Accessed events tend to be very noisy. With field filters you can remove them from view until they are absolutely necessary.

Even when you use field filters, we realized that there was still too much data for manual review. Naturally, we turned to our expert professional services consultants to see how they comb through large quantities of time-oriented data. Unable to find a good solution that met their needs, they developed the concepts of TimeWrinkle and TimeCrunch. We worked closely with them to bring these tools to Redline's new Timeline capabilities.


TimeWrinkle provides you with the means to filter your Timeline view to display only the events that occurred in a set of configurable windows of time. TimeWrinkle comes in two varieties: custom and item-based. Choosing which variety to use and when simply depends on the type of investigative lead you start with.

If you know the general time when suspected malicious activity occurred (whether from a user IT ticket, an IDS log, or some other similar means) you use a custom TimeWrinkle to restrict your timeline to only events that took place around that region of time. If the default five minute window radius is not sufficient, you can adjust it anywhere between 0 and 60 minutes to better suit your needs.

However, if you know something more specific about the suspected malicious activity (such as a file name or MD5 checksum) you can use an item-based TimeWrinkle. Creating an item-based TimeWrinkle will take a selected item (e.g. File, Registry Key, Process, etc.) and narrow your timeline to events that take place around any of the of the associated timestamps for that item. To create an item-based TimeWrinkle, right click on any item in the Timeline and select "Add New TimeWrinkle". This will use default settings to generate a TimeWrinkle around the selected item which can then be edited to exclude, include, or adjust any of the individual field windows within the TimeWrinkle.

Figure 2: Timeline Configuration


There can still be times where you have too much data to review manually even after you have trimmed your timeline to a narrow window using TimeWrinkles. To further aid you in reducing your data, we also provide the ability to trim out a minute worth of events for a specific field by using a TimeCrunch. TimeCrunches are useful when Field Filters (being applied so broadly) are detrimental to your investigation, and instead you need to remove specific event types in a more surgical manner.

The most common example of this is when an antivirus scan updates the file accessed timestamp on a very large number of files in a very short amount of time. When this occurs, the file accessed timestamp will become too noisy to be of investigative use for the window in which the antivirus scan ran. Applying a TimeCrunch can quickly exclude a minute worth of this cluttersome data without losing potentially relevant file accessed timestamps elsewhere in your timeline as with Field Filters.

Figure 3: TimeCrunch


Now you are probably saying to yourself, "Timeline sounds awesome, but what do I do if my investigative lead is not something that is time based?" For example, what do you do if your lead is a potentially compromised credit card number. No worries, we have considered you as well.

Now standard on every list shaped view in Redline is a full featured search capability. For example, by using the search feature you can quickly search the entire list of strings from all processes in memory to determine if the suspect credit card number was present. If any matches are found, we will highlight and scroll to each of them. And if your investigative lead is less specific (e.g. you suspect that some unknown credit card numbers may have been stolen) we also allow you to specify your search criteria as a Regular Expression.

For our current Redline users, upgrade to this latest version of the freeware tool 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. Please be sure to check out the updated user documentation for more details and drop by the Redline section of the Mandiant forums to give us feedback on your experience and post any questions you may have.

Lastly, be sure to tune in to our upcoming This entry was posted in Free tools, Freeware, Indicator of Compromise, IoC, Redline, Ted Wilson on by .

Using AuditParser to Process and Analyze Large Volumes of Data Collected with Redline

In this blog post, I am going to show you some ways to review data that have been collected with the Mandiant Redline™ tool, without using the Redline interface. I will be using Mandiant's AuditParser™ tool in order to transform the Redline audit XML into tab separated data. This will let you take data and view it in different ways, as well as perform timeline analysis on data you have collected. I will focus on using data collected by a Redline Portable collector, which was configured to perform a Comprehensive Collection. The AuditParser tool will also work with audit data that have been collected with the MIR Agent, or with IOCFinder™.

Timeline analysis can be an important technique when performing an investigation on a system. It involves taking data from several sources, in this case, Redline audit data, and sorting it chronologically. This allows an analyst to see numerous data sources in a chronological fashion, allowing multiple, discrete events to be correlated together. I will be demonstrating timeline analysis, with AuditParser, on a system that is infected with malware.

The first item I want to show is how AuditParser converts audit data to the tab separated files. Once you've got the AuditParser tool, you can run it, and point to the directory of audit data that you have collected with Redline. There is also a Windows executable version of this tool available, if you do not have access to Python.

C:Documents and SettingsUserDesktopAuditParser>python -i ..LR_Collection -o ..Processed_Audits
Parsing input file: ..LR_Collectionmir.w32apifiles.1176360b.xml
Parsing input file: ..LR_Collectionmir.w32eventlogs.771e480e.xml
Parsing input file: ..LR_Collectionmir.w32registryapi.3e2e3e42.xml
Parsing input file: ..LR_Collectionmir.w32scripting-persistence.27091e25.xml

This will output a set of files in ..Processed_Audits, which are the tab separated files, one for each audit in the input.

C:Documents and SettingsUserDesktopAuditParser>dir ..Processed_Audits
Directory of C:Documents and SettingsUserDesktopIndividual_Audits
10/19/2012 08:56 PM
20,385,250 mir.w32apifiles.1176360b.xml.txt
10/19/2012 08:56 PM
592,829 mir.w32eventlogs.771e480e.xml.txt
10/19/2012 09:00 PM
48,625,256 mir.w32registryapi.3e2e3e42.xml.txt
10/19/2012 09:01 PM
301,325 mir.w32scripting-persistence.27091e25.xml.txt

Now that you have these files parsed, you can start performing analysis with any software that supports processing tab separated files, such as Microsoft Excel or Apache OpenOffice. This lets you quickly sort and filter data you have collected and quickly look for anomalies. Below is a screenshot of the output of the Persistence audit. The persistence audit combines the File, Registry and Services audit to look for executable files that will persistently run on a system. Each of the columns - denoting information collected from the Registry, Filesystem and Services - can be filtered in order to perform an investigative analysis.

Click to enlarge image

If you sort by files that do not have digital signatures (Column: Signature Exists, select 'False'), one entry is found. This is a serviceDLL entry. This indicates that there is an unsigned service running on this system. The Persistence audit gives you some information you can use to further analysis. It gives the location to the file on the file system, the file owner, a hash of the file, Registry path & value information. The file full path, "c:WINDOWSimewmimachine2.dll" is not a typical location for a service DLL, so this item is definitely something worth investigating.

Click to enlarge image

You could continue reviewing data in individual audits using some of the information presented in the Persistence audit module. In fact, there is some additional information contained in the XML for the persistence item, pertaining to the file 'wmimachine2.dll.' Continuing with the individual audits would be familiar sorting and filtering operations, so that will be skipped for now. Instead, what I'm going to show next is how to timeline the audit data that we have already collected in order to identify other items of interest which have occurred around the creation of our malicious serviceDLL. In order to do this, I will rerun the AuditParser tool with the timeline switches.

C:Documents and SettingsUserDesktopAuditParser>python -i ..LR_Collection -o ..Processed_Audits
ed -t --starttime 2012-10-18T00:00:00Z --endtime 2012-10-21T00:00:00Z

This will rerun AuditParser, regenerating the .txt files you already have processed and creating a new file, timeline.txt. This is a tab separated file that contains a timeline of File, Registry, Event Log, Url History, Process Item and Prefetch audit data. I picked a date range of 2012-10-18 through 2012-10-20 to timeline.

Here is a screenshot of timelined data:

Click to enlarge image

You can see that we timeline on multiple timestamps for each item. For instance, a file can have up to eight different timestamps (API + NTFS timestamps), and the AuditParser tool will create an entry for each of those timestamps.

From the Persistence audit data, you can see the file created date is "2012-10-20T01:06:55Z". You can start by narrowing down the date range of items displayed by filtering the date with the string '2012-10-20T01'. This will show you all of the activity on 2012-10-20 between 01:00:00Z and 01:59:59Z. Below is a screenshot of some activity around the time of interest.

Click to enlarge image

If you look through the data, you can see that there was a file staged in C:Recycler, named 'scvhost.exe'. This was likely executed with a command shell, cmd.exe. After scvhost.exe was executed, you can see the Eventlog record the service start for the ".NET Runtime Optimization Service v2.086521.BackUp_X86" service. Further down, you can see artifacts in the registry where the '6to4' service has been hijacked and used to host this new, malicious service. Here you can see the how the registry has been timelined, and shows the Paths and Values.

Click to enlarge image

This does not necessarily finish the investigation of this host. Malware analysis may need to be performed on the malware 'scvhost.exe' and 'wmimachine2.dll' in order to identify additional host-based and network-based indicators of compromise. The source of 'scvhost.exe' has not been identified, so that would require further investigation.

Hopefully, this demonstration of using AuditParser to process Redline audit data has been helpful, showing a new way to process and analyze the large volume of data that can be collected with Redline. The timeline capability of AuditParser can be a powerful analysis tool. If they are not already, Redline and AuditParser should become part of your investigative toolkit. You can download each tool here (Redline) and here (AuditParser).

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.

New Open Source Tool: Audit Parser

Mandiant RedlineTM and IOC Finder TM collect and parse a huge body of evidence from a running system. In fact, they're based on the same agent software as our flagship Mandiant Intelligent Response® product. During the course of their "audits", these tools conduct comprehensive analysis of the file system (including hashing, time stamps, parsing of PE file structures, and digital signature checks), registry hives, processes in memory, event logs, active network connections,DNS cache contents,web browser history, system restore points, scheduled tasks, prefetch entries, persistence mechanisms, and much more.

Once this data is collected, Redline and IOCFinder currently allow you to do one of two things:

  • Review the contents of memory through a visual workflow in Redline
  • Search for Indicators of Compromise (IOCs) and generate a report of "hits"

But what if you want to analyze all of the raw evidence - not just memory or IOC hits - and do traditional forensics and timeline analysis? That's where Audit Parser steps in. It's the newest addition to Mandiant's portfolio of free software.

Audit Parser is simple:it takes the complex XML data produced by Redline or IOCFinder and converts it into human-readable tab-delimited text. You can then easily review the output in Excel, use a dedicated CSV file viewer (we're fans of "CSVed" and"CSVFileView"), import it into a database, or grep / manipulate it to your heart's content.

When paired with Redline's new start-up workflow to build a "collector" script, Audit Parser gives you a complete(and free)live response analysis toolkit. You can customize the Redline collector to gather as much or as little evidence as desired, run it on your target system, and then easily review all of the results following a quick conversion with Audit Parser.

The screen capture below shows Audit Parser's options - it's pretty straightforward to use:

Tabular data in Excel doesn't make for the most exciting screen shots, but we wanted to give you a glimpse into what the output looks like and the extent of evidence available for filtering, sorting, and analysis:

  • A filtered view of a file system audit, showing complete file metadata for all PE files within %SYSTEMROOT% created between 2011-2012 that are not digitally signed.

  • A portion of a prefetch audit, showing how the contents of .PF files are automatically parsed to provide last time executed, # of times executed, and original file path metadata.

  • A portion of a full registry dump, showing review of Active Setup Installed Components registry keys - the data includes all key value / data pairs and last modified dates.

  • A portion of the parsed Windows event logs, showing review of process auditing events including event log source, time generated, event ID, and full event message contents.

The default "comprehensive collector" script in Redline collects all of the artifacts listed above, as well as many more.

But wait - that's not all! Audit Parser also contains timeline generation functionality. Just specify a time & date range, and it will build a sorted timeline of all file system, registry, and event log events that occurred within that period. Future releases will add more audit types and customizability to this feature.

Audit Parser is written in Python and is distributed under the Apache License. It requires the lxml ( library. We're also distributing a Windows EXE built with Py2EXE for users that may not have a Python environment set up. You can download the tool and documentation on GitHub at:

If you have any questions or comments, feel free to leave them below, e-mail me (ryan [dot] kazanciyan [at], or DM me on Twitter at @ryankaz42. I'll also be at Black Hat USA next week teaching Mandiant's Incident Response course where we'll be going through an in-depth live response analysis lab using Redline, Audit Parser, and other forensic tools. I was on a recent M-Unition podcast discussing the class and how it is completely revamped for 2012. You can listen to the podcast here. Hope to see you there!

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 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 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 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.


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 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.