Sparse-v2 C2 framework

• Design
• Developer setup
• Building
• Listeners, configurations, categories, templates, instances, commands
• Running
  • Deploying a beacon

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:

nix develop
setup-dev-environment

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:

nix build .#sparse-server-docker
docker load < result

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 use for HTTPS access for the beacons. For the most common use case of port 443, the following Docker compose file should work:

services:
  server:
    image: sparse-server:latest
    volumes:
      - ./files:/sparse-server
    ports:
      - '443:443'
      - '3000:3000'
    restart: always

Once deployed, add the first user with the following command:

docker compose exec server /bin/sparse-server user create -n USERNAME

Once deployed, the management interface is available at port 3000 over HTTP.

Deploying a beacon

• 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