Scan a web application end to end
Four workflows against one application, in an order that matters. Each stage writes into the same asset graph, so the vulnerability scan tests endpoints that were actually found rather than paths it guessed at.
Contents
Before you start
- A node online. If you have not got that far, start with the first scan tutorial.
- A web application you own, and its base URL.
1Crawl it first
Operations, then Workflows, then New web crawl. Give it the base URL as a seed and set the scope so it stays on the hosts you mean. The crawl follows the application the way a browser does, and what it produces is the endpoint and parameter surface: a method against a path, with the fields that path takes.
You should seeEndpoints and operations under Intel, then Assets, rather than a list of URLs.
2Find what nothing links to
A crawl only reaches what the application points at. New content discovery brute-forces the rest from a wordlist, paced to what the target tolerates rather than at a fixed rate you guessed. Skip this on a small app and come back to it when you care about coverage.
You should seePaths that the crawl never reached, merged into the same graph.
3Fingerprint what you found
New service enumeration takes the hosts and services already in the graph and works out what is running and at which version. That is worth having on its own, and it is also what turns a version number into a CVE lead for the next stage.
You should seeTechnology and version on your services, with CVE leads attached.
4Scan for vulnerabilities
New vulnerability scan, which walks through targets, severity, templates, nodes and config. Because the three earlier stages ran, it tests real endpoints with real parameters. Leave out-of-band confirmation on: blind classes like a blind SSRF have no visible response, and the interaction is the only proof there is.
You should seeFindings with a severity and a confidence, and the confirmed ones saying so explicitly.
5Look at the shape, not just the rows
Intel, then Attack surface, draws the same graph as a map. It is the fastest way to notice the host nobody remembered, the admin interface on an odd port, or the subdomain that answers but should not.
You should seeOne picture of the application instead of four separate result sets.
When it does not work
Why not run the vulnerability scan on its own?
You can, and it will work. It will also be testing whatever it can find by itself, which on a modern application is a fraction of the surface. The order is the point: cortex is only as good as what mach and scout put in the graph before it.
The crawl found almost nothing
Usually one of two things. The application is behind a login, in which case you want the authenticated scanning tutorial. Or it renders client-side and the crawl needs the browser tier to see what the page builds after it loads.
Do I have to re-run everything to re-test?
No. Assets are content-hashed at ingest, so a re-run produces a typed diff rather than a duplicate set. Re-run the stage you care about and read the change feed.
Next: Read your findings