1) Deploy an Attack Vector

1) Deploy an Attack Vector

The Attack Vector runs the BlackNoise events. It is deployed on your network to execute the offensive actions defined by the chosen scenario and the campaign settings.


Setup has three stages: prepare a host, open the required network flows, then install and register the Attack Vector from the web app.


1. Prepare the host

Hardware and software requirements

The Attack Vector is a Docker container, so you need a machine, the host, that can run Docker.
Hardware:
  • CPU: x86_64 or ARM
  • RAM: 2 GB
  • Storage: 16 GB
Software:
  • Operating system: Linux (recommended) or Windows
  • Docker: Docker Engine v27.0.0 or above

General host settings

  • The Attack Vector uses the host's IPv4 address; configure DHCP or a static IP as needed.
  • If the host has several network interfaces, assign the default route to only one, otherwise the Attack Vector will not operate correctly.
  • For virtual machines, set the network interface to bridge mode.
  • Configure a running NTP service for accurate, continuous time synchronization.
  • Configure an internal DNS service for name resolution of your other servers and workstations.

Set up a Linux host

    Install a Linux distribution (Debian, Ubuntu, RedHat, Fedora, etc.).
    Install Docker Engine from Docker's official repository, not from your distribution's packages. See  https://docs.docker.com/engine/install .

Set up a Windows host

On Windows, the recommended approach is to run a Linux virtual machine and then follow the Linux steps above:
    Install VirtualBox.
    Download a Linux install image (for example Ubuntu Desktop or Server).
    Create a VM with that OS and set its network interface to bridge mode.
    Install Docker from the project repository (not the distribution packages). If you have no Internet access during installation, temporarily switch the VM network to NAT mode.
If you cannot run a virtual machine, two alternatives are supported: a WSL2 Linux distribution running Docker Engine (preferred), or Docker Desktop with WSL integration. Neither of them attaches the container to your LAN, so in both cases the source IP reported for events in BlackNoise is not the IP address of the Windows machine, and the two setups do not report the same address. Take this into account when reading results and when writing detection rules based on the source address.

Alternative 1: WSL2 distribution with Docker Engine

Installing Docker Engine inside the distribution gives you a standard Linux Docker setup, identical to the one described above, with no additional abstraction layer between the container and the engine.
    Install a distribution from a Windows terminal: wsl --install -d Ubuntu . Confirm it runs in version 2 with wsl -l -v .
    Enable systemd in the distribution so the Docker service starts automatically. Add a [boot] section containing systemd=true to /etc/wsl.conf , then run wsl --shutdown from Windows to restart the distribution.
    Install Docker Engine from Docker's official repository, not from the distribution's packages, following  https://docs.docker.com/engine/install  for the exact steps.
Important. Enabling systemd disables the mechanism WSL uses to run Windows executables from Linux. If the installation then fails on a credential error, see Windows interoperability broken in a WSL2 distribution in the Troubleshooting section.

Alternative 2: Docker Desktop with WSL integration

Install Docker Desktop for Windows and enable the integration for your distribution in Settings > Resources > WSL Integration. The engine then runs in Docker Desktop's own distribution rather than in yours.
  • The source IP shown for events in BlackNoise will be the Docker eth0 interface (typically 192.168.65.3 ), not the host IP.
  • Because Windows does not always recognize the && separator, you may need to split the generated command into two parts ( docker login , then docker run ).


2. Open the network flows

Flow matrix prerequisites

The Attack Vector connects to the BlackNoise platform over HTTPS. Open the following flows from the host:
  • Protocol: HTTPS (TCP/443)
  • Domains:  in.blacknoise.co , *.in.blacknoise.co,  registry.blacknoise.co 
  • Direction: outgoing
No protocol break. The HTTPS connection must not be decrypted by any intermediate device. TLS inspection breaks the end-to-end channel the Attack Vector needs to communicate securely with the platform.

Validate the network prerequisites (recommended)

Before installing, run the BlackNoise connectivity-check script on the future host to confirm the required flows are open. Use the version matching the host OS. The script tests the network layer only, it does not check Docker or other system prerequisites.
  • bn-check-av-connectivity-requirements.sh (Linux / macOS)

bn-check-av-connectivity-requirements.sh
16KB, Uploaded last month
  • bn-check-av-connectivity-requirements.ps1 (Windows)

bn-check-av-connectivity-requirements.ps1
16KB, Uploaded last month


3. Install the Attack Vector

    In the web app, go to Resources > Attack Vectors and click Create attack vector (top right).
    Give the Attack Vector a name (alias). The Docker container is generated from this alias.
    Optionally, set advanced options — proxy, DNS, NTP (see Advanced options below).
    Copy the generated docker command and run it in the host's terminal. The host must already be connected to the network with an IP address, or the Attack Vector will not initialize.
    The Attack Vector appears in the web app list; the container image downloads and starts. Once it authenticates with the web app, it turns operational (green dot) and can be used in an attack campaign.


Advanced options: proxy, DNS, NTP

Set these when creating the Attack Vector; the web app injects them into the generated docker command.
Proxy: enable the Use a proxy option. Connection path: Attack Vector → Proxy → Web app.
  • HTTP_PROXY: IP or hostname for port 80 — http://<ip-or-hostname>:<port>
  • HTTPS_PROXY: IP or hostname for port 443 — http://<ip-or-hostname>:<port> or https://<ip-or-hostname>:<port>
  • NO_PROXY: addresses that must bypass the proxy — keep the auto-filled values
The Attack Vector does not support proxy authentication (allow unauthenticated connections to the BlackNoise web app), and does not support TLS decryption at the proxy (the proxy must not decrypt this traffic).
DNS: enable the Use a DNS option. The Attack Vector then uses this DNS server instead of the host's system DNS.
NTP: enable the Use an NTP option. The Attack Vector then uses this NTP server instead of the host's system NTP.

https://slite.com/api/files/3BllhFw6s_3A2n/Capture%20d%E2%80%99e%CC%81cran%202026-04-28%20a%CC%80%2014.18.07.png?apiToken=eyJhbGciOiJIUzI1NiIsImtpZCI6IjIwMjMtMDUtMDQifQ.eyJzY29wZSI6Im5vdGUtZXhwb3J0IiwibmlkIjoiM2VFSE9abXo0ZExaYTciLCJpYXQiOjE3ODkxNTUyODksImlzcyI6Imh0dHBzOi8vc2xpdGUuY29tIiwianRpIjoiQ1o2NFFCZGlKdjk2eDYiLCJleHAiOjE3OTE3NDcyODl9.HH7SfnZRuzfD6YpwGAnl6ErxjdKtRTlYJXvwHZdm_B4


Update an Attack Vector

A red star next to the version number means a new version is available. Updating gives access to the latest features, to the most up-to-date event list, and to event-execution improvements. The update path depends on the version currently installed.
The latest version is required. An Attack Vector that is not running the latest available version can no longer be used: creating a campaign, launching a new simulation and testing the connection to a System Target are all blocked until it is updated. The web app states this clearly and points to the update, so the action can be resumed as soon as the Attack Vector is back to Operational on the new version.
Before version 1.3.10. These Attack Vectors cannot be updated from the web app. Open the Attack Vector details: a yellow banner titled An update is available for your Attack Vector appears at the top of the modal and gives the docker command to apply the new version. Copy it and run it in the host terminal, exactly as during installation. Once the new container starts and authenticates with the platform, the Attack Vector returns to the Operational status with its new version.
From version 1.3.10. The update is triggered from the web app. Open the Attack Vector details and click Update version. It runs automatically and may take a few minutes depending on your connection and the host performance. The Attack Vector moves to the Upgrading status while its main code and modules are replaced, then returns to Operational — see  Attack vectors  for the full status list.
From version 1.4.7. The web app also follows the update in detail: it reports the progress of each step of the process, so you can see how far the update has gone and where it stopped if it does not complete.


Troubleshooting

Permission denied on the Docker socket (Linux). If you see permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock, your user lacks Docker rights. Add it to the docker group, then restart the system:
sudo usermod -aG docker your-username

TLS certificate error during installation. If running the docker command returns tls: failed to verify certificate: x509: certificate signed by unknown authority, the HTTPS connection cannot be established. Two possible causes:
  • A network device is inspecting HTTPS traffic — turn off inspection, or allow the BlackNoise flows without decryption.
  • The host clock is incorrect — fix the system time, or set an NTP server for the Attack Vector.

Attack Vector not operational. Run the diagnostic tool:
  • From the host (container installed but not operational): docker exec -it <attack_vector_identifier> ./diagnose.sh. Find the identifier in Resources > Attack Vectors, Identifier column.
  • From the web app (operational / green): open the Attack Vector details, select the Diagnose tab, then Launch diagnose.
The diagnostic reports network setup and test results (Internet access, connection to the BlackNoise platform) to help pinpoint the issue.

Windows interoperability broken in a WSL2 distribution. If the docker command returns error saving credentials - err: fork/exec /usr/bin/docker-credential-desktop.exe: exec format error, the Docker client is trying to run Docker Desktop's Windows credential helper and the distribution can no longer execute Windows binaries. This happens when systemd is enabled in the distribution: it remounts binfmt_misc at boot and clears the WSLInterop handler that WSL registers to run .exe files from Linux.
Confirm the handler is missing, then register it again:
ls /proc/sys/fs/binfmt_misc/
sudo sh -c 'echo ":WSLInterop:M::MZ::/init:PF" > /proc/sys/fs/binfmt_misc/register'
Check the result with cmd.exe /c ver: if the Windows version is displayed, interoperability is restored and the docker command completes. This registration does not survive a restart of the distribution. To make it permanent, create a systemd unit that registers the handler at each boot:
sudo tee /etc/systemd/system/wsl-binfmt.service > /dev/null <<'EOF'
[Unit]
Description=Re-register WSLInterop after systemd
After=systemd-binfmt.service
Requires=systemd-binfmt.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c 'echo ":WSLInterop:M::MZ::/init:PF" > /proc/sys/fs/binfmt_misc/register'

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl enable wsl-binfmt.service
Two alternatives avoid the problem instead of fixing it: remove systemd=true from /etc/wsl.conf if the distribution does not need it, or remove the credsStore entry from ~/.docker/config.json so the Docker client stores credentials in the file itself. The second option resolves the login only and leaves Windows interoperability unavailable for everything else.