Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Modern Post-Exploitation Strategies - 44CON 2012


Published on

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

Published in: Technology
  • Be the first to comment

Modern Post-Exploitation Strategies - 44CON 2012

  1. 1. ModernPost-ExploitationStrategiesRich SmithKyrus
  2. 2. 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
  3. 3. 4•  Looking at: •  Attack process •  Attack workflow •  How current tooling map to complex workflows •  Pen-test vs Attack What are we going to discuss
  4. 4. 5One of the things we do is to performhighly targeted attacks for our customers Targeted attack services
  5. 5. 6Ongoing engagements, think ~6-12 months Long term, breadth
  6. 6. 7Read CEO’s email Alter source code Goal driven
  7. 7. 8•  Baby steps towards a goal Multi-stage, incremental
  8. 8. 9Current tooling falls short
  9. 9. 10Recon   Exploit   Post-­‐Exploit   Time   Huge focus on exploitation
  10. 10. 11•  What you do after you compromise•  Nothing to do with how you compromise What is post-exploitation?
  11. 11. 12‘How to make the BEST use of the systems that have been compromised’Or from the attacker perspective
  12. 12. 13What do I worry about at night?
  13. 13. 14Attacker worries
  14. 14. 15Manage Many Targets   Rapid Development   QA &Avoid Detection   Maintenance   Post-exploitation challenges
  15. 15. 16I also worry about technology futures & howit may change the attack landscape Post-exploitation worries
  16. 16. ( From Gartner’s 2012 Hype Cycle of Emerging Technologies - August 16, 2012 ) Technology trends
  17. 17. 18 Co$t  of   A3ack   Shi>  the   Target   A3ack  Effec7veness   Future questions
  18. 18. Cloud Computing Trends
  19. 19. Mobile Devices Trends
  20. 20. Bring your own device (BYOD) Trends
  21. 21. Social Media Trends
  22. 22. 23Overall 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
  23. 23. 24Manage Many Targets   Rapid Development   QA &Avoid Detection   Maintenance   Post-exploitation challenges
  24. 24. 25Not well, if at all
  25. 25. 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
  26. 26. 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
  27. 27. 28BIG is not what should be most worrying Small is Size matters
  28. 28. 29Scalability ­  Greater platform independence ­  Easier to develop & maintain logicStealth ­  Reduced attribution & MO leakage ­  Avoid existing deployed defenses High Level Aims
  29. 29. 30TechnicalProof of concept
  30. 30. 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
  31. 31. 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
  32. 32. 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
  33. 33. 34Post-exploitation logic executes in the theInterpreted Language runtime, not on the target platform RPC   Server IL implant BytecodeIL bytecode Dispatch IL Process Task Loop Tasks process Return IL source Process Object High level
  34. 34. 35Python internals101 Python Internals 101
  35. 35. 36Bytecode•  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
  36. 36. 37Import 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
  37. 37. 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
  38. 38. 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
  39. 39. 40Python internals101
  40. 40. 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 ….
  41. 41. 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
  42. 42. 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
  43. 43. 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
  44. 44. 45 RPC Server   Endpoint Implant   Remote HTTPS   Finder Import RPC Map into memCompile & Strip Pre- Loader Sys.modules compiled Payload Stdlib Cache Scrub mem Stage 2 RPC import hook
  45. 45. 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
  46. 46. 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
  47. 47. 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
  48. 48. 49 RPC UUID:  Result  Objects   Endpoint Poll Loop Result CacheResult  Obj   UUID   Result Payload  bytecode   Spawn New Processing Dispatcher Task RPC Logic To  run/import   EndpointService   New  task   RPC    Logic            imports   New Task Services Task Services Process Services Queue Mainloop
  49. 49. 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
  50. 50. 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
  51. 51. 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 …….
  52. 52. 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
  53. 53. 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
  54. 54. 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
  55. 55. 56 Native Binary Inject  Python Userland Exec (pyMachO, pyELF….) Over  the  wire   Python Implant Layer Native Bytecode (RPC) Binary Data Task Python Runtime pyMachO
  56. 56. 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
  57. 57. Implant   Server   58 Webcam Grab Binary Facial Recognition pyMachO ?   Tasking Get SysUUID Stage 2 RPC HookStage 1 HTTP/Zip Hook Bootstrap Stage 0 (persistent) Python VM Tying it all together
  58. 58. 59Demo Time!
  59. 59. 60Takeaways•  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
  60. 60. 61Calls to actionProviders•  Don’t let the current toolsets dictate and limit you, critique, innovate & change them to suit your needsCustomers•  Understand the difference between, and value of Pen-Testing vs Attack Teaming Summary
  61. 61. 62 ¿ Questions