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.

Building an Empire with PowerShell


Published on

This presentation covers the release of Empire, a pure PowerShell post-exploitation agent. It was given at BSidesLV '15.

Published in: Technology
  • Be the first to comment

Building an Empire with PowerShell

  1. 1. Building an Empire with PowerShell Will Schroeder, Justin Warner Veris Group’s Adaptive Threat Division (ATD)
  2. 2. First Things First ○ This tool and presentation would not be possible if it wasn’t for the help and phenomenal work from these people: □ @mattifestation and @obscuresec ○ □ @carlos_perez / □ @tifkin_ / □ @ben0xa and @mwjcomputing □ @enigma0x3 - The ATD Padawan □ And the rest of the offensive PowerShell community! All you guys rock!
  3. 3. @harmj0y ○ Security researcher and red teamer for the Adaptive Threat Division of Veris Group ○ Co-founder of the Veil-Framework and PowerTools ○ Cons: Shmoocon, Carolinacon, Defcon, Derbycon, various BSides
  4. 4. @sixdub ○ Red Team Capability Lead for the Adaptive Threat Division of Veris Group ○ Lots of interest: red team ops, reverse engineering, adversarial tactics, etc ○ Developer on the Veil-Framework and co- founder of PowerTools
  5. 5. tl;dr ○ Red Team Philosophy ○ (Offensive) PowerShell ○ RATs 101 ○ Empire ○ Modules ○ Demo ○ Taking Down the Empire ○ The Future
  6. 6. Red Team Philosophy In Defense of Offense
  7. 7. Red Teaming ○ Red teaming means different things to different people □ physical ops, in-depth social engineering, custom exploit dev, pure network based operations, etc. ○ Common thread of increased time frame, more permissive scope and adversarial mentality ○ We have a ‘assume breach’ perspective □ It’s not a matter of ‘if’, but ‘when’
  8. 8. Malware Motivations ○ Why did we decide to go custom? □ Clients were signaturing tool sets □ Needed rapid dev capability while on ops to integrate unique vulnerabilities ○ And chance to build the RAT features we always wanted □ Wanted a better way to utilize existing PowerShell capabilities ○ Attempt at solving the “weaponization problem”
  9. 9. In Defense of Offense ○ We want to help secure companies against the level of threat that they’ve been unknowingly facing for over a decade □ So we need to be able to simulate at least some of the actions of these advanced groups. ○ There is a balance between making OSS useable for training and making the “next- gen rootkit”
  10. 10. (Offensive) PowerShell “Microsoft’s Post-Exploitation Language” -@obscuresec
  11. 11. Why PowerShell ○ PowerShell provides (out of the box): □ Full .NET access □ application whitelisting □ direct access to the Win32 API □ ability to assemble malicious binaries in memory □ default installation Win7+ ! ○ “Why I Choose PowerShell as an Attack Platform” □ Choose-PowerShell.html
  12. 12. “Bad Guys”
  13. 13. Existing Tech ○ PowerSploit □ Screenshots, keylogging, Mimikatz, etc. ○ PowerView □ Network situational awareness ○ PowerUp □ Privilege escalation ○ PowerBreach □ Additional persistence ○ Posh-SecMod □ Lots of goodies
  14. 14. The Weaponization Problem ○ There’s been an sharp increase in offensive PowerShell projects over the past year ○ But many people still struggle with how to exactly work PowerShell into engagements ○ Using existing tech at this point hasn’t always been the most straightforward □ This is the problem we’re trying to solve!
  15. 15. RATs 101 I smell a RAT….
  16. 16. Just RAT Things... ○ RAT vs Backdoor… Yes they differ ○ What different things do you need to focus on when building a RAT? □ Delivery □ Staging & C2 □ Modularity / Expandability □ Forensics □ The list goes on!!!
  17. 17. The Staging Problem ○ Exotic C2 channels are nice, but somehow your agent code has to get to your target ○ This is often the most vulnerable point of your entire process □ staging can be be noisey □ some kind of logic needs to be sent “in the clear” □ stager needs to be able to detect and utilize proxies as best as possible
  18. 18. Command & Control ○ What are the characteristics of moderate to advanced malware out there? □ Asynchronous ○ Low and slow wins the race □ Variable comms ○ HTTP, HTTPS, DNS, SMB, etc. □ Flexible indicators ○ Survivability across defensive sensors or boundary defensive solutions □ Proxy awareness!
  19. 19. Extensibility ○ The core agent should be as small as possible with only required functionality ○ It is best to make an module interface to allow an operator to add/subtract features □ Follow on payloads, scripts, persistence modules ○ The modules can be loaded and removed during use
  20. 20. Wait… What? ○ Empire is a full-featured PowerShell post- exploitation agent ○ Aims to provide a rapidly extensible platform to integrate offensive/defensive PowerShell work ○ An attempt to train defenders on how to stop and respond to PowerShell “attacks” □ Another tool in the belt!
  21. 21. PowerShell = Just a Toy Language? ○ Many people have written off PowerShell as being a real malware solution because it is a scripting language □ “Easy” to defeat/block the interpreter ○ This has also caused incident responders to overlook it as a malware vector □ Helpful if we provide some real world demos :)
  22. 22. Server Features ○ Client-Server architecture □ Server = Python | Client = PowerShell ○ A backend database preserves agent/listener configurations □ In case something goes down, your agents won’t! ○ Everything is logged, extensively □ Taskings/results per agent, along with timestamps □ Hashes of any files uploaded to target □ --debug will dump a ton of output to empire.debug
  23. 23. Methods of Execution ○ Small “stager” that can be manually executed or easily implemented elsewhere □ A powershell command block can load an Empire agent □ Generated per listener inside the menu ○ Stager Formats: □ .vbs (macro), .bat, ducky script, etc. □ Reflective Pick .DLL - Allows integration with many other tools like MSF
  24. 24. Listeners ○ The “server” side of the whole system □ Configuration of the agent set here
  25. 25. Additional Listener Stuff ○ IP whitelisting/blacklisting dynamically or by a common config ○ Kill dates and working hours nicely integrated into listener management ○ “foreign listeners” allow the passing of agents within the team □ and to other agents like Meterpreter/Beacon!
  26. 26. Empire Staging Control Server Client 2. return key negotiation stager.ps1 w/ shared AES staging key 3. gen priv/pub keys, post ENCstaging(PUB) to /<stage1> 5. decrypt session key, post ENCsession(sysinfo) to /<stage2> 6. return ENCsession(agent.ps1) patched with key/delay/etc. and register agent. Agent starts beaconing. 1. GET /<stage0> 4. return ENCpub(epoch + AES session key)
  27. 27. C2 ○ Utilizes the .NET backend with HTTP or HTTPS ○ Nothing too magical here… □ “Get” request is looking for tasking □ “Post” is returning encrypted results
  28. 28. In the Agent: Contexts ○ Shell - Run Empire or PowerShell cmds ○ Scripts - Import and run PowerShell cmdlets ○ Modules - Utilize pre-built functionality to execute PowerShell functions across agents ○ More later during the demo...
  29. 29. Modules Because an agent actually needs functionality
  30. 30. Modules ○ Currently 90 released modules □ several more in testing testing ○ First round of modules focused on integrating all of the current projects □ Wanted an operational beta to use in real environments ○ We will show some of the top used ones…
  31. 31. Module Categories ○ Currently have the following categories for modules: □ code_execution - ways to run more code □ collection - post exploitation data collection □ credentials - collect and use creds □ lateral_movement - move around the network □ management - host management and auxiliary □ persistence - survive the reboot □ privesc - escalation capabilities □ situational_awareness - network awareness □ trollsploit - for the lulz
  32. 32. Module Development ○ Development is extremely fast due to the wealth of existing PowerShell tech and the ease of development in a scripting language ○ Modules are essentially metadata containers for an embedded PowerShell script ○ Things like option sets, needs admin, opsec safe, save file output, etc
  33. 33. management/ psinject ○ First up: our auto-magic process injection module for Empire □ Takes a listener name and an optional process name/ID ○ Uses Invoke-PSInjector to inject our ReflectivePick .DLL into the host or specified process □ The launcher code to stage the agent is embedded in the .DLL
  34. 34. ReflectivePick *.exe Invoke-PSInjector ReflectivePick .NET Assembly Download Cradle
  35. 35. Invoke- PowerCeption?
  36. 36. PowerShell in LSASS? lol
  37. 37. Invoke-BypassUAC ○ Second, we need a way to escape medium-integrity process contexts ○ The .DLL used by Metasploit’s bypassuac_injection is open source, and works when combined with PowerSploit’s Invoke--Shellcode.ps1 □ Works on Win 7 and 8.1! ○ Lets us spawn high-integrity agents
  38. 38. Invoke-Mimikatz ○ Everyone's favorite post-exploitation capability ○ Not just dumping creds: □ Golden tickets □ Silver tickets □ PTH □ Skeleton key ○ Empire has Internal credential model □ Lets you easily reuse creds you’ve stolen
  39. 39. Invoke-WMI ○ Invoke-WMIMethod is our primary way of moving around □ Can take a listener name and transform it into configurations for a launcher □ Fairly lightweight and safe to use ○ Uses PowerShell’s Invoke-WMIMethod to run the launcher code on a remote host
  40. 40. PTH ○ “But what about pass-the-hash?!!” ○ The credentials/mimikatz/pth module (alias- pth) lets you spawn a new process with a local or domain user’s hash □ You can then use the credentials/tokens module to steal the token from this new process ○ Lets you execute whatever actions you want with just a hash
  41. 41. Demo
  42. 42. Taking Down the Empire How to Find and Stop Us
  43. 43. Detection ○ The typical network indicators will reveal some things □ Not as proxy aware as some agents □ High entropy byte strings in HTTP POSTs ○ Endpoint indicators are plentiful: □ Prefetch with PowerShell □ .NET Assemblies loaded into odd processes □ The list goes on…
  44. 44. Umm… Weird?
  45. 45. Memory Analysis ○ Memory analysis will reveal the entire Empire agent plaintext in memory □ No obfuscation is done at this point □ Allows the extraction of AES keys ○ Decryption of malware C2 □ Useful for a red team because it rewards IR teams to take the next step and chain analysis
  46. 46. Yes… plaintext
  47. 47. Windows 10 :) ○ “ZOMG HACKING IS OVER!!” - harmj0y ○ But for real… major improvements in the security and monitoring of PowerShell □ Who knows when/how clients will actually implement the added features ○ Initial testing: □ Logging is very very noisy with Empire □ Constrained mode might be circumvented with PowerPick
  48. 48. The Future The Shiny Shiny Future
  49. 49. Moving Forward ○ We’ve released full documentation and demo videos hosted at □ There’s also a formal spec on the agent and its associated protocol □ All future updates will be posted here ○ This will be a long-running and fully supported project
  50. 50. Dream Capabilities ○ New C2 methods □ SMB, DNS, SOCKS Proxying etc ○ Script obfuscation/mangling to help prevent memory parsing and to increase training value ○ Contribute modules! it’s super easy
  51. 51. @harmj0y @sixdub Any questions?