Tutorial 1 of 6 · About 15 minutes, most of it waiting

Run your first scan

From an empty account to hosts landing in your asset graph. The one thing worth knowing before you start: Crossfyre does not scan from our infrastructure. You enrol a machine you control, and scans leave from your address.


Contents

Before you start

  • One Linux host with Docker and root. A small VPS is enough, and the box under your desk works too.
  • A domain you own, or one you have written permission to test.

1Get a machine ready

This is first because it is the part people are surprised by. The platform schedules work; your machine does it. Install Docker on the host if it is not there already, because the engines keep scan state in a local database the CLI runs as a container.

curl -fsSL https://get.docker.com | sh

You should seeDocker running, and root on the host.

2Install the CLI and sign in

One installer, then authenticate. login takes an API key, a username and password, or it can open a browser. Nothing else in the CLI works until it succeeds, which is deliberate.

curl -fsSL https://get.crossfyre.io/install.sh | sudo bash
crossfyre login

You should seeThe CLI confirms who you are signed in as.

3Create the node in the dashboard

Go to Arsenal, then Nodes, then Deploy a node. Pick the engines you want on this host. The node key is shown once and not again, so copy it before you leave the page.

You should seeA node in the list, marked offline, waiting for its first heartbeat.

4Bring the node online

Back on the host. This installs the engines you selected, provisions the local database and registers the OS service.

sudo crossfyre node init

You should seeThe dashboard flips the node to online within a few seconds. If it does not, run crossfyre doctor before changing anything.

5Run something small

Operations, then Workflows, then New subdomain enumeration. The wizard walks through domains, mode, wordlists, nodes and engine settings. Start with passive mode only: it needs no wordlist, it finishes in under a minute, and its output is what every later stage works from. crossfyre run does the same thing from the terminal.

You should seeThe workflow moving through its stages, with hosts appearing while it runs.

6Read the result

Hosts land in Intel, then Assets, as they are found rather than at the end. Anything the run decides is a problem lands in Intel, then Findings, with a severity and a confidence. If the connection drops partway, the workflow resumes rather than restarting.

You should seeSubdomains in the asset graph, each carrying the source that confirmed it.

When it does not work

The node never goes online

crossfyre doctor checks the things that are usually wrong: Docker not running, the service not registered, or outbound connectivity blocked. The node dials out to the platform, so it does not need any inbound port open.

The scan will not reach anything beyond my target

That is the default and it is on purpose. A scan reaches its own target host and nothing else. To let a run follow something into a range you own, add it under Arsenal, then Authorised scope.

Can I point this at a site I do not own?

No. The vulnerability engine sends real payloads at real applications. Run it against assets you own or have written permission to test, and nothing else.

Next: Scan a web application end to end