If memory doesn’t serve me right…

July 10, 2017 in Anti-*, Anti-Forensics, Forensic Analysis

Update

One more item from @JamesHabben:

  • One situation I frequently face is determining IIV for malware from months to years before. Memory analysis is useless for that.

Old post

I love memory forensics. So do you.

This is why you gonna hate me 😉

In a quick post on Twitter, @MalwareJake asked:

Memory forensics cuts through the lies of code injection and rootkits

Yes or no?

I replied:

Most of the time: yes. BUT lots of examples for: No

I thought it will be an interesting task to brainstorm&braindump these examples in one place and by doing so, find an excuse to look at the limitations of memory forensics. I am far from being the first one to talk about it, but it’s worth rehashing old ideas every once in a while…

So, without further ado, here’s a brain-dump of ‘malicious’ ideas that memory forensics will not help with, or will find at least challenging:

  • We must start with the well-known examples of Shadow Walker [PDF warning] and Blue Pill rootkits of course
  • “One-bit” modifications f.ex. enabling a debug/verbose flag in a software resulting in local data leaks – hard to detect
  • Same goes for small changes to configs – slightly modified path or server name can easily stay under radar
  • Modification of scrips, batch files, any sort of interpreted code (and in particular, any server-side code) – especially if it doesn’t run in a context of a typical windows user (f.ex. a line added to a task running on server that is responsible for batch-processing could simply copy files from a local system to a pwned share elsewhere)
  • Unusual, but temporary persistence mechanisms allowing to load malware w/o many side effects and malware exiting as soon as possible (not persistent in memory) f.ex. Hot Keys trick (granted, you may see zombie processes though)
  • Small, in-place, viral modification of files (and especially EPO modifications), in particular OS files, but could be any file that is executed on regular basis (especially DLLs)
  • .NET rootkits & any sort of .NET modification (imho still under-explored areas)
  • Shadow-Wakerish Rootkit that intercepts access to a physical memory device and ‘cleans’ memory content on the fly, removing its code and related artifacts
  • Watchdog could wipe the code out when the memory dumping tool is loaded – by monitoring file, registry key/service creation or known detecting known mutexes etc. f.ex.:
    • Comae DumpIt // 32 and 64-bit
      • DumpIt
      • HKLM\SYSTEM\CurrentControlSet\Services\DumpIt
      • %SYSTEM%\Drivers\DumpIt.sys
    • MoonSols Windd
      • 32-bit
        • win32dd
        • HKLM\SYSTEM\CurrentControlSet\Services\win32dd
      • 64-bit
        • win64dd
        • HKLM\SYSTEM\CurrentControlSet\Services\win64dd
    • HBGary FastDump
      • 32-bit
        • fastdumpx86
        • HKLM\SYSTEM\CurrentControlSet\Services\fastdumpx86
      • 64-bit
        • fastdumpx64
        • HKLM\SYSTEM\CurrentControlSet\Services\fastdumpx64
    • Encase
      • 32-bit
        • winen_
        • HKLM\SYSTEM\CurrentControlSet\Services\winen_
      • 64-bit
        • winen64_
        • HKLM\SYSTEM\CurrentControlSet\Services\winen64_
    • FTK Imager // 32- and 64-bit
      • Memory
        • AccessData Driver
        • %TEMP%\ad_driver.sys
        • HKLM\SYSTEM\CurrentControlSet\Services\ad_driver
      • Filesystem driver
        • FRIdrv
        • %SYSTEM%\Drivers\FRIdrv.sys
        • HKLM\SYSTEM\CurrentControlSet\Services\FRIdrv
    • Rekall’s pmem
      • pmem
      • %TEMP%\pme*.tmp
      • HKLM\SYSTEM\CurrentControlSet\Services\pmem
    • Memoryze
      • Mandiant_Tools
      • HKLM\SYSTEM\CurrentControlSet\Services\Mandiant_Tools
    • Redline
      • FeKern
      • %SYSTEM%\Drivers\FeKern.sys
      • HKLM\SYSTEM\CurrentControlSet\Services\FeKern
      • C:\Program Files\Redline\
    • (OLD!!!) MDD
      • ManTech MemDd Device Driver
      • HKLM\SYSTEM\CurrentControlSet\Services\mdd
    • (OLD!!!) Physmem
      • HKCU\Software\Sysinternals\Physmem

Additionally, one could try to open (using CreateFile) the devices created by these services, or simply look for process names associated with these tools. The memory dumping process takes a while and if malware checks every second or so, it is enough to detect the acquisition in progress…

I guess it’s obvious now that using fixed / hard-coded names in these tools is not a good idea. For this very reason old rootkit detection tools like RKU and GMER use randomized device names for nearly 10 years or so.

Last, but not least – this post is not to bash the memory forensics. It’s one of the most important tools we have in our arsenal. However, it’s important to know that it’s just one of the tools and under some circumstances we may simply need to use different approach.

Some references – far more advanced ideas and techniques:

If you know other artifacts related to memory acquisition tools, or have other anti-memory forensics ideas please let me know, thanks!

Share this :)

Comments are closed.