Rich Smith's Modern Post-Exploitation Strategies presentation slides from 44CON 2012 in London, September 2012.

2. Modern
Post-Exploitation
Strategies
Rich Smith
Kyrus
Rich@Kyr.us

3. 3
• 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
What are we going to discuss

4. 4
• Looking at:
• Attack process
• Attack workflow
• How current tooling map to complex
workflows
• Pen-test vs Attack
What are we going to discuss

5. 5
One of the things we do is to perform
highly targeted attacks for our customers
Targeted attack services

6. 6
Ongoing engagements, think ~6-12 months
Long term, breadth

7. 7
Read CEO’s email Alter source code
Goal driven

8. 8
• Baby steps towards a goal
Multi-stage, incremental

9. 9
Current tooling falls short

10. 10
Recon
Exploit
Post-­‐Exploit
Time
Huge focus on exploitation

11. 11
• What you do after you compromise
• Nothing to do with how you compromise
What is post-exploitation?

12. 12
‘How to make the BEST use of the systems
that have been compromised’
Or from the attacker perspective

13. 13
What do I worry about at night?

14. 14
Attacker worries

15. 15
Manage Many Targets
Rapid Development
QA &
Avoid Detection
Maintenance
Post-exploitation challenges

16. 16
I also worry about technology futures & how
it may change the attack landscape
Post-exploitation worries

17. ( From Gartner’s 2012 Hype Cycle of Emerging Technologies - August 16, 2012 )
Technology trends

18. 18
Co$t
of
A3ack
Shi>
the
Target
A3ack
Effec7veness
Future questions

19. Cloud Computing
Trends

20. Mobile Devices
Trends

21. Bring your own device (BYOD)
Trends

22. Social Media
Trends

23. 23
Overall Trends
• Larger number of resources
• Greater diversity in those resources
• Increased inter-resource complexity/
dependency
• Users relationship with technology has
never been deeper
Trends & attack

24. 24
Manage Many Targets
Rapid Development
QA &
Avoid Detection
Maintenance
Post-exploitation challenges

25. 25
Not well, if at all

26. 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
Scale poorly

27. 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
Baking in

28. 28
BIG
is not what should be
most worrying
Small is
Size matters

29. 29
Scalability
­ Greater platform independence
­ Easier to develop & maintain logic
Stealth
­ Reduced attribution & MO leakage
­ Avoid existing deployed defenses
High Level Aims

30. 30
Technical
Proof of concept

31. 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. 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
Goals

33. 33
• 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’
The implementation

34. 34
Post-exploitation logic executes in the the
Interpreted Language runtime, not on the
target platform
RPC
Server IL implant
Bytecode
IL bytecode Dispatch
IL Process Task
Loop Tasks
process
Return
IL source Process Object
High level

35. 35
Python internals
101 Python Internals
101

36. 36
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)
Python internals 101

37. 37
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
Python internals 101

38. 38
• 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
Python internals 101

39. 39
• 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
Python internals 101

40. 40
Python internals
101

41. 41
• Self-Bootstrapping
Native task
• Stage 0 is the only
Tasking
Binary
Injector /
persistent part of the
bytecode Userland
Exec
implant. Tiny & generic
Stage 2
RPC Import Hook • Simple event-loop that
& Mainloop
GETs bytecode over SSL &
Stage 0 Stage 1 runs it from memory
Bytecode HTTPS +
Exec ZIP Import
(Persistent) Hook
• This is used to bootstrap
PythonVM
the Stage 1 import hook ….

42. 42
• Stage 1 Import Hook -
Native task In memory import of a zip
over SSL
Binary
Tasking Injector /
bytecode Userland
Exec
• Zip imports supported
since Py2.3
Stage 2 • but only from the filesystem not
RPC Import Hook
& Mainloop memory
Stage 0
Bytecode
Stage 1
HTTPS +
• Re-implement the stdlib
Exec
(Persistent)
ZIP Import
Hook
zipfile module in Python
PythonVM

43. 43
(SSL)
Bootstrap Get Zip Stage 1 Stage 0
server
Unzip Expanded zip
Zip in in memory
memory
Custom Finder
Import Import
Hook in
Stage 1 Loader
Module / Package in frame’s namespace
Stage 1

44. 44
Native task
• Stage 2 is a full RPC Import
Hook + RPC client node
Binary
Tasking
bytecode
Injector /
Userland
• Import hook resolves
Exec bytecode dependency trees
Stage 2
remotely & transparently
RPC Import Hook
& Mainloop
• No sourcecode mods
Stage 0
Bytecode
Stage 1
HTTPS +
• Fully symmetric RPC system
Exec
(Persistent)
ZIP Import
Hook
over SSL
PythonVM
• Splits the task & decision

45. 45
RPC
Server
Endpoint Implant
Remote
HTTPS
Finder
Import
RPC
Map into
mem
Compile &
Strip
Pre- Loader Sys.modules
compiled
Payload
Stdlib Cache
Scrub mem
Stage 2 RPC import hook

46. 46
• 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
Stage 2 Mainloop

47. 47
• 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
Initialization

48. 48
• 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
Mainloop

49. 49
RPC UUID:
Result
Objects
Endpoint Poll Loop
Result
Cache
Result
Obj
UUID
Result Payload
bytecode
Spawn New
Processing Dispatcher Task RPC
Logic To
run/import
Endpoint
Service
New
task
RPC
Logic
imports
New Task
Services Task
Services Process
Services Queue
Mainloop

50. 50
• 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
Tasks

51. 51
• A Common Task is one that
Native task
is pure Python bytecode
­ E.g. Search for files named
Common
Binary ‘pk.pem’
Injector /
Task
Bytecode
Userland
Exec
• There is a balance to be
struck between stealth &
Stage 2
RPC Import Hook efficiency when splitting
& Mainloop
tasks
­ Task searching for ‘secret.doc’
Stage 0 Stage 1
Bytecode HTTPS + can leak MO
Exec ZIP Import ­ Exfiltrating every filename to
(Persistent) Hook
match to ‘secret.doc’ at the
PythonVM server would use bandwidth

52. 52
• A Native Task is one that
Native task executes native code
­ Some tasks are too low level/
Binary specific for Python
Tasking
bytecode
Injector /
Userland • A number of options
Exec
depending on OS
Stage 2
­ Ctypes, PyObjC, Subprocess
RPC Import Hook
& Mainloop
• Potential issues
­ Forensically noisy
Stage 0
Bytecode
Stage 1
HTTPS +
­ Native functions may
Exec
(Persistent)
ZIP Import
Hook
be hooked
• One solution userland
PythonVM
execution …….

53. 53
• 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!
Userland execution

54. 54
• 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 …
Userland execution

55. 55
• 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
pyMachO

56. 56
Native Binary
Inject
Python Userland Exec
(pyMachO, pyELF….)
Over
the
wire
Python
Implant Layer Native
Bytecode
(RPC) Binary Data
Task
Python Runtime
pyMachO

57. 57
• 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)
Example injection

58. Implant
Server
58
Webcam Grab Binary Facial Recognition
pyMachO ?
Tasking
Get SysUUID
Stage 2 RPC Hook
Stage 1 HTTP/Zip Hook
Bootstrap
Stage 0 (persistent)
Python VM
Tying it all together

59. 59
Demo Time!

60. 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. 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
Summary

62. 62
¿
Rich@Kyr.us
Rich@Kyr.us
Questions