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.binas the BeaconConfig.The
-vflag will enable verbose logging. (recommend to see what is going on)The
-iflag will set the Beacon ID to1234.The
--userand--computerarguments are used to set the username and computer name in the Beacon Metadata.and
-wor--writerwrites 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
--sleeptimeSLEEPTIME- override sleeptime settings (in milliseconds) (default:None)--jitterJITTER- override jitter settings (in percentage) (default:None)
beacon-client beacon metadata
-cCOMPUTER,--computerCOMPUTER- computer name (None = random) (default:None)-uUSER,--userUSER- user name (None = random) (default:None)-PPROCESS,--processPROCESS- process name (None = random) (default:None)-iBEACON_ID,--beacon-idBEACON_ID- beacon id (None = random) (default:None)-IINTERNAL_IP,--internal-ipINTERNAL_IP- internal ip (None = random) (default:None)
beacon-client beacon metadata flags
--archARCH- system architecture (None = random) (default:None)--barchBARCH- beacon architecture (None = random) (default:None)--high-integrity- set high integrity flag