Written by Devon Kerr & Will Gibb
The target="_blank"
href="https://www.mandiant.com/blog/basics-series-openioc/">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 target="_blank"
href="/content/fireeye-www/en_US/services/freeware/redline.html">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.
href="https://www.fireeye.com/content/dam/legacy/ammo/Table-1-Summary-of-significant-artifacts.jpg">
width="746" height="500"
src="https://www.fireeye.com/content/dam/legacy/ammo/Table-1-Summary-of-significant-artifacts.jpg"
class=" wp-image-5403 " />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:
href="https://www.fireeye.com/content/dam/legacy/ammo/Figure-1-Initial-IOC-for-acmCleanup.exe-BACKDOOR.png">
width="549" height="163"
src="https://www.fireeye.com/content/dam/legacy/ammo/Figure-1-Initial-IOC-for-acmCleanup.exe-BACKDOOR.png"
class="size-full wp-image-5402" />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:
href="https://www.fireeye.com/content/dam/legacy/ammo/Figure-2-Augmented-IOC-for-acmCleanup.exe-BACKDOOR.png">
width="544" height="462"
src="https://www.fireeye.com/content/dam/legacy/ammo/Figure-2-Augmented-IOC-for-acmCleanup.exe-BACKDOOR.png"
class="size-full wp-image-5401" />Figure 2: Augmented IOC for
acmCleanup.exe (BACKDOOR)
The augmented IOC will continue to
identify the exact malware discovered on Bob's PC. This improved IOC
will also identify malware which has things in common with that
backdoor:
- Malware which uses the same Mutex, a process
attribute that will prevent the machine from being infected
multiple times with the same backdoor - Malware which
performs DNS queries for the malicious domain
"23vsx.evil.com" - Malware which has a specific set
of import functions; in this case which correspond to reverse
shell and keylogger functionality
Beginning on
October 11, the attacker accessed the system and executed the
Windows command "ipconfig" at 20:24:00 UTC, resulting in
the creation of a prefetch file. Approximately five minutes later,
the attacker began uploading files to "C:$RECYCLE.BIN".
Based on review of their MD5 hashes, three files
("wce.exe", "getlsasrvaddr.exe",
"update.exe") were identified as known credential dumping
utilities while others ("filewalk32.exe",
"rar.exe") were tools for performing file system searches
and creating WinRAR archives. These items should be recorded in an
IOC, as a representation of an attacker's tools, techniques and
procedures (TTPs). It is important to know that an attacker is
likely to have interacted with many more systems than were infected
with malware; for this reason it is crucial to look for evidence
that an attacker has accessed systems. Some of the most common
activities attackers perform on these systems include
password-dumping, reconnaissance and data theft.
Seeing that
the attacker had staged file archives and utilities in the
"$Recycle.Bin" folder, John also created an IOC to find
artifacts present there. This IOC was designed to identify files in
the root of the "$Recycle.Bin" directory; or to identify
if a user (notably, the attacker) tried to access the
"$Recycle.Bin" folder by manually typing it in the address
bar of Explorer by checking TypedPaths in the Registry. This is an
example of encapsulating an attacker's TTPs in an OpenIOC form.
href="https://www.fireeye.com/content/dam/legacy/ammo/Figure-34.png">
width="357" height="281"
src="https://www.fireeye.com/content/dam/legacy/ammo/Figure-34.png"
class="size-full wp-image-5400" />Figure 3: IOC for Unusual Files
in "C:RECYCLER" and "C:$RECYCLE.BIN"
(Methodology)
On October 15, 2013, at 12:15:37 UTC, the
Sysinternals PsExec utility was created in
"C:$RECYCLE.BIN". Approximately four hours later, at
16:11:03 UTC, the attacker used the Internet Explorer browser to
access text files located in "C:$RECYCLE.BIN". Between
16:11:03 UTC and 16:11:06 UTC, the attacker accessed two text files
which were no longer present on the system. At 16:17:55 UTC, the
attacker mounted the remote hidden share
"\10.20.30.101C$". At 16:20:29 UTC, the attacker executed
the Windows "tree" command, resulting in the creation of a
prefetch file, a command which produces a filesystem listing. At
17:37:37 UTC, the attacker created one WinRAR archive,
"C:$Recycle.Bina.rar" which contained two text files,
"c.txt" and "a.txt". These text files contained
output from the Windows "tree" and "ipconfig"
commands. No further evidence was present on the system. John noted
that the earliest event log entries present on the system start
approximately two minutes after the creation of "a.rar".
It is likely that the attacker cleared the event logs before
disconnecting from the system.
John identified the lateral
movement to the 10.20.30.101 host, from "ACM-BOBBO"
through registry keys that recorded the mount of the hidden C$
share. By recording this type of artifact in an IOC, John will be
able to quickly see if the attacker has pivoted to another part of
the Acme Widgets Co. network when investigating 10.20.30.101. He
included artifacts looking for other common hidden shares such as
IPC$ and ADMIN$. The effectiveness of an IOC may be influenced by
the environment the IOC was created for. This IOC, for example, may
generate a significant number of false-positives in an environment
where these hidden shares are legitimately used. At Acme Widgets
Co., however, the use of hidden shares is considered highly
suspicious.
href="https://www.fireeye.com/content/dam/legacy/ammo/Figure-4-IOC-for-Lateral-Movement-Methodology-2.png">
width="360" height="120"
src="https://www.fireeye.com/content/dam/legacy/ammo/Figure-4-IOC-for-Lateral-Movement-Methodology-2.png"
alt="Figure 4 IOC for Lateral Movement (Methodology)"
class="size-full wp-image-5418" />Figure 4 IOC for Lateral
Movement (Methodology)
At the end of the day, John authored three
new IOCs based on his current investigation. He knows that if he
records the artifacts he identified from his investigation into the
"ACM-BOBBO" system, he can apply that knowledge to the
investigation of the host at 10.20.30.101. Once he collects
information on 10.20.30.101 with his Redline portable collector,
he'll be able to match IOCs against the Live Response data, which
will let him identify known artifacts quickly prior to beginning
Live Response analysis. Although John is using these IOCs to search
systems individually, these same IOCs could be used to search for
evidence of attacker activity across the enterprise. Armed with this
set of IOCs, John sets out to hunt for evil on the host at
"10.20.30.101".
Stay tuned for our next blog post,
seeing how this investigation develops.
