beacon-client
The command beacon-client
can be used to connect to a Cobalt Strike Team Server given a beacon config or payload.
It will read the beacon settings so it can communicate with the C2 server, and then it will start do check-ins and
retrieve Tasks like a real beacon.
Tip
If you enable -v / --verbose
logging, and you have the rich
module installed. It will automatically
use rich to render the console logging which can be easier on the eyes.
The implementation of the client in beacon-client
is observing only, meaning it does not implement any of the
beacon functionality such as executing commands or listing files and does not send any Callback data to the Team Server.
If you want to know how to implement your own custom beacon client that can respond to tasks, please refer to this tutorial.
The --writer
parameter of beacon-client
allows you to log the retrieved beacon tasks to a file.
This can be useful for debugging or logging of tasks that are being sent.
The output is written as flow.record records and can be dumped using the tool rdump
which is part of
the flow.record package and is installed as a dependency.
To ensure you have all the dependencies for beacon-client
you can use the following pip command:
$ pip install -e dissect.cobaltstrike[c2]
Here is an example usage of connecting to a Team Server with custom Beacon metadata, we choose a fixed beacon id so we can connect to it again later without creating a new beacon session at the Team Server:
$ beacon-client beacon.bin -vi 1234 --user "wing" --computer "safecomputer" -w c2.records.gz
This will launch the beacon-client using
beacon.bin
as the BeaconConfig.The
-v
flag will enable verbose logging. (recommend to see what is going on)The
-i
flag will set the Beacon ID to1234
.The
--user
and--computer
arguments are used to set the username and computer name in the Beacon Metadata.and
-w
or--writer
writes decrypted C2 packets such as Tasks and Callback packets to the filec2.records.gz
.
There are many more options that can be overridden, by default most settings are randomized. To see all the options run
it with --help
and is also documented here: beacon-client - CLI interface.
Dumping saved records
The contents of c2.records.gz
can then be dumped using the rdump
(record dump) tool:
$ rdump c2.records.gz
For more advanced usage of rdump
use --help
or see the documentation for flow.record.
If beacon-client
is not in your path, you can also run the command using the following Python module:
$ python -m dissect.cobaltstrike.client --help
beacon-client - CLI interface
beacon-client [-h] [-d DOMAIN] [-p PORT] [--sleeptime SLEEPTIME] [--jitter JITTER]
[-c COMPUTER] [-u USER] [-P PROCESS] [-i BEACON_ID] [-I INTERNAL_IP]
[--arch {x86,x64}] [--barch {x86,x64}] [--high-integrity] [-n] [-w WRITER] [-v]
[-s] [--no-warning]
BEACON
beacon-client positional arguments
BEACON
- beacon to use as configuration (default:None
)
beacon-client options
--no-warning
- disable connect warning
beacon-client beacon communication
beacon-client beacon sleep options
--sleeptime
SLEEPTIME
- override sleeptime settings (in milliseconds) (default:None
)--jitter
JITTER
- override jitter settings (in percentage) (default:None
)
beacon-client beacon metadata
-c
COMPUTER
,--computer
COMPUTER
- computer name (None = random) (default:None
)-u
USER
,--user
USER
- user name (None = random) (default:None
)-P
PROCESS
,--process
PROCESS
- process name (None = random) (default:None
)-i
BEACON_ID
,--beacon-id
BEACON_ID
- beacon id (None = random) (default:None
)-I
INTERNAL_IP
,--internal-ip
INTERNAL_IP
- internal ip (None = random) (default:None
)
beacon-client beacon metadata flags
--arch
ARCH
- system architecture (None = random) (default:None
)--barch
BARCH
- beacon architecture (None = random) (default:None
)--high-integrity
- set high integrity flag