Guide
Vulnerability scanner
The only tool here that sends traffic at a host. Prove you control the domain, then choose how loud to be.
The short version
- Type the domain. The page gives you a TXT record to publish at
_valhalla.<domain>. - Publish it, then press Check. The proof is read from the zone’s own nameservers, never a cache.
- Pick a pack. Heimdall is safe against anything you own; Ragnarök is loud and says so.
- Watch it run. Stop is a real stop — about a second from the button to a dead scanner.
- The PDF states how ownership was established. A reader can tell consent from an unsolicited scan.
The idea
Every other tool here reads something somebody published. This one sends traffic at a host, and the only thing separating security research from an unsolicited attack is consent. So consent is the first thing the tool establishes and the first thing its report states.
The traffic leaves from this server's address. The target's host, WAF and upstream
provider see scanning traffic from valhalla.thugs.red and will block or complain
accordingly. The DNS proof establishes that you consent; it does nothing about what their
provider thinks. That is why the request rate is deliberately low and why the loudest pack says so
in as many words.
Proving you control the domain
Type the domain. The page gives you a record to publish:
_valhalla.example.dk TXT valhalla-site-verification=<40 hex characters>Publish it in your zone, wait for it to propagate, and press Check. DNS is not instant, so this is a button rather than something checked on page load — a page that only checked once would be wrong most of the time.
How the check works, and why it matters
- The zone's own nameservers are asked directly, never a resolver. Caches sit everywhere between here and your zone, and a cached record would keep a domain "verified" after you deleted the proof — or after the domain changed hands.
- The token is specific to one account and one domain. A token you publish authorises nobody else, and a token for one domain proves nothing about a second.
- A nameserver that does not answer is unknown, not a denial. The failure message names which nameservers were asked, because "not verified" with no detail is the least actionable thing a DNS check can say.
- The check runs again immediately before the first packet. A scan can sit queued for minutes, and in that window a record can be pulled. Checking only at submission would make the control decorative.
Scope
A verified domain authorises itself and everything under it. Verify
example.dk and you can scan www.example.dk and api.example.dk.
The calculation is public-suffix aware, so verifying github.io cannot authorise
scanning somebody's project page.
Verified domains are remembered. Reuse one from the chips on the start page.
The bypass, if you hold it
Specialists and administrators can start a scan without a published proof. It exists because the real world has internal hosts with no public zone and engagements where DNS is somebody else's department.
The proof is still tried first for them. The bypass is a fallback for when there is no valid record, not a short-circuit around looking — so if you publish the record, your scan is recorded as proved and does not carry the badge.
When it is used it is never silent: the scan row records it, the results page carries a badge, the PDF opens with a box saying no proof was published, and an entry goes in the audit log with your name on it. A badge that is always on stops being read by the time it is true, which is exactly why it is not always on.
Choosing a pack
Norse names, because "aggressive-3" tells you nothing about what is about to happen.
| Heimdall | Looks and does not touch: what software is running, how TLS is configured, which files are exposed. Barely distinguishable from ordinary traffic. Safe against anything you own. |
| Bifrost | Heimdall plus misconfiguration and exposure — admin panels, forgotten paths, default credentials. Requests paths that do not exist, so it will fill the target's 404 log. |
| Mjölnir | The real vulnerability sweep: known CVE checks from low to critical. This looks like an attack to a WAF, because most of it is the same traffic an attacker would send. |
| Ragnarök | The full template set including fuzzing, plus a service scan of the open ports. Loud, slow, and the single most likely thing on this platform to earn an abuse complaint. Hours, not minutes. |
Start with Heimdall. It is not a lesser scan — most of what an attacker sees first is in it — and it tells you whether the target is worth the noisier packs.
Rate and concurrency
Both are clamped server-side whatever the form sends, because the traffic leaves this server's address and the ceiling is the platform's decision rather than yours. Turning them up on a small target mostly produces timeouts that look like findings.
What never runs, whatever you pick
No pack ever loads code templates. Nearly a thousand of those ship
upstream and they execute commands on this host, not on the target. They are excluded by
protocol at every tier, so a future default change upstream cannot switch them on.
Watching it, and stopping it
The results page streams. Findings arrive severity-first, so a critical arriving late does not land at the bottom of a long list, and the per-tool table shows which tools are running, done or failed.
Stop is a real stop. About a second from the button to a dead scanner, with no orphaned child processes — measured against a live run. The web request and the worker share no memory, so it works by setting a flag the worker polls.
One scan runs at a time, platform-wide. Two at once is not twice the throughput, it is twice the reason for somebody's upstream to blocklist this address. If your scan sits in queued, something else is running, or the worker is down — and the page says which.
Reading the results honestly
- A tool that failed is not a scan that found nothing. Each tool reports its own outcome, and a failure is shown as a failure. The same refusal-is-not-absence rule as everywhere else here.
- Findings are deduplicated by check and location. Without that, the scanner re-reports the same template for every redirect hop and every matched TLS version, which turned 11 real issues into 40 rows in testing.
- Every finding keeps the tool's own record of it, so a disputed result can be checked against what the tool actually said rather than against our reading of it.
- Severity is the template's claim. A critical against a staging box behind a VPN is not a critical in your environment. Read matched at before you read the colour.
The PDF
A GET under the scan's own URL. Its first page states how ownership was established, so a reader months later can tell an authorised test from a scan somebody pointed at a stranger. That is most of what makes the document worth anything.