The document discusses advanced persistent threats and techniques used by attackers both historically and currently. It covers topics like out-of-band analysis techniques to gain "perfect knowledge" of attackers through reverse engineering, using telemetry and signatures to detect malware, and challenges with scanning techniques due to polymorphism and evasion methods used by attackers.
10. Out of band analysis
• Out of band analysis
– Perfect knowledge
– Attacker is unprepared
• Derive understanding from reverse engineering
– Feed back to tactical cleanup/more detection
• Leveraging virtual infrastructure to increase information assurance
– Existing approaches
• Agents
• Virus Scanning
• Whitelists
• A better way
11. Perfect knowledge
• To find an artifact
– Malware/Virus Scanning
– Manual analysis
– Incident day 0
• Finding more
– Collect telemetry
– Signature development
• Reverse engineering
12. Collecting Telemetry
• Useful for improving OODA loop
– more effective decision making during an in
progress event
• Configurable
– System Center Operations Manager / “Agentless”
Exception Monitoring
– Group Policy (XP/2K3)
– Registry CorporateWerServer
13. Signature based scanning
• Devise a set of unique artifacts from a known
malware sample
– TimeDateStamp
– Unencrypted data
– Names of sections or exported Functions
– *wildcard*matching*
14. Heuristics
• A function that derives a score or other
threshold to determine good vs. bad
– Entropy scanning
• Detects encrypted/compressed sections
• Attempt to compress a block to determine if it’s already
compressed
– API Imports
• OpenProcess/WriteProcessMemory
• Hook use
• Low-level interfaces
15. Scanning Approaches
• Agent’s
– A background process which interacts with some
management infrastructure
– Understands known malware through the use of
signatures or behavioral heuristics monitoring
– Typically reports to management consoles
• Virus/Malware Scanning
– Similar to agent based techniques but in the foreground
• Agentless
– VM guest memory snapshots
– SCOM AEM
16. White lists
• Default deny
– Similar to how firewall rules are built
• Only allow known/approved services
• Tripwire uses this technique to guard against file-
system persistence
– Off-line assurances
• Unable to definitively report for live systems
• Can we use this in memory
18. Memory Analysis Options
• WinDbg/Olly/IDA
– Mostly Manual
• Volatility
– Scriptable
• BlockWatch / The Memory Cruncher
– Automated data reduction and navigation support
19. WinDbg
• Works on every version
• Invasive/non-invasive debugging
• Plugin/scriptable
• Essentially Basic Debugging interface
“ContinueDebugEvent”
• User space anti-debugging is very complicated
– Ntdll!*breakpoint* can be tampered with (unable to attach)
– Starting a program does not break at first module instruction
• Break on other events
• Kernel debugger (kd) not as simple to use
– Network debugger can still use windbg
20. Generic Unpacking issues
• Encoding/Obfuscation
– Page decoding
• Non linear execution
– Exceptions (divide by zero)
– Other Process/Threads
– Debugging self
• Detecting a debugger, VM or other analysis
tool
22. Signature development
• Yara
– Lots of support
• https://yaragenerator.com/
• http://www.deependresearch.org/2013/02/yara-
resources.html
• ClamAV
– Less active, some support from SourceFire
• Custom Engine
23. Custom Engine
• Private implementation
– Leverage public tools but developed with
information gained from incident
– May use a variety of analysis techniques
• Combine Yara/Clam/Hash/etc…
• “Perfect knowledge” of attacker
25. Performance
• Complicated generic scanning can be slow
• Regex’s with Overlapping sub-sections may
take a long time to evaluate
– E.g. (.*A).*(.*A) -- or something similar can be a
DoS
26. Windows hardening
• Windows XP does not memset(0) driver .text sections
– Random slack can be executed
– Updated 2k3+
• KINTERRUPT no longer has huge code templates/glue included as part of it’s
structure
– KINTERRUPT.DispatchCode is now 4 bytes (and always just points to a registered handler in the
module) instead of up too 106 bytes of arbitrary code
• Updated Vista+
• Page table entries secured
– Win8 no longer has executable page table entries
• Kernel 9200+ (8/2012) Kernel Pool (heap) is no longer default executable
– This is a MAJOR win!!!!!!
– No more huge degree’s of unknown executable memory to inspect
27. Analyzing Windows Memory
• Rootkit can shadow/move itself during dump’s
• Issues from dumping memory from a live/physical system is
problematic and has lead to an interesting arms race;
– Using cold-boot attacks
– Purpose built dumping hardware or commodity FireWire type
inputs
– Cause kernel panic to induce a dump
• Windows Kernel 9600 (Windows 8.1/2012R2)
– A snapshot from VMWare or Hyper-V
– We will ignore dump acquisition issues for now and focus on VM
snapshots
28. X64 Kernel Virtual Address Space
http://www.codemachine.com/article_x64kvas.html
Start End Size Description Notes
FFFF0800`00000000 FFFFF67F`FFFFFFFF 238TB Unused System Space WIN9600 NOW USE &
CAN CONTAIN +X AREAS
FFFFF680`00000000 FFFFF6FF`FFFFFFFF 512GB PTE Space -X used to be executable
Win7
FFFFF700`00000000 FFFFF77F`FFFFFFFF 512GB HyperSpace 8.1 seems to have cleaned
up here, 9200 had 1 +X
page
FFFFF780`00000000 FFFFF780`00000FFF 4K Shared System Page
FFFFF780`00001000 FFFFF7FF`FFFFFFFF 512GB-4K System Cache Working Set
FFFFF800`00000000 FFFFF87F`FFFFFFFF 512GB Initial Loader Mappings Large Page (2MB)
allocations
FFFFF880`00000000 FFFFF89F`FFFFFFFF 128GB Sys PTEs
FFFFF8a0`00000000 FFFFF8bF`FFFFFFFF 128GB Paged Pool Area
FFFFF900`00000000 FFFFF97F`FFFFFFFF 512GB Session Space
FFFFF980`00000000 FFFFFa70`FFFFFFFF 1TB Dynamic Kernel VA Space
FFFFFa80`00000000 *nt!MmNonPagedPoolStart-
1
6TB Max PFN Database
*nt!MmNonPagedPoolSt
art
*nt!MmNonPagedPoolEnd 512GB Max Non-Paged Pool DEFAULT NO EXECUTE
FFFFFFFF`FFc00000 FFFFFFFF`FFFFFFFF 4MB HAL and Loader Mappings
29. Page Table Shellcode weird-machine
• Win7 and earlier
– Can we emit intended shellcode into PTE area?
• Perform some VirtualAlloc from user space => executable memory in
kernel
– Just reserving memory writes PTE
• Page Table shell-code is non-trivial
– Lots of gadgets!
fffff6fb`7e201ea0 63 b8 c3 2d 00 00 00 00 63 a8 13 2f 00 00 00 00 c..-....c../....
fffff6fb`7e201eb0 63 98 e3 2d 00 00 00 00 63 88 13 2f 00 00 00 00 c..-....c../....
fffff6fb`7e201ec0 63 78 63 30 00 00 00 00 63 68 d3 2e 00 00 00 00 cxc0....ch......
fffff6fb`7e201ed0 63 58 53 30 00 00 00 00 63 48 a3 2e 00 00 00 00 cXS0....cH......
fffff6fb`7e201ee0 63 38 c3 2e 00 00 00 00 63 28 83 2e 00 00 00 00 c8......c(......
PXE at FFFFF6FB7DBEDF68 PPE at FFFFF6FB7DBEDF88 PDE at FFFFF6FB7DBF1008 PTE at FFFFF6FB7E201EA0
contains 0000000000187063 contains 0000000134C04863 contains 0000000100512863 contains
000000002DC3B863
pfn 187 ---DA--KWEV pfn 134c04 ---DA--KWEV pfn 100512 ---DA--KWEV pfn 2dc3b ---DA--KWEV
30. Defense: Rootkit revealing
• Default non-execute pool space helps tremendously
• Detect the presence of a rootkit by comparing results
from multiple sources/abstraction layers
– Physical (page tables)
– Logical
• Driver LIST_ENTRY
• VAD
– SECTION’s, …
31. Tool evaluation
• https://blockwatch.ioactive.com
– Operates on direct physical memory dumps from VM snapshots
– Demo script that identifies KVAS physical/logical sections
– Transforms/Dumps memory / Generates hashes
– Install IronPython
• Example, from Crunch install directory
ipy64 UnLinkedRR.py C:BW_Folder VMWare.VMSS.or.VMSD d:dest-
folder
• Future
– More well known blocks (local optimization)?
• There’s some weird looking fill patterns often sitting around as exec;
• More page table checks, CR0.WP etc…
32. Example VMWare ~8GB
BlockWatch Folder: t:BW_DEMO
Dumping data from : Clone of Clone of Current Win 8.1 - PRO (2)-66bb942e.vmss
Found probable kernel @ fffff800b508c000
Debug symbol being loaded for ntkrnlmp.pdb
Kernel build number 9600
Root PT Entries: 16, SubTable Entries: 778263
Unlinked entry count: 1544
UnLinked Section: System Space @: 0xffffd00020180000L, Size: 0x1000L
UnLinked Section: Loader Mappings @: 0xfffff800021d0000L, Size: 0x1000L
UnLinked Section: HAL and Loader Mappings @: 0xffffffffffd02000L, Size: 0x1000L
UnLinked Section: hal @: 0xfffff800b5000000L, Size: 0x200000L
UnLinked Section: Loader Mappings @: 0xfffff800b5800000L, Size: 0x200000L
33. …moving on; Attack! To the Unknown!
kd> !pte ffffd000`201a0000
VA ffffd000201a0000
PXE at FFFFF6FB7DBEDD00 PPE at FFFFF6FB7DBA0000 PDE at FFFFF6FB74000800 PTE at FFFFF6E800100D00
contains 0000000000523863 contains 0000000000522863 contains 0000000000527863 contains 0000000000555963
pfn 523 ---DA--KWEV pfn 522 ---DA--KWEV pfn 527 ---DA--KWEV pfn 555 -G-DA—KWEV
• ffffd000201a0000 appears across Hyper-V &
VMWare, reboots
– Provides RoP gadgets
– Fixed writeable executable memory location
• Writable/Executable at a fixed address
!pool ffffd000`201a0000
Pool page ffffd000201a0000 region is Unknown
ffffd000201a0000 is not a valid large pool allocation, checking large session pool...
Unable to read large session pool table (Session data is not present in mini and kernel-only dumps)
ffffd000201a0000 is not valid pool. Checking for freed (or corrupt) pool
34. Can you guess what it is?
• ??
• Segoe_slboot.ttf
– Starts at offset 0x1d0
– Initial bytes some sort of heap tag ? BG*
– System boot/load time artifact
ffffd000`201a0000 21 01 a0 00 00 00 00 80 42 47 49 4b 00 00 00 80 !.......BGIK....
ffffd000`201a01d0 00 19 00 23 00 01 2e 4c 00 00 00 10 67 6c 79 66 ...#...L....glyf
ffffd000`201b2fb0 00 6e 00 74 00 65 00 6e 00 74 00 2e 00 53 00 65 .n.t.e.n.t...S.e
ffffd000`201b2fc0 00 67 00 6f 00 65 00 20 00 55 00 49 00 03 00 00 .g.o.e. .U.I....
35. A little more (past end of font)
ffffd000`201b3000 ffffd000201b3020 0000000100002000 ffffd000201b3020 8000000000300121
…
ffffd000`201b3020 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 MZ..............
ffffd000`201b3070 69 73 20 70 72 6f 67 72 61 6d 20 63 61 6e 6e 6f is program canno
…
ffffd000`201b46b2 49 00 6e 00 74 00 65 00 72 00 6e 00 61 00 6c 00 4e 00 61 00 I.n.t.e.r.n.a.l.N.a.
ffffd000`201b46c6 6d 00 65 00 00 00 62 00 6f 00 6f 00 74 00 72 00 65 00 73 00 m.e...b.o.o.t.r.e.s.
• Seems to have some basic heap structure
pointer’s/allocation sizes
– Unfortunately it’s all default executable/writable at
a fixed address across systems/rebooting
• This leaves a lot of room for RoP gadgets (MZ
is only .rsrc, why +x?)
36. BIOS Ranges
• Platform specific (vmware in this case)
– 2012R2 0xffffd00020500000, 8.1 0xffffd00020600000
– Fixed address across reboots (size is 241,664 - 0x3B000)
– Physical system dumps
ffffd000`206c5a50 c3 32 2e 30 00 56 4d 77 61 72 65 20 76 69 72 74 .2.0.VMware virt
ffffd000`206c5a60 75 61 6c 20 6d 61 63 68 69 6e 65 00 56 4d 77 61 ual machine.VMwa
ffffd000`206c5a70 72 65 2c 20 49 6e 63 00 56 20 4d 20 77 61 72 65 re, Inc.V M ware
ffffd000`206c5a80 2c 20 49 6e 63 2e 20 56 42 45 20 73 75 70 70 6f , Inc. VBE suppo
ffffd000`206c5a90 72 74 20 32 2e 30 00 90 c8 02 00 00 c4 5e 04 33 rt 2.0.......^.3
3: kd> !pte ffffd000`206c5a50
VA ffffd000206c5a50
PXE at FFFFF6FB7DBEDD00 PPE at FFFFF6FB7DBA0000 PDE at FFFFF6FB74000818 PTE at FFFFF6E800103628
contains 0000000000B22863 contains 0000000000B21863 contains 0000000000852863 contains 00000000000C5963
pfn b22 ---DA--KWEV pfn b21 ---DA--KWEV pfn 852 ---DA--KWEV pfn c5 -G-DA--KWEV
37. Other/More dynamic/Misc Areas
• Slack
• Audit MDL structures
• Session Space
• ACPI FACS -- exec
– Firmware ACPI Control Structure
– Verify ACPI with wite list
• Shim Engine (i.e. handling for drvmain.sdb)
• Bootloader artifacts
• Volume manager heap
0: kd> !pool ffffe00000420000
Pool page ffffe00000420000 region is Nonpaged pool
*ffffe00000420000 size: 90 previous size: 0 (Allocated) *VM3D
Pooltag VM3D : Volume Manager, Binary : volmgr.sys
0: kd> !pool ffffe000`00418000
Pool page ffffe00000418000 region is Nonpaged pool
*ffffe00000418000 size: 90 previous size: 0 (Allocated) *VM3D
Pooltag VM3D : Volume Manager, Binary : volmgr.sys
38. Other Gadget Areas
• There are other +X areas, in the region, but have
small variability in their allocation
• Windows Boot manager, network boot support code,
more font areas
39. Defense: RoP Detection
• Spurious Saved Return Addresses
– Sometimes RoP Gadget is just random data present
in an executable section!!!
– All existing RoP Databases or techniques target
arbitrary saved return addresses
• https://www.corelan.be/index.php/security/corelan-
ropdb/#advapi32dll_8211_5126005755
– 0x77e25c1f, # POP EAX # RETN
– Saved Return should be
• Simple/Effective/Very reliable reducing gadget surface area
40. Spurious Saved Return Addresses
Validation
• Conceptually similar to heap back-checking logical links
except we walk the stack
– Think Heap/Pool verification
– Verify op-code preceding saved return address
– Adding into BlockWatch
• Our operation is static so performance is no big deal and we like to
be current!
– Some performance impact if implemented at run time
– May not reduce the gadget surface area sufficiently
41. Comprehensive verification
• Forensics
– Reduction / Analysis aid
• APT Detection
– Diffing
– White list
• Blockwatch.ioactive.com
– Signup & use
– Less unknown’s more secure
42. BlockWatch Service
• Largest Hash Database on the planet
– 300+Million entries in the white list
– High degree of Windows OS’s and server software
• Run with local white list definition