The document discusses PowerShell Empire, a PowerShell post-exploitation framework that aims to provide a flexible and extensible platform for integrating offensive PowerShell capabilities. It provides an overview of Empire's architecture, including its client-server design with a backend database, listeners for command and control, and modules for additional functionality. The document demonstrates Empire's capabilities through modules for process injection, privilege escalation, credential dumping, and lateral movement. It also discusses considerations for detecting and analyzing Empire agents on compromised systems.

1. Building an Empire
with PowerShell
Will Schroeder, Justin Warner
Veris Group’s Adaptive Threat Division (ATD)

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
○ https://github.com/mattifestation/PowerSploit/
□ @carlos_perez / https://github.com/darkoperator/
□ @tifkin_ / https://github.com/leechristensen/
□ @ben0xa and @mwjcomputing
□ @enigma0x3 - The ATD Padawan
□ And the rest of the offensive PowerShell
community! All you guys rock!

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. @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. tl;dr
○ Red Team Philosophy
○ (Offensive) PowerShell
○ RATs 101
○ Empire
○ Modules
○ Demo
○ Taking Down the Empire
○ The Future

6. Red Team
Philosophy
In Defense of Offense

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. 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. 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. (Offensive)
PowerShell
“Microsoft’s Post-Exploitation Language”
-@obscuresec

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”
□ http://www.exploit-monday.com/2012/08/Why-I-
Choose-PowerShell.html

12. “Bad Guys”

13. Existing Tech
○ PowerSploit
□ Screenshots, keylogging, Mimikatz, etc.
○ PowerView
□ Network situational awareness
○ PowerUp
□ Privilege escalation
○ PowerBreach
□ Additional persistence
○ Posh-SecMod
□ Lots of goodies

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. RATs 101
I smell a RAT….

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

21. 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!

22. 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 :)

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

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

25. Listeners
○ The “server” side of the whole system
□ Configuration of the agent set here

26. 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!

27. 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)

28. C2
○ Utilizes the .NET backend with HTTP or
HTTPS
○ Nothing too magical here…
□ “Get” request is looking for tasking
□ “Post” is returning encrypted results

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

30. Modules
Because an agent actually needs
functionality

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

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

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

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

35. ReflectivePick
*.exe
Invoke-PSInjector
ReflectivePick
.NET Assembly
Download Cradle

36. Invoke-
PowerCeption?

37. PowerShell in
LSASS? lol

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

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

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

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

46. Demo

47. Taking Down
the Empire
How to Find and Stop Us

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

49. Umm… Weird?

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

51. Yes… plaintext

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

53. The Future
The Shiny Shiny Future

54. Moving Forward
○ We’ve released full documentation and
demo videos hosted at
www.PowerShellEmpire.com
□ 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

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

56. @harmj0y
@sixdub
https://github.com/powershellempire/empire
www.PowerShellEmpire.com
Any questions?