Modern Post-Exploitation Strategies - 44CON 2012

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

Modern Post-Exploitation Strategies [email protected] Rich Smith Kyrus

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

What are we going to discuss • Looking at: • Attack process • Attack workﬂow • How current tooling map to complex workﬂows • Pen-test vs Attack 4

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Goal driven Read CEO’s email 7 Alter source code

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

Current tooling falls short 9

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

What do I worry about at night? 13

Slide 14

Slide 14 text

Attacker worries 14

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

Future questions 18 A3ack Eﬀec7veness Co$t of A3ack Shi> the Target

Slide 19

Slide 19 text

Cloud Computing Trends

Slide 20

Slide 20 text

Mobile Devices Trends

Slide 21

Slide 21 text

Bring your own device (BYOD) Trends

Slide 22

Slide 22 text

Social Media Trends

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Not well, if at all 25

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

Baking in 27 • Baking in capabilities to the implant is sub- optimal for most situations • Reduce your ﬂexibility post-compromise • Can reveal an overall attack intent - Reverse engineering ﬁeld day

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

30 Technical Proof of concept

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

35 Python internals 101 Python Internals 101

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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 ﬁnd & load modules in non-standard ways   Importer protocol deﬁned in PEP302 37

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

Python internals 101 • The PEP 302 protocol deﬁnes   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

Slide 40

Slide 40 text

40 Python internals 101

Slide 41

Slide 41 text

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 ….

Slide 42

Slide 42 text

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 ﬁlesystem not memory • Re-implement the stdlib zipﬁle module in Python

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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 deﬁne goal at asset creation time 50

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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/ speciﬁc 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 …….

Slide 53

Slide 53 text

Userland execution • Allows execution through the replacement/modiﬁcation 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 ﬁlesystem mounts   Wanting to inject native code from a IL VM! 53

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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 ?

Slide 59

Slide 59 text

59 Demo Time!

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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