e6530bcf20
specify in the example docker compose to use a container registry link as a shortcut around building
62 lines
3.3 KiB
Org Mode
62 lines
3.3 KiB
Org Mode
#+TITLE: Sparse-v2 C2 framework
|
|
|
|
* Design
|
|
Sparse v2 is a C2 beacon designed to weaponize libpcap to bypass local host based filtration and auditing. It writes and reads directly from the systems network interface card, creating an alternate TCP/IP stack that does not follow the same rules as the rest of the networking on the host system.
|
|
|
|
It is designed to take advantage of ideas put forward in this blog post: https://andrew.riouxs.co/articles/20251017-direct-network-access.html
|
|
|
|
* Developer setup
|
|
This project uses nix flakes. To set up a developer environment, install the Nix package manager (https://nixos.org/download/) and enable Flakes (https://nixos.wiki/wiki/Flakes). With these requirements met, run:
|
|
|
|
#+BEGIN_SRC sh
|
|
nix develop
|
|
setup-dev-environment
|
|
#+END_SRC
|
|
|
|
* Building
|
|
Building Sparse requires the same developer tooling that a developer shell requires, Nix configured to allow Flakes. To build sparse v2 in its entirety, run:
|
|
|
|
#+BEGIN_SRC sh
|
|
nix build .#sparse-server-docker
|
|
docker load < result
|
|
#+END_SRC
|
|
|
|
* Listeners, configurations, categories, templates, instances, commands
|
|
These are the abstractions used to represent beacons and the management of beacons deployed on a network.
|
|
- Listeners use a certificate authority and listen on a specific port to allow a beacon to perform callbacks. The port specified must not be changed by any NAT or port forwarding rule, and the IP address must be the public IP address before any NAT
|
|
- Configurations represent how a beacon should perform a callback, whether that is via a specific timetable or only once after executing. Also allows adding random jitter to the callback period
|
|
- Categories are used to sort incoming connections, and when issuing commands can expose a range of targets to apply the command to
|
|
- Templates represent the actual beacon that is to be installed on a system and all the configuration that comes with it
|
|
- Instances are callbacks created by a deployed beacon, and can be issued commands
|
|
- Commands are issued to beacon instances or categories
|
|
|
|
* Running
|
|
Running sparse will require knowing what ports to the beacons will connect to via HTTPS. For the most common use case of port 443, the following Docker compose file should work:
|
|
|
|
#+BEGIN_SRC yaml
|
|
services:
|
|
server:
|
|
image: gitea.riouxs.co/andrew.rioux/sparse-server:latest
|
|
volumes:
|
|
- ./files:/sparse-server
|
|
ports:
|
|
- '443:443'
|
|
- '3000:3000'
|
|
restart: always
|
|
#+END_SRC
|
|
|
|
Once deployed, add the first sparse management interface user with the following command:
|
|
|
|
#+BEGIN_SRC sh
|
|
docker compose exec server /bin/sparse-server user create -n USERNAME
|
|
#+END_SRC
|
|
|
|
Once deployed, the management interface is available at port 3000 over HTTP.
|
|
|
|
** Deploying a beacon
|
|
- Sign into the management interface of the sparse C2 server
|
|
- Add a listener with a port that matches the port specified in the docker compose and allowed through NAT, and use an IP address that can be routed to this C2 server
|
|
- Add a configuration to perform a periodic callback
|
|
- Add a template, selecting the prior listener and configuration. It will need an IP address that corresponds to the LAN that the beacon will be running on
|
|
- Download the beacon, and install it as a systemd service on Linux. It should be able to perform callbacks, even if blocked locally using iptables. Auditbeat will be unable to detect the beacon performing callbacks
|