Change is constant, and mistakes happen
A configuration change ships, and it quietly exposes something it shouldn’t. No one is to blame — judging the risk of a newly exposed service is genuinely hard, and it is best assessed by offensive engineers. In a world of rapid deployment, governing every change across the enterprise is near impossible. Threat actors watch for those mistakes; so do we. The moment new or modified attack surface appears, we put offensive engineers on it.
In practice, we are continuously watching for:
- New or changed public-facing services
- Attack surface inherited through mergers and acquisitions
- Misconfigured firewalls and newly opened ports
- Exposed management interfaces — RDP, VNC and other admin consoles
- New network and hosting infrastructure
Scanning continuously — efficiently
Being first to new risk means always watching. Network services are exposed over IPv4 and IPv6, across TCP and UDP — 65,536 × 2 possible ports per address. Scanning all of that, all the time, is expensive, so we scan smart: the top 576 ports account for roughly 90% of services on the internet, letting us cut scanning effort dramatically while still catching what matters. Paired with cyber threat intelligence on the latest developing threats, a thoroughly mapped view of your services lets us answer fast: what here is vulnerable, and where must we act?
Purple teaming: we don’t have to play fair
Real attackers have to discover everything from the outside. We don’t — and that’s our advantage. By blending red and blue, offense and defense, we can cheat: instead of rediscovering every asset cold, we take asset lists straight from the defenders. That happens through APIs for pushing data, enumerating cloud deployments from the inside, or simply being told about new attack surface. Same targets as an attacker, but with a head start.
Attractiveness: do your assets make us drool?
Every network service we discover gets an internal attractiveness score that guides where our engineers spend their time — and new assets default to the highest score, forcing us to look at them first. It drives both human prioritisation and automation. We rate assets manually from 0 to 5:
- 5 — Very likely to interest attackers and us: known CVEs, obviously interesting, screaming to be tested.
- 4–3 — Interesting but not screaming: risky functionality like serialization or file uploads, custom code and configuration.
- 2–1 — Standard and default. Patched, governed, controlled — what a hacker would call boring.
- 0 — Out of scope, junk, noise.
What makes an asset attractive? Two things above all: brand new — fresh from the DevOps bakery, where we want to be first to find and demonstrate the risk — and old and outdated — the neglected, errored-out systems that look like they no longer belong on the internet.