Beyond good ol’ Run key, Part 64

Posted on by

I recently updated my ‘collect all cool persistence mechanism described elsewhere’ post. After I announced it on Twitter, 3gstudent replied with one more link – one that led to his demo of persistence via bitsadmin. I looked at BITS before, but it never occurred to me to look at all command line options of the bitsadmin tool – the fact it allows persistence was a nice surprise. It intrigued me that it was not recognized by autoruns.

I immediately tested the mechanism on a Win7 VM and quickly discovered that the BITS stores info about tasks inside the following location:

  • c:\ProgramData\Microsoft\Network\Downloader\qmgr0.dat
  • c:\ProgramData\Microsoft\Network\Downloader\qmgr1.dat

Sometimes you may find also qmgr0.bak & qmgr1.bak files there.

I have ran a test adding as many tasks as possible and noticed that the only visible difference is growth of the file size of both files. After the first test the files on my system were around 4MiB (Win7). Adding new tasks eventually made BITS run out of space – at that time it simply extends the file.

Googling around for these file names doesn’t provide that much info. The format of the file is unknown – some serialized data.

One thing is sure though –  if you come across these during the exam, you should defo look at possible BITS persistence.

If memory doesn’t serve me right…

Posted on by

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!