Category Archives: Anti-Forensics

Sysmon doing lines

Posted on by

This is just an experiment I ran today to see if I could fool sysmon (or more specifically: any program that parses sysmon logs, or users viewing the sysmon logs in the Event Viewer) into doing an extra line, or two… .

What if…

…the command line of the spawn process (calculator in this case) looked like a part of the Event Log itself? Something along these lines :

calc

 CurrentDirectory: C:\non-existing\
 User: test-pc\user
 LogonGuid: {15a1393e-e37e-58de-0000-0020e0940300}
 LogonId: 0x394E0
 TerminalSessionId: 1
 IntegrityLevel: High
 Hashes: SHA1=2E391131F9B77A8EC0E0172113692F9E2CCCEAF0
 ParentProcessGuid: {15a1393e-97f2-59d2-0000-0010a4d8a500}
 ParentProcessId: 666
 ParentImage: C:\windows\system32\calc.exe

Obviously, you can’t run it from a command line, you need a program to run it for you using the CreateProcess API.

The result would be like this:

So… when the data is previewed, the user can (at least for a moment) believe the calc.exe was indeed spawn by the process ID 666 and parent process is calc.exe (which on its own is kinda difficult), and the current directory is c:\non-existing.

Programs exporting logs into CSV/TXT could get potentially fooled too as the injected data lines up with expected logs and a possible state machine parsing them could be fooled; one could potentially inject a number of such fake logs and potentially disturb the log parsing process and create some funny, non-existing process-tree scenario.

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!