SpiderFoot

• In the Azure Portal, search the Marketplace for SpiderFoot | Support by SecureAnyCloud and select Create.
• Choose your subscription, resource group and region.
• Set the VM size to Standard_B2ms or larger.
• Under Administrator account, select SSH public key and supply your own key.
• Under Inbound port rules, allow HTTP (80) and SSH (22). Before the VM is created, tighten both rules to your own address ranges on the networking blade.
• Leave the OS disk at its default. Select Review + create.

# Create the VM from the sac image.
az vm image terms accept --urn sac1647283583153:spiderfoot-ubuntu-24-04:default:latest
az vm create \
  --resource-group my-resource-group \
  --name my-spiderfoot \
  --image sac1647283583153:spiderfoot-ubuntu-24-04:default:latest \
  --size Standard_B2ms \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_rsa.pub \
  --public-ip-sku Standard
# Then open the two ports you need, scoped to YOUR OWN network rather than the
# internet. These commands run on your workstation, not on the appliance. MY_CIDR="203.0.113.0/24"
# replace with your own range
az network nsg rule create \
  --resource-group my-resource-group \
  --nsg-name my-spiderfootNSG \
  --name allow-ssh-from-office --priority 1000 \
  --source-address-prefixes "${MY_CIDR}" \
  --destination-port-ranges 22 --protocol Tcp --access Allow
az network nsg rule create \
  --resource-group my-resource-group \
  --nsg-name my-spiderfootNSG \
  --name allow-http-from-office --priority 1010 \
  --source-address-prefixes "${MY_CIDR}" \
  --destination-port-ranges 80 --protocol Tcp --access Allow

ssh azureuser@<vm-ip>

First boot generates this VM's two credentials and proves the access gate before anything is allowed onto port 80. Give it a minute or so after the VM first comes up.

# All three must report active. spiderfoot-firstboot is a oneshot that stays
# "active (exited)" once it has completed successfully.
systemctl is-active spiderfoot.service spiderfoot-firstboot.service nginx.service
# The gate's own health literal. This is the ONLY unauthenticated route on the # appliance, and it never reaches SpiderFoot, so it discloses nothing.
curl -s http://127.0.0.1/nginx-health
# SpiderFoot must be on loopback only, and nginx must be the only listener on 80.
sudo ss -lntp | grep -E ':(80|5001)\b'

You should see SpiderFoot on 127.0.0.1:5001 and nginx on 0.0.0.0:80. SpiderFoot is never published directly, and there is no route to it that skips the gate.

Both passwords were generated on this machine, at this boot, and exist nowhere else. Nothing in this file was baked into the image. Read the file:

sudo cat /root/spiderfoot-credentials.txt

SPIDERFOOT_URL=http://<vm-ip> SPIDERFOOT_UNLOCK_URL=http://<vm-ip>/sac-unlock
# 1. The sac gate (the browser's FIRST prompt) GATE_USERNAME=sac GATE_PASSWORD=<GATE_PASSWORD> # 2. SpiderFoot's own sign-in (the SECOND prompt) SPIDERFOOT_USERNAME=sfadmin SPIDERFOOT_PASSWORD=<SPIDERFOOT_PASSWORD>

Open http://<vm-ip>/sac-unlock first, not http://<vm-ip>/. Step 7 explains why. Following this order makes the sign-in flow work first time in every browser.

• Your browser prompts for the SecureAnyCloud gate credentials. Enter GATE_USERNAME and GATE_PASSWORD. You see a short confirmation page.
• Follow the Continue to SpiderFoot link. Your browser now prompts a second time. This prompt shows the realm as 127.0.0.1. This is correct: it is SpiderFoot identifying itself by the loopback address it is bound to. Enter SPIDERFOOT_USERNAME and SPIDERFOOT_PASSWORD.
• The SpiderFoot interface loads, with no scans, no targets and no API keys.

This appliance has two independent authentication layers. Understanding them explains the two prompts and the unlock URL.

Why SpiderFoot must never run unauthenticated. SpiderFoot enables its own authentication only if a password file exists. Without one, it does not merely leave the UI open. Measured on the stock upstream project, an anonymous POST /startscan returns 303 and a scan actually starts. Anyone who could reach the port could make your VM scan anything, from your IP address. The requests that appear to be rejected are in fact missing-argument errors, not authentication denials.

This appliance therefore never runs SpiderFoot without its own password file. The service is held on a systemd condition that refuses to start it if that file is missing or malformed.

Layer 1: the SecureAnyCloud gate. nginx on port 80 is the sole ingress and denies by default at server scope, so every route inherits the gate: the interface, all forty-one of SpiderFoot's exposed endpoints, and its static assets. Exactly one route is unauthenticated, /nginx-health. It is a static literal that never reaches SpiderFoot.

Layer 2: SpiderFoot's own sign-in. It is left enabled, with a per-VM password. Passing the gate alone gets you SpiderFoot's own 401, and no further.

Why there is an unlock URL. SpiderFoot's own authentication is HTTP Digest, and the gate is HTTP Basic. Both schemes travel in the same Authorization request header, and a browser can send only one at a time. A gate that demanded Basic on every request would therefore deadlock. The browser sends Basic, and SpiderFoot demands Digest. The browser sends Digest and drops the Basic header, and the gate demands Basic. This repeats forever.

The gate solves this by making its Basic requirement conditional on a per-VM cookie that is issued when you authenticate. Visiting /sac-unlock obtains that cookie in one clean step. After that, the single Authorization header is free to carry SpiderFoot's Digest credentials, and the interface works normally.

None of this weakens the gate. You can prove that from the appliance itself:

# Every route is closed to an anonymous caller with exactly 401 — including the
# endpoint that starts scans, which stock upstream answers with 303 and a
# running scan. for p in / /modules /scanlist /startscan /optsraw /static/css/spiderfoot.css; do printf '%-32s %s\n' "$p" \
  "$(curl -s -o /dev/null -w '%{http_code}' "http://127.0.0.1$p")" done
# The gate credential ALONE reaches SpiderFoot's own challenge and no further. # Expect 401, with a Digest challenge — that is layer 2 doing its job. GU=$(sudo grep -m1 '^GATE_USERNAME=' /root/spiderfoot-credentials.txt | cut -d= -f2-) GP=$(sudo grep -m1 '^GATE_PASSWORD=' /root/spiderfoot-credentials.txt | cut -d= -f2-)
curl -s -o /dev/null -D - -u "$GU:$GP" http://127.0.0.1/ | head -1
curl -s -D - -o /dev/null -u "$GU:$GP" http://127.0.0.1/ | grep -i '^www-authenticate'
# And a VALID SpiderFoot credential with no gate cookie is still refused, so the
# gate cannot be bypassed just by switching authentication scheme. Expect 401.
SU=$(sudo grep -m1 '^SPIDERFOOT_USERNAME=' /root/spiderfoot-credentials.txt | cut -d= -f2-)
SP=$(sudo grep -m1 '^SPIDERFOOT_PASSWORD=' /root/spiderfoot-credentials.txt | cut -d= -f2-)
curl -s -o /dev/null -w '%{http_code}\n' --digest -u "$SU:$SP" http://127.0.0.1/

Re-read the authorisation notice at the top of this guide before you start. A good first target is a domain that you own.

• Select New Scan.
• Give the scan a name, and enter your target in Scan Target. SpiderFoot detects the target type automatically.
• Choose how to scan. By Use Case is the simplest starting point.
• Select Run Scan Now. The scan page updates as results arrive.

The use cases are:

• Passive: never contacts the target directly. Choose it when you want to stay entirely off the target's logs. It is also the right choice for a first run.
• Footprint: maps the target's externally visible network and web presence.
• Investigate: Footprint plus reputation and malicious activity checks.
• All: every module that applies. This is thorough, and by far the heaviest. See Step 9.

Results are grouped by type. Select any type to see the individual findings and, for each one, the module and source that produced it. Graph draws the relationships between findings, and the export buttons produce CSV, JSON or GEXF for tools such as Gephi.

A completed scan looks like this. Findings are grouped by type, with the number of unique results and the module that produced each one:

Start with Passive on a target you own. It gives you a feel for the output and the runtime without touching the target at all.

Standard_B2ms (2 vCPU, 8 GiB) is the recommended size. A concrete measurement stands behind that recommendation, not a guess.

A single All use case scan on the build machine saturated both vCPUs hard enough to make other work on the VM sluggish. SpiderFoot runs many modules concurrently, and most of them are network-bound. But parsing, correlating and writing results is real CPU work, and a broad scan does a great deal of it.

The honest envelope for Standard_B2ms is:

• One scan at a time, with a moderate module selection (Passive, Footprint, or a hand-picked module list).
• An All scan completes, but expect the appliance to be busy for the duration. Do not plan to run anything else alongside it.
• Do not run several scans concurrently on this size.

If you need concurrent scans, or routinely run All against large targets, move to Standard_B4ms (4 vCPU, 16 GiB) or larger. Scan storage is modest, because results are text in a SQLite database. CPU, not disk, is what you are buying.

# Watch what a scan is actually costing you while it runs. top -b -n 1 | head -15
# The database grows with results; check it between scans.
sudo du -sh /var/lib/spiderfoot/

A number of modules need an API key for a third-party service, and every key field in this image is empty. This is deliberate. SecureAnyCloud never bakes a credential into an image, and a shared key would be both a leaked secret and a rate limit that you would share with strangers.

SpiderFoot works well with no keys at all. The module library loads in full, and the passive and footprinting use cases are productive without any. To add your own keys:

• Open Settings.
• Find the module in the list on the left and enter your key in its API Key field.
• Select Save Changes.

Keys are stored in this VM's own SQLite database at /var/lib/spiderfoot/, which is 0700 and owned by the spiderfoot account, so other local users cannot read them.

Be aware of what a keyed module discloses. Querying a third-party service about a target tells that service that you are interested in that target. Choose your modules accordingly.

Everything below ships in the image, so you can audit it without contacting us.

# The exact upstream commit, tree, and a content manifest of the shipped source.
cat /usr/share/spiderfoot/source-provenance.txt
# Third party notices, including the two copyleft dependencies and the bundled
# wordlist's advertising acknowledgment obligation. less /usr/share/spiderfoot/THIRD-PARTY-NOTICES # Every Python distribution in the image and the licence signal it published. column -t -s $'\t' /usr/share/spiderfoot/dependency-licences.txt | less # The exact resolved version of every dependency.
cat /usr/share/spiderfoot/python-requirements.lock
# Re-run the licence gate yourself. It exits non-zero on any AGPL, SSPL, BUSL,
# Elastic v2, Commons Clause, non-commercial, PolyForm, Prosperity or RSAL
# licence, and fails closed on anything it cannot resolve.
sudo /opt/spiderfoot/venv/bin/python \
  /usr/share/spiderfoot/spiderfoot-licence-gate.py

The application is MIT licensed, Copyright 2022 Steve Micallef. MIT permits use, modification, distribution and sale, and the full text ships at /opt/spiderfoot/app/LICENSE.

The bundled ispell wordlist at /opt/spiderfoot/app/spiderfoot/dicts/ispell/ is four-clause BSD, Copyright 1993 Geoff Kuenning. Redistribution is permitted, but clause 4 requires an advertising acknowledgment. The shipped notices discharge this requirement, and the acknowledgment is reproduced here:

This product includes software developed by Geoff Kuenning and other unpaid contributors.

The Python dependencies were examined by an executable licence gate at build time: 62 distributions, zero restrictive licences, zero unresolved. Two carry file-level copyleft: certifi and publicsuffixlist, both MPL-2.0 and both unmodified. There is no AGPL code, and in particular no PyMuPDF. The PDF text extraction path in this image is PyPDF2, which is BSD-3-Clause.

One dependency was deliberately removed. Upstream's requirements.txt lists pygexf, which is GPL-3.0. Nothing in SpiderFoot imports it. The GEXF export you use is networkx's BSD-3-Clause writer, and pygexf is not even importable on Python 3.

Leaving it out removes a copyleft obligation at no functional cost, and the build proves that by generating a real GEXF graph without it. Your Graph view and GEXF export are unaffected.