Probe & Scanner Detection

Most detectors fire on traffic volume — "this ASN sent 12× its usual requests", "this path bypassed cache at 3× the rate". That works for scraping and credential stuffing, but it's blind to the activity that happens before those attacks: reconnaissance.

A scanner looking for soft targets fires single requests at dozens of well-known probe paths — /wp-login.php, /.env, /backup.zip, /phpmyadmin, /.git/config, /wp-content/upgrade/alfacgiapi. Each individual probe is tiny (often under 50 requests/week across your whole tenant). No volume-based detector would ever fire. Yet the structural signature — many distinct probe paths, across several probe families, from one ASN in one hour — is unambiguously hostile.

That's what the probe detector catches.

How it works

Edge tracks failed requests (4xx and 5xx) separately, classifying each into one of seven probe families:

• wordpress — anything matching wp-login, wp-admin, wp-content, wp-includes, wlwmanifest.xml, xmlrpc.php, or similar.
• env_secrets — .env variants (.env.production, /app/.env, /backend/.env, /laravel/.env, etc.).
• git_repo — /.git/config, /.git/HEAD.
• alfa_webshell — ALFA Team webshell fingerprints (alfacgiapi, ALFA_DATA). These scanners specifically look for sites already compromised by someone else so they can piggyback.
• sql_dump — dump.sql, backup.zip, database.sql, wp-config.php.bak, etc.
• admin_panel — phpmyadmin, adminer.php, /administrator, phpinfo.php, /vendor/phpunit/phpunit.
• tenant_targeted — a probe path that contains your brand's name as a substring (e.g. /yourbrand-db.sql). This is the most important signal: a generic kit fires the same URLs at every site, but a tenant-targeted probe means somebody already knows you.

Known probe fingerprints are priority-tracked so they never get lost among legitimate 4xx noise (missing images, expired deep links), no matter how busy your site is.

When it trips

The detector evaluates each (ASN, country) pair over a rolling 60-minute window. It fires on any of three independent signals:

1. 20+ distinct probe paths from one ASN → warning. Classic scanner fingerprint.
2. 3+ distinct probe families from one ASN → critical regardless of request count. Cross-category scanning demonstrates more capable tooling.
3. Any tenant_targeted probe at count ≥ 1 → critical immediately. A scanner using your brand name is far more specific than a generic kit.

The alert's context includes a breakdown of families, example probe paths per family (up to three per family), and the full probe and total-4xx request counts, so you can see at a glance what the scanner was looking for.

When it does NOT trip

• A real user hitting a single missing asset (/us/old-campaign) — one path, no family match, no trip.
• Your own health-check or synthetic-monitor hitting a deprecated URL repeatedly — even at high volume, no family match.
• A single 4xx noise source on one family only — min_distinct_paths guards against overfiring on one-off 4xx anomalies.

What to do when it fires

The standard mitigation is a rate-limit on the ASN (not a block). Scanner ASNs are often shared with legitimate traffic — AWS, DigitalOcean, Hetzner, OVH — and blocking the whole range will hit real users. A rate-limit at, say, 10 requests/minute is lethal to a scanner without affecting humans.

If you see tenant_targeted hits:

1. Treat as a targeted-recon event — note the ASN and the exact path patterns probed.
2. Audit that those filenames do not, in fact, exist on your origin. (Shouldn't, but worth confirming.)
3. Rotate any credentials that historically existed in an .env or similar configuration file on this origin at any time.
4. Consider extra access controls on admin-style paths.

Probes are cheap to ignore if your origin is hardened. The alert's biggest value is longitudinal — who keeps probing you, and when do they escalate to something else? The ASN Recurrence detector watches exactly that.