Since the release of Empire at BSides Las Vegas, the project has received a lot of great feedback and use cases. While @harmj0y, @sixdub and myself worked really hard ondocumenting all of Empire’s features, there are a few tips and tricks that weren’t documented that can be of use. I wanted to cover some additional Empire functionality so you can get the most out of the framework.
Generating a Launcher
Empire stagers are the various methods you can use to trigger Empire agents on systems. The ‘launcher’ format generates the straight PowerShell one-liner to start the staging process, and one we commonly use in engagements as well as testing. If you are simply in need of the PowerShell one-liner, you can simply type “launcher <listenerName>” from the listener menu and this will quickly generate the one-liner for you. The listener names are tab-completable.
After receiving agents, there are also a few shortcuts that will help you easily with shell management. When an agent comes in, it will always have a randomized name. Since this can sometimes make for difficult agent identification, Empire allows you to rename agents using “rename <oldAgentName> <newAgentName>” from the agents menu:
Alternatively, you can do this within the context of an agent by typing “rename <newName>”.
When dealing with multiple agents, determining which ones are active and which ones have died can be accomplished by typing “list stale” in the agents menu. This will list any agents that are no longer active.
You can then remove all stale agents by typing “remove stale”:
You can also list any agents that haven’t checked in in a period of time by typing “list x”. X will be the minute window for the agent check-in. For example, “list 5” will list all agents that have called back in the last 5 minutes.
Mass Agent Configuration Changes
Empire also allows for basic configuration changes to multiple agents at once. You can accomplish this by typing “<command> all <parameter>”. For example, you can set the sleep for all agents to “0” by typing “sleep all 0”:
When searching for a specific process, Empire allows you to specify a process name with the “ps” command. To search for a specific process, you can simply type “ps <ProcessName>” to list all processes that contain that name.
High Integrity Agents*
Several Empire modules require a high integrity context in order to perform certain post-exploitation agents. For example, Empire supports the use of Mimikatz to obtain credentials from memory. High integrity agents will always be identified by an asterisk (*) next to the UserName, and this information can be seen as well by running info in an agent menu. You can check if your current user is a local administrator in a medium integrity context (meaning a bypassuac attack should be run) by running the privesc/powerup/allchecks module.
The Credential Store
Empire will automatically scrape/parse Mimikatz output and throw the results into an accessible credential module that’s stored in the backend database. You can view the credentials by typing “creds”.
Searching the Credential Store
The credential store will hold both hash and plaintext credentials. Empire allows for you to search/filter the credential store, so if you are looking for specific users, you can type “creds <searchTerm>” to show all credentials matching that term.
You can also filter by plaintext/hashes by typing “creds plaintext” (for all plaintext creds) or “creds hash” (for all hashes).
Adding Credentials to the Credential Store
If you have credentials that weren’t automatically added into the credential store, you can manually add them by typing “creds add <domain> <username> <password>”:
You can also remove credentials from the credential store by typing “creds remove <credID>/<credID-credID>/all”. You can remove a single credential by specifying the CredID, remove a set of credentials by specifying the range of CredIDs, or you can remove all credentials by specifying “all”.
Empire also allows you to export the credential store to a CSV. You can achieve this by typing “creds export <filePath>\file.csv”:
Each set of credentials is assigned a unique CredID, and you can use this CredID within modules that require credentials:
Alternatively, you can unset the CredID of a module by typing “unset CredID”. This can be used to unset any options that are set within a module. By using “unset”, it will clear out the value of the option specified.
You can also use the CredID with the “pth” command to execute use the Mimikatz PTH module with the credentials in the credential store.
You can then use “steal_token <pid>” to steal the token of the newly generated process.
Sometimes, things don’t always go your way. In the event of an Empire crash on the server side, you won’t lose all of your access. The agents will run in memory on the target and will keep calling home, even if your listeners are down. Empire utilizes a backend database that preserves Empire’s configuration (such as listeners). In the event of a crash, simply start empire back up and wait for your agents to check back in:
Once Empire fires back up, your agents will slowly begin to trickle back in. You can also manually browse the Empire database by opening SQLiteBrowser in Kali and pointing it to “/data/empire.db”. This will allow you to see what all Empire retains in the backend database as well as make changes:
These are just a few tips and tricks that we often use when interacting with Empire. Hopefully they are of some use as well! If anyone has any questions, issues, or pull requests, hit us up on Github or in the #psempire channel in Freenode.