modern post-exploitation strategies - 44con 2012
DESCRIPTION
Rich Smith's Modern Post-Exploitation Strategies presentation slides from 44CON 2012 in London, September 2012.TRANSCRIPT
What are we going to discuss
• Going to discuss some ongoing research in extending attack techniques
• Came from real world needs of being
able to manage complex, long term attack engagements for customers
3
What are we going to discuss
• Looking at: • Attack process • Attack workflow • How current tooling map to complex
workflows • Pen-test vs Attack
4
Targeted attack services
One of the things we do is to perform highly targeted attacks for our customers
5
Long term, breadth
Ongoing engagements, think ~6-12 months 6
Goal driven
Read CEO’s email
7
Alter source code
Multi-stage, incremental
• Baby steps towards a goal 8
Current tooling falls short
9
Huge focus on exploitation
10
Recon Exploit Post-‐Exploit
Time
What is post-exploitation?
• What you do after you compromise
• Nothing to do with how you compromise
11
Or from the attacker perspective
‘How to make the BEST use of the systems that have been compromised’
12
What do I worry about at night?
13
Attacker worries
14
Post-exploitation challenges
15
Avoid Detection QA &
Maintenance
Manage Many Targets Rapid Development
Post-exploitation worries
I also worry about technology futures & how it may change the attack landscape
16
Technology trends ( From Gartner’s 2012 Hype Cycle of Emerging Technologies - August 16, 2012 )
Future questions
18
A3ack Effec7veness
Co$t of A3ack
Shi> the Target
Cloud Computing
Trends
Mobile Devices
Trends
Bring your own device (BYOD)
Trends
Social Media
Trends
23
Trends & attack
Overall Trends • Larger number of resources • Greater diversity in those resources • Increased inter-resource complexity/
dependency • Users relationship with technology has
never been deeper
Post-exploitation challenges
24
Avoid Detection QA &
Maintenance
Manage Many Targets Rapid Development
Not well, if at all
25
Scale poorly
26
• Recognize current post-exploitation ‘binary dropper’ approaches don’t scale well
• In the development process
• In the ability to be effective against diverse targets
• Pen-test frameworks use this approach - Software engineering nightmare
Baking in
27
• Baking in capabilities to the implant is sub-optimal for most situations
• Reduce your flexibility post-compromise • Can reveal an overall attack intent
- Reverse engineering field day
28
Size matters
BIG is not what should be most worrying
Small is
High Level Aims
Scalability Greater platform independence Easier to develop & maintain logic
Stealth Reduced attribution & MO leakage Avoid existing deployed defenses
29
30
Technical Proof of concept
Goals
31
• Would be great to have a single payload that would run everywhere!
• Cross platform, Interpreted Languages such as Java or Python could help here
• They also help address some of the software engineering worries
Goals
32
• Separate what you do, from why you do it
• Lots of distributed system approaches that may help out here e.g. RPC
• Can also help with reducing complexity in the implant, pushing it to the server
The implementation
• Uses Python over-the-wire bytecode for cross-platform tasking • No persistent native binary code • Harder analysis on both platter & wire
• A distributed implant architecture, RPC based • Split the task & the decision • ‘Reach back’ rather than ‘bake in’
33
High level
34
Post-exploitation logic executes in the the Interpreted Language runtime, not on the
target platform
Dispatch Bytecode
IL Process Loop
IL implant
Return Object
Server
Process
Task process Tasks
IL source
IL bytecode
RPC
35
Python internals 101 Python Internals
101
Python internals 101
Bytecode • Python source code as written by the
programmer is compiled to a simple bytecode representation This is what the .pyc’s/.pyo’s are
• Python bytecode is portable between platforms & architectures As long as major & minor versions are the
same (micro can vary)
36
Python internals 101
Import hooks • Python has modules & packages • import statement is used to access
them & resolve their dependency tree • An import hook is custom importer that
can be used to find & load modules in non-standard ways Importer protocol defined in PEP302
37
Python internals 101
• Writing new hooks can be a pain in the *** Worth a whole talk in itself, see ‘Import this, that
and the other thing’ by Brett Cannon PyCon2010 – it’s excellent
• Python 3.x reduces this pain via importlib • Not available in Python 2.x so you need to
implement from scratch using PEP 302 Available since v2.3 to better customize the
__import__ builtin Given 2.x is in the widest use this is what I did
38
Python internals 101
• The PEP 302 protocol defines A Finder Tends to be pretty straightforward Locate the module/package code
A Loader More complex Compile to bytecode if needed Insert module into namespace Execute top level code Lots of annoying metadata bookkeeping
39
40
Python internals 101
41
PythonVM
Stage 0 Bytecode
Exec (Persistent)
Stage 1 HTTPS +
ZIP Import Hook
Stage 2 RPC Import Hook
& Mainloop
Tasking bytecode
Binary Injector / Userland
Exec
Native task
• Self-Bootstrapping • Stage 0 is the only
persistent part of the implant. Tiny & generic
• Simple event-loop that GETs bytecode over SSL & runs it from memory • This is used to bootstrap
the Stage 1 import hook ….
42
PythonVM
Stage 0 Bytecode
Exec (Persistent)
Stage 1 HTTPS +
ZIP Import Hook
Stage 2 RPC Import Hook
& Mainloop
Tasking bytecode
Binary Injector / Userland
Exec
Native task
• Stage 1 Import Hook - In memory import of a zip over SSL • Zip imports supported
since Py2.3 • but only from the filesystem not
memory
• Re-implement the stdlib zipfile module in Python
Stage 1
43
Bootstrap server
Stage 1 Get Zip
Zip in memory
(SSL)
Expanded zip in memory
Finder
Loader
Unzip
Custom Import Hook in Stage 1
Import
Module / Package in frame’s namespace
Stage 0
44
PythonVM
Stage 0 Bytecode
Exec (Persistent)
Stage 1 HTTPS +
ZIP Import Hook
Stage 2 RPC Import Hook
& Mainloop
Tasking bytecode
Binary Injector / Userland
Exec
Native task • Stage 2 is a full RPC Import
Hook + RPC client node • Import hook resolves
bytecode dependency trees remotely & transparently • No sourcecode mods
• Fully symmetric RPC system over SSL
• Splits the task & decision
Stage 2 RPC import hook
45
Remote Import
RPC
Finder
Loader Pre-compiled Payload Cache Stdlib
Compile & Strip
Sys.modules
RPC Endpoint
HTTPS
Map into mem
Scrub mem
Server Implant
Stage 2 Mainloop
• Now there is the ability for complex bytecode bundles to be sent, executed and automatically have dependencies resolved remotely without touching disk Write completely standard Python Much quicker to write than C/ASM Much easier to debug/QA Non-stdlib packages easily usable
46
Initialization
• 1st Task performed is to derive a UUID IP’s are often used but generally a bad choice
when managing many targets
• Instead we use SYSUUID from SMBIOS Fairly easy to get at from Pure Python on
Unixes, Linux & OSX Pain in the a** on Windows but can be done
via Ctypes
47
Mainloop
• The implant uses a polling mechanism rather than a persistent connection At random intervals checks-in to RPC endpoint(s) Pending tasks can be sent as A task ID to import, resolve & execute All tasks can operate in own thread or child
• Nothing needs to touch disk • Result objects cached & returned next
check-in
48
Mainloop
49
Task Queue
Dispatcher
Poll Loop
Result Processing
Logic
RPC Endpoint
UUID: Result Objects
UUID Result Obj
Spawn New Task RPC Endpoint
Payload bytecode
To run/import
Services Services Services
New task
New Task Process
Result Cache
Service Logic
RPC imports
Tasks
• Tasks are split into 2 parts Payload: What executes on the target Service: The logic that processes the result of
the payload, executes on the server • Payloads are pure Python bytecode • Determination of next task happens at
the server If compromise detected we leak minimal MO Allows easy updating of goal oriented logic No need to define goal at asset creation time
50
51
PythonVM
Stage 0 Bytecode
Exec (Persistent)
Stage 1 HTTPS +
ZIP Import Hook
Stage 2 RPC Import Hook
& Mainloop
Common Task
Bytecode
Binary Injector / Userland
Exec
Native task • A Common Task is one that
is pure Python bytecode E.g. Search for files named
‘pk.pem’ • There is a balance to be
struck between stealth & efficiency when splitting tasks Task searching for ‘secret.doc’
can leak MO Exfiltrating every filename to
match to ‘secret.doc’ at the server would use bandwidth
52
PythonVM
Stage 0 Bytecode
Exec (Persistent)
Stage 1 HTTPS +
ZIP Import Hook
Stage 2 RPC Import Hook
& Mainloop
Tasking bytecode
Binary Injector / Userland
Exec
Native task
• A Native Task is one that executes native code Some tasks are too low level/
specific for Python • A number of options
depending on OS Ctypes, PyObjC, Subprocess
• Potential issues Forensically noisy Native functions may
be hooked • One solution userland
execution …….
Userland execution
• Allows execution through the replacement/modification of existing process image with a new one Without calling OS (Execve, loadlibrary etc) Without having to load from disk
• Useful in a number of scenarios Antiforensics Non-exec filesystem mounts Wanting to inject native code from a IL VM!
53
Userland execution
• Builds on years of other people research • Grugqs Phrack 62 paper ul_exec & FIST (Linux) • Pluf & Ripe’s SELF work from Phrack 63 (Linux) • Immunity’s PyELF library (Linux) • Nebbet’s Shuttle (Windows) • Dai Zovi’s & Iozzo’s Mach-O work (OS X) • pyMachO …
54
pyMachO
• Facilitates userland exec from a Python runtime on OS X Think PyELF for OS X Nicely sidesteps code-signing controls
• Send a Mach-O binary over the wire to a Python userland exec task, & inject it into an existing process
55
pyMachO
56
Native Binary
Python Userland Exec (pyMachO, pyELF….)
Implant Layer (RPC)
Native Binary Data
Inject
Over the wire Python Bytecode
Task
Python Runtime
Example injection
• For the demo we will inject an OSX MachO bundle to do webcam capture • isight.bundle hasn’t worked since 64bit
Snow Leopard • Relies on Quicktime.framework • 32 bit only
• So we wrote a new one for the demo using QTKit (32 & 64 bit supported)
57
Tying it all together
58
Stage 0 (persistent)
Stage 1 HTTP/Zip Hook
Stage 2 RPC Hook
Get SysUUID
pyMachO
Webcam Grab Binary
Python VM
Facial Recognition
Implant Server
Bootstrap
Tasking
?
59
Demo Time!
Summary
60
Takeaways • Current post-exploitation approaches do
not scale well • Baking-in capabilities can leak your intent • Interpreted languages can help with scale • Distributed architectures can help with
separating action from reason
Summary
61
Calls to action Providers • Don’t let the current toolsets dictate and limit you,
critique, innovate & change them to suit your needs
Customers • Understand the difference between, and value of
Pen-Testing vs Attack Teaming
