$30 off During Our Annual Pro Sale. View Details »

Modern Post-Exploitation Strategies

Rich Smith
September 07, 2012

Modern Post-Exploitation Strategies

A talk given at 44Con 2012 and Nordic Security Con 1 where scalable post-exploitation strategies are discussed, and a cross platform RPC based Python based post-exploitation framework is presented.

Rich Smith

September 07, 2012

More Decks by Rich Smith

Other Decks in Technology


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

  2. 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
  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
  4. Targeted attack services One of the things we do is

    to perform highly targeted attacks for our customers 5
  5. Long term, breadth Ongoing engagements, think ~6-12 months 6

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

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

  8. Current tooling falls short 9

  9. Huge focus on exploitation 10 Recon& Exploit& Post/Exploit& Time&

  10. What is post-exploitation? • What you do after you compromise • Nothing

    to do with how you compromise 11
  11. Or from the attacker perspective ‘How to make the BEST

    use of the systems that have been compromised’ 12
  12. What do I worry about at night? 13

  13. Attacker worries 14

  14. Post-exploitation challenges 15 Avoid Detection& QA & Maintenance& Manage Many

    Targets& Rapid Development&
  15. Post-exploitation worries I also worry about technology futures & how

    it may change the attack landscape 16
  16. Technology trends ( From Gartner’s 2012 Hype Cycle of Emerging

    Technologies - August 16, 2012 )
  17. Future questions 18 A3ack& Effec7veness& Co$t&of& A3ack& Shi>&the& Target&

  18. Cloud Computing Trends

  19. Mobile Devices Trends

  20. Bring your own device (BYOD) Trends

  21. Social Media Trends

  22. 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
  23. Post-exploitation challenges 24 Avoid Detection& QA & Maintenance& Manage Many

    Targets& Rapid Development&
  24. Not well, if at all 25

  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
  26. 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
  27. 28 Size matters BIG is not what should be most

    worrying Small is
  28. High Level Aims Scalability ­  Greater platform independence ­  Easier

    to develop & maintain logic Stealth ­  Reduced attribution & MO leakage ­  Avoid existing deployed defenses 29
  29. 30 Technical Proof of concept

  30. 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
  31. 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
  32. 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
  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&
  34. 35 Python internals 101 Python Internals 101

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

  40. 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 ….
  41. 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
  42. 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
  43. 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
  44. 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&
  45. 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
  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
  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
  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&
  49. 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
  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
  51. 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 …….
  52. 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
  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
  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
  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
  56. 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
  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 ?&
  58. 59 Demo Time!

  59. 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
  60. 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
  61. Questions ¿ 62 Rich@Kyr.us Rich@Kyr.us

  62. None