Scanning & Enumeration
Building an accurate picture of what you actually expose — the first phase of both an assessment and an attack.
Authorisation First
The professional framing is simple. A defender scans their own estate to find what an attacker would find first. A tester scans a client's estate under a contract that says exactly which addresses are in scope. Everything outside that is not security work.
Scope creep is the practical risk: a shared hosting range, a cloud service you do not own, or a supplier's address that happens to answer. Confirm ownership of every target before touching it.
Asset Discovery
You cannot defend what you do not know you run. Most organisations are surprised by their own attack surface — a forgotten staging box, an expired subdomain still pointing at a cloud bucket, an admin panel exposed during a migration two years ago.
| Source | Reveals |
|---|---|
| DNS records and subdomain enumeration | Hosts that were never decommissioned |
| Certificate transparency logs | Every subdomain a certificate was issued for |
| Cloud account inventory | Resources created outside the main pipeline |
| Public code and package registries | Leaked internal hostnames and keys |
| Search engines and archives | Pages indexed before someone added auth |
Port & Service Scanning
Once you know the hosts, the question is what each one is listening on and what software answers. A scanner sends probes and interprets the responses: which ports are open, which service and version is behind them, and what the operating system looks like.
| Scan type | What it tells you | Cost |
|---|---|---|
| Host discovery | Which addresses are alive | Fast, quiet |
| Common-port scan | The obvious services | Fast |
| Full port scan | The service on an unusual port | Slow, noisy |
| Service and version detection | Exact software and version — the CVE lookup | Moderate |
| Script or plugin checks | Known weak configurations | Slower, more intrusive |
Scanning is noisy by nature, and that cuts both ways. As a defender, a scan of your own range is also a test of whether your monitoring notices — if nothing alerts, that is a finding in itself.
Vulnerability Scanning
A vulnerability scanner compares what it observes — versions, banners, configurations, responses — against a database of known issues. It is breadth, not depth: excellent at finding the unpatched and the misconfigured, and incapable of finding a logic flaw in your checkout.
| Strength | Limit |
|---|---|
| Covers thousands of known issues quickly | Only finds what is already in the database |
| Repeatable and schedulable | Cannot chain findings into an attack path |
| Good at patch and configuration drift | Blind to business-logic flaws |
| Cheap to run continuously | Produces false positives that need triage |
The valuable metric is not how many findings a scan produced but time to remediation for the ones that matter. A programme that generates 4,000 unread findings a month is theatre.
Reporting What You Found
Recon output is only useful when it changes something. A finding needs enough detail for someone else to reproduce it, an honest severity, and a concrete remediation.
| Field | Purpose |
|---|---|
| Asset and location | Exactly which host, service and endpoint |
| Evidence | The request and response, or the scanner output |
| Severity with reasoning | Impact and exploitability, not just a CVSS number |
| Exposure | Internet-facing, internal, or requires an account |
| Remediation | The specific change, not "apply best practice" |
| Owner | The team that can act on it |
Interview Questions
What has to be true before any scanning begins?
Written authorisation with a defined scope: named systems, an agreed window and a point of contact. Scanning outside that is unlawful in most jurisdictions regardless of intent.
Why is asset discovery the highest-value phase?
Unknown assets are not patched, monitored or backed up. Most organisations find their worst exposure is a host nobody knew was still running.
Open port, identified service, confirmed vulnerability — the difference?
Three separate claims of increasing strength. A port answering says little; a version banner suggests a CVE; only verification confirms exploitability, and only that justifies escalation.
What can a vulnerability scanner not find?
Business-logic flaws, broken access control specific to your model, and anything not already in its database. It gives breadth, not the depth of a manual test.
How should findings be prioritised?
By real exposure and impact rather than raw severity — an unauthenticated critical on an internet-facing service outranks the same CVE on an isolated internal host.
What does it mean if your own scan triggers no alerts?
The monitoring is a finding. Scanning your estate is also a test of detection, and silence means an attacker doing the same would go unnoticed.