You are browsing the archive for Anti-Forensics.

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!

Using RegisterApplicationRestart as a (lame) sandbox evasion

May 20, 2017 in Anti-Forensics, Forensic Analysis, Sandboxing

The RegisterApplicationRestart function allows the OS to relaunch the application in case it crashes, or fails for other reasons (or when an installer needs to restart the system and then launch again).

To avoid cyclical restarts the program needs to run for at least 60 seconds though.

So, imagine a program that does the following:

  • Check if a specific command line argument is provided
    • If yes
      • Run malware
    • If no
      • Register itself via RegisterApplicationRestart and provide a command line f.ex. /nosandbox
      • Sleep for 60 seconds using Sleep
      • Cause a crash (f.ex. divide by 0)

If the application is ran w/o a sandbox, it will be relaunched by the OS after the crash and with a /nosandbox argument – it will execute the malware.

If the application is ran under sandbox, the sandbox engine will most likely affect the running of the Sleep function. This in turn will disable the functionality of the RegisterApplicationRestart function. The program will run less than 60 seconds, hence won’t be restarted after the crash. The sandbox report will be pretty much empty.

Note, with its default settings, Windows 10 will simply restart the application:

For earlier versions, the user may be asked to choose whether they want to restart the application (depending on Windows Error Reporting settings). Notably, if such dialog  popped up while the sample was running inside the sandbox, there is a chance the sandbox would autoclick the ‘restart’ option for us. But then… well.. it would have to wait these 60 seconds first, wouldn’t it?

Bonus forensic information:

The less used option of RegisterApplicationRestart API is in conjunction with installers. If combined with ExitWindowsEx,EWX_RESTARTAPPS,… it will register the app to be executed by the systems with the next logon. The mechanism of this temporary persistence mechanism is quite interesting.

Right before the user is logged off the csrss.exe process registers a RunOnce entry located in the following location:

  • HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce\Application Restart #<NUMBER>

– it is simply pointing to the restarted application.

So, if you ever see entries like these:

  • HKCU\Software\Microsoft\Windows\
    CurrentVersion\RunOnce\Application Restart #0
  • HKCU\Software\Microsoft\Windows\
    CurrentVersion\RunOnce\Application Restart #1

etc.

– then it’s most likely a result of an unfinished installer business…

Could it become a persistence mechanism and become a part of the Beyond Good Ol’ Run key series? Perhaps, but I have not found a practical way to do it w/o restarting the system (perhaps aborting the restart could help, but from what I can tell the csrss.exe registers the RunOnce persistence mechanism pretty late).