1. Defeating Windows
memory forensics
FSEC 2012
September 19, 2012.
Luka Milković
Luka.Milkovic@infigo.hr
INFIGO IS http://www.infigo.hr

2. Agenda
Memory forensics
Why?
How?
Previous memory anti-forensic techniques
Windows related
Memory acquisition process – flawed by
design?
Defeating Windows memory forensics
Impossible in user-mode…
…or not?
Possible solutions

3. Memory forensics – why?
Disk forensics prevalent, but memory
forensics increasingly popular
Used by incident handlers…
Malware detection
objects hidden by rootkits (processes, threads, etc.)
memory-resident malware
unpacked/unencrypted images
Recently used files
„Dead objects”
terminated processes, threads, connections…
… and the bad guys
Password recovery

4. Memory forensics – how?
Two consecutive processes
Memory acquisition
Memory analysis
Acquisition
Many tools, focus on free ones
Mandiant Memoryze
Moonsols Windows Memory Toolkit (Win32dd)
ManTech MDD

5. Memory forensics – how? (2)
Analysis
Finding OS and other artifacts in image
Free and commercial tools
Volatility Framework
Mandiant Redline/Memoryze
EnCase, HBGary Responder and many other
All support raw dump, weak support for
hib/crash file
Volatility has weak support for x64

6. Memory forensics – how? (3)
„The big picture”
Analysis tool
Acquisition tool Memory dump
User mode
Install driver Kernel mode
Acquisition driver Remote host
Send dump over network
Memory dump
algorithm
1. Reading DevicePhysicalMemory
2. Physical space mapping (MmMapIoSpace())
3. Raw Virtual2Physical mapping

7. Previous works - simple
Blocking acquisition
Killing acquisition process
tools always have the same names
Blocking driver installation
driver installation is necessary on OS >= Win2k3
names not random
Metasploit script
not available anymore
Evasion very simple
Rename process
Rename driver
not that easy if you don’t have the source

8. Previous works – advanced
Blocking analysis
Haruyama/Suzuki BH-EU-12: One-byte
Modification for Breaking Memory Forensic
Analysis
minimal modifications to OS artifacts in memory
targets key steps of analysis to make it
impossible/difficult
so-called abort factors
tool specific
Pros:
subtle modifications (harder detection)
Cons:
cannot hide arbitrary object (could theoretically)
breaks entire analysis – can raise suspicion

9. Previous works – advanced (2)
Attacking acquisition & analysis
Sparks/Butler BH-JP-05: Shadow Walker –
Raising the bar for Rootkit Detection
intentional desynchronization of ITLB/DTLB
faking reads of and writes to „arbitrary” memory
location
execute access not faked
Pros:
awesome idea:)
hides (almost) arbitrary objects
Cons:
not very stable (and no MP/HT support)
page fault handler visible (code and IDT hook)
performance

10. Memory acquisition – flawed by design?
Where is the weakest link?
Analysis tool
Acquisition tool Memory dump
User mode
Attacker kernel access == Install driver Kernel mode
Acquisition driver Remote host
Send dump over network
Memory dump
algorithm
1. Reading DevicePhysicalMemory
2. Physical space mapping (MmMapIoSpace())
3. Raw Virtual2Physical mapping

11. Defeating Windows memory forensics
Introducing Dementia
PoC tool for hiding objects in memory dumps
currently only processes
x86 only
Kernel driver
NtWriteFile inline hook
could hook even lower
list of addresses to be hidden
virt2phys translation – using DTB of System process
clears process allocation (PoolTag „Proc”)
„unlinks” the process from the process list in dump
clears EPROCESS block

12. Defeating Windows memory forensics (2)

13. Defeating Windows memory forensics (3)
Limitations
Plenty of other artifacts not hidden
Handle tables not cleaned
Memory allocated by process not cleaned
including process code and data
Work in progress!

14. Memoryze case
Memoryze is interesting…
Not reliant on API calls?
What about

15. Memoryze case (2)
Memoryze re-designed the workflow a bit:
Analysis tool
Write dump
Acquisition tool
Memory dump
User mode
Install driver Kernel mode
Return read page
Acquisition driver
Dump memory Memory dump
algorithm
1. Reading DevicePhysicalMemory
2. Physical space mapping (MmMapIoSpace())

16. Memoryze case (3)
Yes, attacker can now modify dump from
the user mode:)
Dementia module
Hiding target process, process threads and
connections
completely from the user mode, no driver used
currently even more advanced than the driver mode:)
Injects to Memoryze process
Hooks DeviceIoControl and sanitizes buffers on
the fly
Works similarly to Volatility
but no virt2phys translation, determine everything
from the dump
has partial knowledge – only single pages of the dump

17. Memoryze case (4)
DEMO

18. Possible solutions
Memoryze should adopt traditional
workflow
Current is both slow and insecure
Use crash dumps (native!) instead of raw
dumps
Entirely different OS mechanisms
Use hibernation files
Plagued by the same problems, but more
difficult to tamper with
Use hardware acquisition tools?
Perform anti-rootkit scanning before
acquisition?

19. Thank you!