Client

[!NOTE]

The CLI Client was the first interface created for the Empire C2 suite but is no longer the recommended method of interacting with the Empire server. Starkiller has replaced the CLI client as a modern interface and is now the recommend method of interacting with the Empire server.

The Client configuration is managed via empire/client/config.yaml.

Once launched, Empire checks for user write permissions on paths specified in config.yaml. If the current user does not have write permissions on these paths, ~/.empire will be set as fallback parent directory and the configuration file will be updated as well.

• servers - The servers block is meant to give the user the ability to set up frequently used Empire servers.

  If a server is listed in this block then when connecting to the server they need only type: connect -c localhost.

  This tells the client to use the connection info for the server named localhost from the yaml. In addition, if autoconnect is set to true, the client will automatically connect to that server when starting up.

  servers:
  localhost:
    host: https://localhost
    port: 1337
    socketport: 5000
    username: empireadmin
    password: password123
    autoconnect: true

• suppress-self-cert-warning - Suppress the HTTP warnings when connecting to an Empire instance that uses a self-signed cert.

• auto-copy-stagers - Automatically copy generated stager text to the clipboard.

• directories - Control where Empire should read and write specific data.

• mouse-support - Enable/disable mouse functionality for the client.

directories:
  downloads: empire/client/downloads/
  generated-stagers: empire/client/generated-stagers/

• tables - Enable or disable borders around tables

tables:
  borders: true

• logging - See Logging for more information on logging configuration.

logging:
  level: INFO
  directory: empire/client/downloads/logs/

Shortcuts

• shortcuts - Shortcuts defined here allow the user to define their own frequently used modules and assign a command to them.

Let's look at 3 distinct examples. All of which can be found in the default config.yaml

This first example is the simplest example. It adds a sherlock command to the Interact menu for Powershell agents. It does not pass any specific parameters.

shortcuts:
  powershell:
    sherlock:
      module: powershell/privesc/sherlock

This next one is slightly more complex in that we are telling the shortcut to set the Sleep parameter to 1. Note that if there are any other parameters for this module that we don't define, it will use whatever the default value is.

shortcuts:
  powershell:
    keylog:
      module: powershell/collection/keylogger
      params:
        - name: Sleep
          value: 1

This third one gets a bit more complex. Instead of providing a value to the parameter, it is marked as dynamic. This tells the client that it expects the user to send the parameters as part of their command. In other words, the user needs to type bypassuac http1 in order for this to execute. The parameters are passed in the order they are defined in config.yaml. There are some convenient autocompletes if the field is named Listener or Agent.

shortcuts:
  powershell:
    bypassuac:
      module: powershell/privesc/bypassuac_eventvwr
      params:
        - name: Listener
          dynamic: true

The last one is much more simple. Instead of running a module, we run a shell command.

shortcuts:
  powershell:
    whoami:
      shell: whoami