sechub.in Open in urlscan Pro
2606:4700:3031::ac43:d67c Public Scan

Back to summary

URL:
https://sechub.in/view/2158455
Submission: On December 18 via api (December 18th 2024, 8:06:35 am UTC) from US — Scanned from DE

Form analysis
0 forms found in the DOM

Text Content

Sechub
* 首页

历史
投稿

OPENIOC SERIES: INVESTIGATING WITH INDICATORS OF COMPROMISE (IOCS) – PART I

Threat Research 2020-07-24 08:03:11 indicators of compromise · mandiant · will
gibb
收藏

Written by Devon Kerr & Will Gibb

The Back to Basics: OpenIOC blog series previously discussed how Indicators of
Compromise (IOCs) can be used to codify information about malware or utilities
and describe an attacker's methodology. Also touched on were the parts of an
IOC, such as the metadata, references, and definition sections. This blog post
will focus on writing IOCs by providing a common investigation scenario,
following along with an incident response team as they investigate a compromise
and assemble IOCs.

Our scenario involves a fictional organization, "Acme Widgets Co.", which
designs, manufactures and distributes widgets. Last week, this organization held
a mandatory security-awareness training that provided attendees with an overview
of common security topics including password strength, safe browsing habits,
email phishing and the risks of social media. During the section on phishing,
one employee expressed concern that he may have been phished recently. Bob
Bobson, an administrator, indicated that some time back he'd received a strange
email about a competitor's widget and was surprised that the PDF attachment
wouldn't open. A member of the security operations staff, John Johnson, was
present during the seminar and quickly initiated an investigation of Bob's
system using the Mandiant Redline™ host investigation tool. John used Redline to
create a portable collectors configured to obtain live response data from Bob's
system which included file system metadata, the contents of the registry, event
logs, web browser history, as well as service information.

John ran the collectors on Bob's system and brought the data back to his
analysis workstation for review. Through discussions with Bob, John learned that
the suspicious e-mail likely arrived on October 13, 2013.

After initial review of the evidence, John assembled the following timeline of
suspicious activity on the system.

Table 1: Summary of significant artifacts

Based on this analysis, John pieced together a preliminary narrative: The
attacker sent a spear-phishing email to Bob which contained a malicious PDF
attachment, "Ultrawidget.pdf", which Bob saved to the desktop on October 10,
2013, at 20:19:07 UTC. Approximately five minutes later, at 20:24:44 UTC, the
file "C:WINDOWSSysWOW64acmCleanup.exe" was created as well as a Run key used for
persistence. These events were likely the result of Bob opening the PDF. John
sent the PDF to a malware analyst to determine the nature of the exploit used to
infect Bob's PC.

The first IOC John writes describes the malware identified on Bob's PC,
"acmCleanup.exe", as well as the malicious PDF. IOCs sometimes start out as
rudimentary - looking for the known file hashes, filenames and persistence
mechanisms of the malware identified. Here is what an initial IOC looks like:

Figure 1: Initial IOC for acmCleanup.exe (BACKDOOR)

As analysis continues, these IOCs are updated and improved - incorporating
indicator terms from malware and intelligence analysis as well as being refined
based on the environment. In this sense, the IOC is a living document. For
example, additional analysis may reveal more registry key information,
additional files which may be written to disk, or information for identifying
the malware in memory. Here is the same IOC, after augmenting it with the
results of malware analysis:

Figure 2: Augmented IOC for acmCleanup.exe (BACKDOOR)

The augmented IOC will continue to identify the exact malware discovered on
Bob's PC. This improved IOC will also identify malware which has things in
common with that backdoor:

* Malware which uses the same Mutex, a process attribute that will prevent the
machine from being infected multiple times with the same backdoor
* Malware which performs DNS queries for the malicious domain "23vsx.evil.com"
* Malware which has a specific set of import functions; in this case which
correspond to reverse shell and keylogger functionality

Beginning on October 11, the attacker accessed the system and executed the
Windows command "ipconfig" at 20:24:00 UTC, resulting in the creation of a
prefetch file. Approximately five minutes later, the attacker began uploading
files to "C:$RECYCLE.BIN". Based on review of their MD5 hashes, three files
("wce.exe", "getlsasrvaddr.exe", "update.exe") were identified as known
credential dumping utilities while others ("filewalk32.exe", "rar.exe") were
tools for performing file system searches and creating WinRAR archives. These
items should be recorded in an IOC, as a representation of an attacker's tools,
techniques and procedures (TTPs). It is important to know that an attacker is
likely to have interacted with many more systems than were infected with
malware; for this reason it is crucial to look for evidence that an attacker has
accessed systems. Some of the most common activities attackers perform on these
systems include password-dumping, reconnaissance and data theft.

Seeing that the attacker had staged file archives and utilities in the
"$Recycle.Bin" folder, John also created an IOC to find artifacts present there.
This IOC was designed to identify files in the root of the "$Recycle.Bin"
directory; or to identify if a user (notably, the attacker) tried to access the
"$Recycle.Bin" folder by manually typing it in the address bar of Explorer by
checking TypedPaths in the Registry. This is an example of encapsulating an
attacker's TTPs in an OpenIOC form.

Figure 3: IOC for Unusual Files in "C:RECYCLER" and "C:$RECYCLE.BIN"
(Methodology)

On October 15, 2013, at 12:15:37 UTC, the Sysinternals PsExec utility was
created in "C:$RECYCLE.BIN". Approximately four hours later, at 16:11:03 UTC,
the attacker used the Internet Explorer browser to access text files located in
"C:$RECYCLE.BIN". Between 16:11:03 UTC and 16:11:06 UTC, the attacker accessed
two text files which were no longer present on the system. At 16:17:55 UTC, the
attacker mounted the remote hidden share "\10.20.30.101C$". At 16:20:29 UTC, the
attacker executed the Windows "tree" command, resulting in the creation of a
prefetch file, a command which produces a filesystem listing. At 17:37:37 UTC,
the attacker created one WinRAR archive, "C:$Recycle.Bina.rar" which contained
two text files, "c.txt" and "a.txt". These text files contained output from the
Windows "tree" and "ipconfig" commands. No further evidence was present on the
system. John noted that the earliest event log entries present on the system
start approximately two minutes after the creation of "a.rar". It is likely that
the attacker cleared the event logs before disconnecting from the system.

John identified the lateral movement to the 10.20.30.101 host, from "ACM-BOBBO"
through registry keys that recorded the mount of the hidden C$ share. By
recording this type of artifact in an IOC, John will be able to quickly see if
the attacker has pivoted to another part of the Acme Widgets Co. network when
investigating 10.20.30.101. He included artifacts looking for other common
hidden shares such as IPC$ and ADMIN$. The effectiveness of an IOC may be
influenced by the environment the IOC was created for. This IOC, for example,
may generate a significant number of false-positives in an environment where
these hidden shares are legitimately used. At Acme Widgets Co., however, the use
of hidden shares is considered highly suspicious.

Figure 4 IOC for Lateral Movement (Methodology)

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.

原始链接：
http://internal-www.fireeye.com/blog/threat-research/2013/12/openioc-series-investigating-indicators-compromise-iocs.html
侵权请联系站方： admin@sechub.in

sechub.in Open in urlscan Pro 2606:4700:3031::ac43:d67c Public Scan

Form analysis 0 forms found in the DOM

Text Content

sechub.in Open in urlscan Pro
2606:4700:3031::ac43:d67c Public Scan

Form analysis
0 forms found in the DOM