Managed Defense: The Analytical MindsetWhen it comes to cyber security (managed services or otherwise),
you’re ultimately reliant on analyst expertise to keep your
environment safe. Products and intelligence are necessary pieces of
the security puzzle to generate detection signal and whittle down the
alert chaff, but in the end, an analyst’s trained eyes and
investigative process are the deciding factors in effectively going
from alerts to answers in your organization.
This blog post highlights the events of a recent investigation by href="https://www.fireeye.com/solutions/managed-defense.html">FireEye
Managed Defense to showcase the investigative tooling and
analysis process of our analysts.
Threat Overview
Recently, FireEye Managed Defense responded to a suspected
China-nexus threat group campaign targeting the transportation,
construction, and media sectors in Southeast Asia. FireEye’s
investigative findings uncovered previously unseen malware, DUOBEAN, a
backdoor that solicits additional modules from command-and-control
(C2) infrastructure and injects them into process memory.
Initial Lead
Our initial lead for this activity originated from threat hunting in
Managed Defense, which identified a ZIP archive containing a malicious
LNK file with embedded PowerShell commands to download and inject a
malicious payload into victim process memory. The attachment was
blocked by a FireEye ETP appliance in Southeast Asia, but network
indicators for the payload were extracted for monitoring suspicious infrastructure.
When IP addresses are tasked for monitoring, our network sensors
record traffic observed to the suspicious destination for further
analysis by our Managed Defense team during threat hunting activities.
When new leads from monitored traffic have been collected, our
analysts use an internal tool, MDASH, as a dashboard for exploring
suspicious network activity.
Analyst Perspective
With mountains of evidence available from endpoint telemetry and
network traffic, it’s critical to interrogate artifacts with
purposeful lines of questioning in order to respond to threat actor
activity as effectively as possible without getting lost in the data.
In this engagement, we have the initial lead for DUOBEAN activity
being a tracked IP address that has generated a lead for hunting.
Given this type of evidence, there’s a few questions we’re interested
in answering before looking at the PCAP contents.
Why did we start monitoring this indicator?
The most important action an analyst can take when evaluating any
indicator is understanding what it is trying to detect. For FireEye,
the monitored network infrastructure is commented by the author to
provide necessary context for analysts that review generated leads.
In this case, our team identified that a recent sample of CHAINLNK
from a blocked ETP attachment in Southeast Asia beaconed to
infrastructure serving the same SSL certificate. Related
infrastructure reusing SSL certificates were enumerated when a
malicious domain was gathered from the payload and scoped using
PassiveTotal to identify SSL certificates associated with the IP.
Certificate SHA-1 was then searched against PassiveTotal results to
identify an additional network asset serving the same certificate.
This overlapping certificate use is illustrated in Figure 1.
src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/analyticalmindset/Picture1.png" alt="" />
Figure 1: Suspicious infrastructure
observed in hunting activity
How long have we been tracking this IP Address?
IP addresses can be some of the most volatile indicators in the
world of security. The operational cost for an attacker to transition
infrastructure is nominal, so the accuracy of the indicator will
decrease as time marches on.
In this instance, the IP address had only been monitored for seven
(7) days which increased the credibility of the indicator given the
relative freshness.
What’s the prevalence of this activity?
Prevalence of traffic to an IP address gives us a baseline for
normalcy. Large volumes of traffic from multiple varying hosts in
multiple organizations changes our frame of reference to be less
suspicious about the activity, while traffic from a few consistent
internal hosts at one or few clients would be more consistent with
targeted attacker activity.
In this engagement, we observed six (6) hosts from one organization
making consistent HTTPS requests (without response) to the
infrastructure. This limited scope would be consistent with more
suspicious activity.
How frequently is activity being observed?
Frequency of traffic informs an analyst of whether the activity is
programmatic or interactive. Identical activity at consistent
intervals is not something humans can easily replicate. Although
malware regularly uses variable lengths of time for beaconing,
consistent outbound requests in cadence are telling us that some
programmatic task is occurring to generate the activity, not a user session.
In this engagement, we observed outbound traffic occurring from all
six (6) hosts at 15 minute intervals which was indicative of
programmatic activity initiating the requests.
How much information is being passed between these hosts?
Strictly looking at netflow information, the byte size and
directionality of the traffic will also inform your analysis on what
you’re observing. Small consistently sized outbound packets tends to
be more representative of beaconing traffic (legitimate or otherwise),
while varied request/response sizes with frequency communication
suggests interactivity.
In this engagement, we observed only a few bytes of outbound traffic
on each of the hosts, consistent with beaconing.
Without looking at the packets, our line of questioning against the
flow data already begins to characterize the content as highly
suspicious. Looking at the network capture content (Figure 2), we
observe that the outbound traffic gathered is strictly TLS Client
Hello traffic to a free domain, which are commonly employed by attackers.
src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/analyticalmindset/Picture2.png" alt="" />
Figure 2: TLS Client Hello from packet capture
Given the findings from the hunting investigation, the Managed
Defense team immediately informed the customer that further endpoint
analysis was going to be performed on the six (6) host communicating
with the suspicious infrastructure. At the time, the customer was not
instrumented with FireEye Endpoint Security, so portable collections
were captured for each of the hosts and securely uploaded to the
Managed Defense team for analysis.
Further Analysis
Endpoint collections containing Windows file system metadata,
Windows Registry, Windows Event Logs, web browser history, and a
process listing with active network connections were gathered for
Managed Defense analysts.
Windows Event Logs by themselves can have hundreds of thousands if
not millions of entries. As an analyst, it’s increasingly important to
be specific in what questions you’re looking to answer during endpoint
investigations. In this case, we have one leading question to begin
our investigation: What application is regularly communicating with
our suspicious infrastructure?
Active network connections indicated that legitimate Windows binary,
“msiexec.exe”, was responsible for the network connection to the
suspicious infrastructure. This information was also included in
detailed process tracking evidence (EID 4688) from Windows Event Logs
listed in Figure 3.
src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/analyticalmindset/Picture3.png" alt="" />
Figure 3: Windows Event Log detailing
suspicious use of “msiexec.exe”
The legitimate application “msiexec.exe”, is responsible for
command-line installation and modification of Windows Installer
applications (*.msi files), and rarely makes network connections. From
an analyst’s perspective, the low occurrence of network activity in
standard use from this binary elicits suspicions of process injection.
The parent process in this instance is also in a minimally privileged
%AppData%\Roaming directory commonly used for malware persistence.
As an analyst, we’re confident at this point that malicious activity
is occurring on the host. Our line of questioning now transitions from
exploring the source of network traffic to discovering the scope of
the compromise on the host. To triage, we will use the following line
of questioning:
What is it?
For this question, we’re interested in understanding the attacker
behavior on the victim computer, specifically the malware in this
investigation. This includes functionality and persistence mechanisms used.
With our initial lead being the potential staging directory of
%AppData%\Roaming from the Windows Event Log listing, we’ll first look
at any files created within a few minutes of “eeclnt.exe”. A Mandiant
Redline listing of the files returned from filtering the directory is
shown in Figure 4.
src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/analyticalmindset/Picture4.png" alt="" />
Figure 4: Mandiant Redline file listing
from potential staging directory, %Appdata%\Roaming
Three (3) suspicious files in question are returned “eeclnt.exe”,
“MSVCR110.dll”, and “MSVCR110.dat”. These files are uploaded to the
FLARE team’s internal malware sandbox, Horizon, for further analysis.
PE File information indicates that “eeclnt.exe” is a legitimate copy
of the ESET Smart Security binary with a required import of
“MSVCR110.dll”. “MSVCR110.dll” supplementary library required for
applications developed with Microsoft Visual C++. In this case,
“MSVCR110.dll” was replaced with a malicious loader DLL. When
“eeclnt.exe” executes, it imports the malicious DLL “MSVCR110.dll”,
which loads the backdoor contained in “MSVCR110.dat” into
“msiexec.exe” process memory through process hollowing. This technique
is called “sideloading” and is commonly used by attackers to evade
detection by using legitimate executables to run malicious code.
After initial triage from a Managed Defense analyst, the backdoor
was passed along to our FLARE team to reverse engineer for additional
identification of malware functionality and family identification. In
this case, the backdoor was previously unseen so the Managed Defense
analyst who identified the malware named it DUOBEAN.
How does it persist?
On Windows hosts, malware normally persists in one of three ways:
Registry “Run” keys that run a specific application anytime a specific
user (in some cases any user) authenticate into the workstation.
Windows Services, long-standing background processes typically started
at machine boot; and scheduled tasks that run an arbitrary command or
binary at a designated interval.
In this case, by filtering for the sideloaded binary, “eeclnt.exe”,
we quickly identified a Windows Service, “Software Update”, created
around the file creation timestamp that maintained persistence for the
DUOBEAN backdoor.
How did it get there?
This can be one of the more challenging questions to answer in the
investigative world. With limited data retention times and rolling log
data, the initial vector is not always easily discerned.
In this case, pivoting to look at browser history and file system
modification around the time the DUOBEAN backdoor was created on the
victim endpoint led us to our answers. Mandiant Redline output to
detail the timeline of initial compromise is displayed in Figure 5.
src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/analyticalmindset/Picture5.png" alt="" />
Figure 5: Mandiant Redline output
containing the host initial compromise timeline
The timeline of events shows that the user was phished from their
personal Gmail, opening the password protected CHAINLNK attachment
delivered from a OneDrive link embedded in the email. Malicious
PowerShell commands observed from Windows Event Logs contained in
Figure 6 following the activity indicate that CHAINLNK successfully
executed and downloaded DUOBEAN.
src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/analyticalmindset/Picture6.png" alt="" />
Figure 6: Malicious CHAINLNK PowerShell
commands observed in Windows Event Logs
No further activity was identified from this host based on the
investigative evidence provided, and Managed Defense continued to
scope the environment for additional indicators of compromise. This
specific threat actor was detected early in the attack lifecycle which
limited the impact of the threat actor and enabled Managed Defense to
guide the victim organization through a quick remediation.
Summary
The China-nexus threat actor activity detailed above expanded to
multiple customers, and eventually escalated to a Managed Defense
Community Protection Event (CPE). CPEs are rapidly progressing
campaigns targeting multiple customers with substantial potential for
business impact. Managed Defense customers are immediately notified of
CPE activity, indicators are deployed to monitor customer products,
and the Managed Defense Consulting team provides insight on how to
mitigate risk.
Regardless of the scale of your investigation, time is of the
essence. Drowning under investigative data without a clear line of
questioning buys attackers additional time to impose their agenda on
your organization. Remember, products and intelligence are components
of your security practice, but expertise is required in order to
transform those inputs into an effective response.
Source:
Managed Defense: The Analytical Mindset
