Process hollowing occurs when a legitimate process is targeted on a
system to act as a container for malicious logic. Attackers can either
target legitimately started user processes or even start their own
sacrificial process to hollow out.
It's important to be able to identify this activity as it will allow you
to recreate attacker timelines and gather a complete IOC list that can
be used to develop robust detection logic.
Our first demo looks at attacker privilege escalation techniques.
We're going to be focusing on process injection and further drilling
down into process hollowing. Process hollowing is frequently seen in
the wild by means of Cobalt Strike.
This is an incredibly popular remote access and command and
control tool that's post‑exploitation framework actually
employs all of the MITRE ATT&CK tactics.
However,
one of the most common uses for this tool is hollowing out a
sacrificial process in order to evade detection and perform
further actions on objectives.
Our second demo involves isolating a process dump with an autopsy to detect
those minor attack process injection techniques we just discussed. We will walk
through a memory capture with process hollowing and injection and identify key
indicators of compromise, or IOCs. Learning how to analyze memory dumps is
especially useful when you're dealing with memory‑based attacks or fileless or
memory‑resident malware.
Now that Volatility has had some time to run,
we can start taking a look at the output. If we expand the tree
under sample007.bin, we'll eventually see all of the Volatility
plugins that we ran and their output.
Let's take a look at the pstree output.
Now at this point you've likely narrowed down your suspect list to a
few key processes and aren't just blindly hoping to find process
hollowing evidence on a random memory dump.
In this case, we're going to assume that we've done some prior
investigating and have noted that LSASS was acting a little
suspect and warrants a further look.
In fact,
even within the pstree output here we see two instances of LSASS
spawned from some pretty abnormal processes.
So, where do we go from here?
The module malfind can be especially useful for confirming suspicions
of a malicious process or for identifying others that we may have
missed during our initial investigation.
Malfind, while a bit sensitive at times and with a tendency to generate some
false positives, will flag a process for one of two reasons.
First, it was marked as an executable with the
PAGE_EXECUTE_READWRITE flag, but doesn't have an associated MZ
header or a process is running with no mapped file on disk.
If we look at the malfind output for those LSASS processes,
we can see that they have an MZ header and were marked with the
PAGE_EXECUTE_READWRITE, so this leads us to believe that potentially this is a
process running with no mapped file on disk, which can be indicative of
process hollowing or process injection. At this point,
we've got pretty solid indication of some malicious
activity, or at the very least some processes that weren't
some additional offline analysis.
However, in true forensicator fashion,
we're going to take a look at another artifact that will provide some
additional evidence as to whether or not we're really dealing with process
hollowing and subsequent injection, and that is the ldrmodules plugin This
plugin has three columns we're going to focus on, the InLoad, InInt, and
InMem columns. For normal processes, we'd see True across the board here.
The only normal False occurrence should be for our
system process. For all others,
this can be indicative of a process running in memory
with no associated file on disk.
Once we find those pesky LSASS processes,
we can see that both have at least one False column and the combination
of these IOCs make a pretty solid case that these processes were hollowed
out and likely had malicious code injected.