Covering Your Tracks - Anti-forensics for Memory
No
matter what you do as a hacker, at some point you are going to traverse memory.
Computers can
almost be thought of as recording devices; anything a user does gets
recorded somewhere and memory is a good place to start forensic investigations.
This may sound like it is therefore impossible to completely avoid leaving a footprint
of some kind on a computer and while that may be true to at least some extent,
there are ways to avoid detection from memory acquisition tools. But before
understanding these methods it is first necessary to understand how these
memory acquisition tools work.
Volatility
is an open source framework written in python. It contains numerous plugins to
analyze a memory dump. Memory dumps can be obtained from tools such as AccessData
FTK Imager which is nothing more than loading the program and then choosing
File >> Capture Memory and then choosing where to save the .mem file. Once
the memory is acquisitioned it can be analyzed with volatility commands (volatility
is a command line tool) such as (Davis, 2017):
volatility
-f <memory_filename>.mem imageinfo
The
command above returns the operating system (suggested profiles) along with some
other system information such as the number of processors. Once the profile has
been obtained the running processes at the time of capture can be found with
the command (Davis, 2017):
volatility
-f <memory_filename>.mem --profile=<profile_name> psscan
The
results of this scan will likely show a couple processes of svchost.exe. This
is normal, however, a lot of malware will use svchost.exe to try and hide. Svchost
has a parent process of services.exe and if services.exe Pid differs from a the
svchost parent Pid (PPid), chances are svchost is malware. The executable for
this malware can then be dumped using the following command (Davis, 2017):
volatility
-f <memory_filename>.mem --profile=<profile_name> procdump -p 3960 --dump-dir=./
Volatility
will then return whether the process is malware or not. In the case that it is
malware the hash of the file can be obtained (e.g. the location of --dump-dir=./
or the current working directory) and uploaded to virus total to gain more
information:
memdump
in place of procdump dumps the code of the process instead of the executable
and can be used for analyzing the actual code of the process. Volatility can be
used for more than memory analysis; it can also use the netscan plugin to see
listening and established network connections (Davis, 2017).
While
it’s common for there to be numerous svchost.exe processes some processes such
as lsass.exe should only appear one. lsass stands for local security authority
subsystem service and handles authentication and passwords. If this process
becomes unstable then the computer will need to be re-booted (which may be
beneficial for malware avoiding forensics). Seeing a process like this twice is
also a good indicator that malware has infected the machine (Davis, 2017).
Avoiding
tools all together like volatility is possible. As may have already been
inferred earlier with the svchost.exe and its services.exe parent; injecting malware
into the services.exe is possible. If malware code injection is done right, it
may be able to avoid detection from anti-virus software and forensic analysts
using volatility. Process injection is having malware insert itself or code
into a process, very similar to how a virus infects a cell.
Other
methods exist for avoiding detection from memory forensic tools such as Kernel
debugger block hiding. The static kernel structure KdDebugBlock finds the base
address of a kernel image and can be found by scanning for the OwnerTag member
(a “KDBG” static string). Overwring the OwnerTag disrupts memory acquisition or
prevents it all together.
Memory
acquisition debuggers rely on symbols to read physical address space and these
symbols such as MmGetPhysicalMemoryRanges() can be patched to return NULL which
prevents debuggers from seeing the physical address space layout (Stuttgen
& Cohen, 2013). This requires some in-depth knowledge of assembly and the
operating system’s kernel. Demonstration is out of scope for this blog but an interesting
article on these techniques can be found in the link below:
Anti-memory
forensics is an advanced topic that requires knowledge of processes and their
innerworkings. Thankfully there is also an abundant amount of resources to
assist in learning about memory forensics. 13Cubed is an excellent YouTube
channel for learning about memory forensics with volatility as well as other
forensic techniques such as exploring the registry.
Another
great resource for practicing memory forensics with volatility is the Memory Samples
that volatility provides. These are memory dumps of malware such as the famous Stuxnet
which can be downloaded and then loaded into volatility via the link below:
In
closing, while it may be impossible to avoid leaving a footprint of some kind
on a computer, methods can be used to make a forensic analyst’s work hard.
Techniques also exist where malware to crash debuggers such as volatility.
Additionally, malware can hide in locations such as the BIOS making detection
even more difficult. These techniques are advanced and normally if a well-crafted
exploit such as this is discovered; it may be a nation-state attack of some
kind. That make this topic all the very cool and is why everyone should
download a kali linux or Parrot OS distro and download the Memory Samples above
to learn more. Happy hacking!
References
Davis,
R. (2017, May 25). Introduction to Memory Forensics [Video file].
Retrieved from
https://www.youtube.com/watch?v=1PAGcPJFwbE
Stuttgen,
J. & Cohen, M. (2013). Anti-forensic resilient memory acquisition.
Retrieved from
https://reader.elsevier.com/reader/sd/pii/S1742287613000583?token=765FF84F83827C8BB93C43AE83292A4E2FFB484034C301EB19F83291B1C809BE70B6EBDBE0C5098346F2C4E1F73DAC1A
Comments
Post a Comment