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
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
Process Execution Events
There are many historical process execution artifacts including AppCompat,
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.
Parent Process Path
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
File Last Modified (UTC)
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
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.
Process Information: New
Process ID: 0x24b0 New Process
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
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.
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.
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.
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.
Process + Path
Local IP Address
Remote IP Address
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 10.0.0.51:443.
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.
Based on this real-time registry key event, the malicious executable
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.
In our blog post
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
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
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."
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
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.
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
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
File metadata like filename and MD5.
A uniquely named process handle discovered by John's malware
A prefetch entry for the "msspcheck.exe"
Registry artifacts associated with persistence of
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
Figure 1: Augmented IOC for
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.
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
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:
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.
Chuck Willis overviews version 1.1 of the Mandiant-sponsored
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.
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
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
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.
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
Table 1: Summary of significant
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
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
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
Malware which uses the same Mutex, a process
attribute that will prevent the machine from being infected
multiple times with the same backdoor
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
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
"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.
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"
On October 15, 2013, at 12:15:37 UTC, the
Sysinternals PsExec utility was created in
"C:$RECYCLE.BIN". Approximately four hours later, at
16:11:03 UTC, the attacker used the Internet Explorer browser to
access text files located in "C:$RECYCLE.BIN". Between
16:11:03 UTC and 16:11:06 UTC, the attacker accessed two text files
which were no longer present on the system. At 16:17:55 UTC, the
attacker mounted the remote hidden share
"\10.20.30.101C$". At 16:20:29 UTC, the attacker executed
the Windows "tree" command, resulting in the creation of a
prefetch file, a command which produces a filesystem listing. At
17:37:37 UTC, the attacker created one WinRAR archive,
"C:$Recycle.Bina.rar" which contained two text files,
"c.txt" and "a.txt". These text files contained
output from the Windows "tree" and "ipconfig"
commands. No further evidence was present on the system. John noted
that the earliest event log entries present on the system start
approximately two minutes after the creation of "a.rar".
It is likely that the attacker cleared the event logs before
disconnecting from the system.
John identified the lateral
movement to the 10.20.30.101 host, from "ACM-BOBBO"
through registry keys that recorded the mount of the hidden C$
share. By recording this type of artifact in an IOC, John will be
able to quickly see if the attacker has pivoted to another part of
the Acme Widgets Co. network when investigating 10.20.30.101. He
included artifacts looking for other common hidden shares such as
IPC$ and ADMIN$. The effectiveness of an IOC may be influenced by
the environment the IOC was created for. This IOC, for example, may
generate a significant number of false-positives in an environment
where these hidden shares are legitimately used. At Acme Widgets
Co., however, the use of hidden shares is considered highly
Figure 4 IOC for Lateral
At the end of the day, John authored three
new IOCs based on his current investigation. He knows that if he
records the artifacts he identified from his investigation into the
"ACM-BOBBO" system, he can apply that knowledge to the
investigation of the host at 10.20.30.101. Once he collects
information on 10.20.30.101 with his Redline portable collector,
he'll be able to match IOCs against the Live Response data, which
will let him identify known artifacts quickly prior to beginning
Live Response analysis. Although John is using these IOCs to search
systems individually, these same IOCs could be used to search for
evidence of attacker activity across the enterprise. Armed with this
set of IOCs, John sets out to hunt for evil on the host at
Stay tuned for our next blog post,
seeing how this investigation develops.
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.
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.
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 (firstname.lastname@example.org), the name of the IOC (Evil.exe
(BACKDOOR) and a brief description such as "This variant of the
open source Poison Ivy backdoor has been configured to beacon to
10.127.10.128 and registers itself as "Microsoft 1atent time
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
The name of a service is "MS 1atent time
services" - OR -
The ServiceDLL name for any
service contains "evil.exe" - OR -
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
An OR requires that one side of the expression is
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.
next post we're going to have a crash course in writing IOC
definitions using the Mandiant IOC editor, IOCe.
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
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
Configuring Web History Data Collection
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
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 Networktab. 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 Parametersfrom 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.
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, whichwill 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
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
Figure 3: Displaying your web history
data for review in both Web Historian (behind) and Redline
Although similar, Redline does have a few minor
differences in how it visualizes your data:
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
Searching and simple filtering is done in each
individual table view and is not applied globally. To access the
findoptions, either press the magnifying glass in the
bottom right corner, or press Ctrl-f while a table view is
To export your data to a CSV (comma separated
values) format file, click on exportin 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.
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.
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.
Indicators of Compromise (IOCs) as a quick way to determine if
your system contains any potential security breaches or other
evidence of compromise. Visit http://www.openioc.org/ to
learn more about IOCs.
Last but not least, Redline gives
you the ability to examine an entire system worth of metadata.
With Redline, you are not simply restricted to Web History related
data; you can investigate security incidents with the scope and
context of the full system.
If your favorite feature
from Web Historian has not yet been included in Redline (Graphing,
Complex Filtering, etc.), feel free to make a request using one of
the contact methods specified below. We will be taking feedback into
consideration when choosing what the Redline team works on in the
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.
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
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.
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
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
Investigating with Indicators of Compromise (IOCs)
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.
have several goals for this series:
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
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
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.
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
Mandiant Redline™ Presented by Theodore (Ted) Wilson Thursday, August 1 12:45 - 3:15 PM Station
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™
- Streamline memory analysis with a proven workflow
for analyzing malware based on relative priority.
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
OWASP Broken Web Presented by Chuck Willis Thursday, August 1 12:45 - 3:15 PM Station
The Open Web Application Security Project (OWASP)
Broken Web Applications project (www.owaspbwa.org) 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
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
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
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
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
Can Redline collection be run on a remote machine?
Redline does not itself support remote collection. We recommend
Intelligent Response® if you would like centralized
remote collection of your hosts' data over an enterprise sized
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?
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
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
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?
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?
runs as a batch script via the command line, but the analysis and
visualization portions are only available through the graphical user
Are you limited to the types of variants/intrusions you can scan
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
Can you tell if the attacker has manipulated the time stamps of
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
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
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
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
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 "RAR.EXE-12F2DC4F.pf". 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
In this case, we will conduct a search for
"Rar!" in unallocated space and find a section of the disk
that looks especially interesting.
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.
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.
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!
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.
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.
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
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.
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.
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
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.
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.
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
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
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
Shim Cache Parser is the proof-of-concept tool we
developed to extract this useful forensic evidence. You can download
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.
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
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 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
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
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
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.
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
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.
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.
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.
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
10/19/2012 08:56 PM 592,829
mir.w32eventlogs.771e480e.xml.txt 10/19/2012 09:00 PM
10/19/2012 09:01 PM 301,325
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
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
C:Documents and SettingsUserDesktopAuditParser>python
AuditParser.py -i ..LR_Collection -o ..Processed_Audits ed
-t --starttime 2012-10-18T00:00:00Z --endtime
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
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
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
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
On today's podcast, Kristen Cooper talks with Lucas Zaichkowsky on
the latest version of Redline, a free tool from Mandiant.
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
To listen to the full podcast and learn more about
Redline click here.
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
Indicators of Compromise (IOCs) and generate a report of
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
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.
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
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
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
Audit Parser is written in Python and is
distributed under the Apache License. It requires the lxml (http://lxml.de/) 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: https://github.com/mandiant/AuditParser
If you have any questions or comments, feel free to leave them
below, e-mail me (ryan [dot] kazanciyan [at] mandiant.com), 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!
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
If you are not familiar with IOCs, I urge to
you take a moment and head over to http://OpenIOC.org and have a look
around. IOCs are the best way for finding indications of compromise
and/or intrusion throughout your enterprise. IOCs are one of the
main technologies that power Mandiant Intelligent Response,
Mandiant's flagship IR appliance, and have previously been
accessible in free products with IOC
Editor & IOC
Finder. Some blog entries that might help bring you up to speed
are Ryan Kazanciyan's recent post on using Redline for investigation
and to create an IOC, and Carrie Jung's post on investigations into
the Duqu worm, including looking at Duqu with Redline and
creating an IOC
to help you find Duqu.
Previously, if you wanted to
look for an IOC, you would create an IOC using IOC
Editor, and then collect data from a host using IOC Finder. As
an additional step, you would run a match against that data and
generate a report using IOC Finder in a different configuration.
With the latest release of Redline you will still start making your
IOC in the Editor, but you can collect the data from a host and
match against it in a much simpler manner.
When you first
fire up the latest version of Redline with IOC support (Version 1.5)
you will see options that look very similar to previous
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
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
Following the prompt "Choose an Indicator from the list on
the left to see full details," if you click on one of the
Indicator Names, you will see information about that Indicator. If
you want to use only one Indicator, or a specific subset of the
Indicators in your IOC directory, click the check box at the top
next to Name, and then select the specific Indicator(s) that you
want to use by checking just those checkboxes:
So, what if you are new to this? What if you do not have any IOCs
on hand? Well, as a shortcut, you can go to http://openioc.org/ and grab a few
sample ones that we have available. Ideally, you will eventually
build your own IOCs from the investigation data that you discover,
but these samples will help you get started for learning purposes.
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.
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
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).
can watch it run, but likely you will want to go do something else
and come back a bit later, since for any decent sized collection of
IOCs it is going to take a while, unless you are doing a very small
IOC or very simple IOCs. For the sample IOCs on http://openioc.org/ it took around
two hours on a Windows 7 VM with 2 Gigs of RAM allocated. Faster
machines with more resources are going to usually run faster, with
Disk I/O being the main bottleneck, along with Processor. RAM is
less of an issue. If you want to have things run faster, you can
also try using the Portable Agent version of Redline. We will cover
that more next week in an upcoming post on Redline Pro Tips.
Once you have the items you need, you can look through the
results of the audit data gathered as you would a normal Redline
analysis -- but you will notice another task running - "Redline
is Creating an IOC Report," matching the audit data against
IOCs just like IOC Finder would have -- but with no need to run any
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.
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 OpenIOC.org website. Will Gibb and I
will also be doing a webinar, Fresh Prints of
Mal-ware: IOCing Red, on Thursday, April 19 on IOCs and
Redline where we will discuss writing a real world IOC from an
investigation. We hope you can tune in!
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
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
Get the data that matters, and do it faster
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
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
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
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
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.