3. Agenda
1. Motivation
2. Anti-sandbox tricks
3. Using a hypervisor for monitoring
4. Mo’ problems!
5. Fixing the problems
6. Mo’ problems!
7. Conclusion
4. An early warning
This presentation will get technical
Don’t be afraid of the assembly
Don’t worry if some of it makes no sense
5. Sandboxes & honeypots
“Let’s just see what happens”
Most of our tools for observing software at
run-time are built with an assumption that
misbehavior is accidental
- Debuggers
6. Stealth
Debuggers were not designed to be
stealthy
Debugged process can detect the
debugger
Observer effect
8. Some other popular strings
CheckRemoteDebuggerPresent
IsDebuggerPresent
VIRTUALBOX
VBoxGuestAdditions
QEMU
Prod_VMware_Virtual_
XenVMM
MALTEST
TEQUILABOOMBOOM
VIRUS
MALWARE
SANDBOX
WinDbgFrameClass
SAMPLE
https://github.com/Yara-Rules/rules/blob/master/antidebug_antivm.yar
9. AntiCuckoo
Detect & crash the Cuckoo process
- Ouch..
Real malware would probably just falsify
the results to not stand out..
https://github.com/David-Reguera-Garcia-Dreg/anticuckoo
11. Improving Stealth #1
Move the monitoring component into the
kernel
Windows doesn’t like it if you just
randomly hook stuff (PatchGuard)
What about rootkits?
14. Rootkit problem?
Based on these numbers rootkits may
seem to be not that big of a deal
High cost of development may mean you
don't use one unless you have to
Or are we just bad at detecting them?
15. Improving Stealth #2
Move the monitoring component into a
hypervisor
Harder to detect
Greater visibility
Harder to develop
16. Emulation vs. virtualization
Emulation Pro:
- Easier to monitor
Emulation Con:
- Easy to detect
- Easy to get it wrong
- Unlikely in production environment
17. How to start the malware?
Our goal is to do everything without the
need of an in-guest agent
No startup scripts, no client process
Straight up memory and CPU
manipulation can get us what we need!
18. Done?
Nope
Malware can detect if it’s running in a
virtualized environment
Hypervisors were not designed to be
stealthy either
23. 60GB free disk space?
LVM copy-on-write allows us to quickly
deploy lightweight duplicates
Analysis clones will only use extra space
if they change files
And only as much space as they actually
changed
26. Uptime check
Let your VM sit idle for a while, take
memory snapshot
Start each analysis clone by loading this
memory snapshot
Could also just return fake value
28. Memory size check
Who uses a machine with <1Gb RAM?
We can increase sandbox memory size
but that limits how many we can run
Xen memory sharing allows CoW!
31. Xen memory-sharing status
It works but it’s very experimental
Original developer no longer around
May not work with other experimental
Xen features
41. I/O activity
It’s all emulated so we could fake it
We could even reconstruct the location of
buttons / pop-ups from memory!
Click on “Install” buttons?
- Doesn’t seem to make much difference
- http://laredo-13.mit.edu/~brendan/BSIDES_NOLA_2015.pdf
42. Other CPUID leaks
hypervisor_id = "XenVMMXenVMM" (0x40000000/ebx-edx)
hypervisor version (0x40000001/eax):
version = 4.6
hypervisor features (0x40000002):
number of hypercall-transfer pages = 0x1 (1)
MSR base address = 0x40000000
MMU_PT_UPDATE_PRESERVE_AD supported = false
vtsc = false
host tsc is safe = true
boot cpu has RDTSCP = true
tsc mode = 0x0 (0)
tsc frequency (kHz) = 3392364
incarnation = 0x1 (1)
43. PCI leaks
00:02.0 VGA compatible controller: Cirrus Logic GD 5446 (prog-if 00 [VGA controller])
Subsystem: Red Hat, Inc QEMU Virtual Machine
Physical Slot: 2
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR-
FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR-
<PERR- INTx-
Latency: 0
Region 0: Memory at f0000000 (32-bit, prefetchable) [size=32M]
Region 1: Memory at f2072000 (32-bit, non-prefetchable) [size=4K]
Expansion ROM at f2060000 [disabled] [size=64K]
Kernel driver in use: cirrus
44. Disk vendor leaks
description: ATA Disk
product: QEMU HARDDISK
physical id: 0.0.0
bus info: scsi@0:0.0.0
logical name: /dev/sda
version: 1
serial: QM00001
size: 93GiB (100GB)
capabilities: partitioned partitioned:dos
configuration: ansiversion=5 logicalsectorsize=512 sectorsize=512 signature=a6b04d21
45. Some more things to look for
Screen resolution
File modification timestamps
Username
Malware executable file-name
GeoIP
47. Telling time
RDTSC is trappable to the hypervisor
- We could actually fake the value it returns
Not the only way to measure time
- HPET, NTP, covert channels..
51. Advanced Stalling malware
Spam system calls that normally finish
fast
- NtCreateSemaphore
Monitoring incurs overhead on each call
so this will time out the sandbox
http://www.syssec-project.eu/m/page-media/3/hasten-ccs11.pdf
55. Discussion
There is no absolute stealth
Making stealthier tools require malware to
run more checks
But only if our analysis tools span the
entire spectrum
56. Conclusion
No end in sight
Still many low-hanging fruits for malware
to detect
A lot more tools available
We need to use them all or malware
becomes resilient faster