What did Clearhouse catch in 26 days?
In 26 days across an anonymized fleet of production Laravel applications, Clearhouse recorded 220,720 probes from 59,430 distinct addresses, served 94,570 fake configuration and credential files, caught 4,590 watermarked secrets being sent back, and handed out 302,630 hours of time out. At that pace, the fleet turns away more than 3.1M probes and hands out 1.3M decoy files a year.
| Measure | 26-day fleet total | Annualized pace |
|---|---|---|
| Scanner probes caught | 220,720 | 3,100,000+ |
| Distinct probing addresses | 59,430 | — |
| Fake decoy files served | 94,570 | 1,300,000+ |
| Watermarked secrets replayed and caught | 4,590 | 64,000+ |
| Hours of time out handed to scanners | 302,630 | 4,200,000+ |
Most production web logs treat background scanning as noise to ignore. When every request for /.env or /wp-login.php receives an ordinary 404, two questions go unanswered: what a scanner does once it thinks it found a credential file, and whether the thousands of addresses sweeping your sites are independent bots or the same operators rotating through cloud ranges.
How does Clearhouse tell a scanner from a visitor?
Clearhouse checks whether a request asks for software the application does not run. A Laravel application has no wp-login.php, no public .env, no .git/config, and no phpinfo.php. A real visitor who mistypes a link gets an ordinary 404 and is never counted, while a request for a known scanner path is handled in three steps.
- Spot the probe. Asking for a file the stack does not run records a strike in the application’s own log with the path, signature, and origin.
- Hand out a watermarked decoy. When a scanner requests
/.env,/.git/config,/.aws/credentials,/dump.sql,/.vscode/sftp.json, or/wp-login.php, Clearhouse returns a realistic fake file. Every password, token, and key inside is a cryptographic watermark generated fresh for that single request and tied to nothing. - Lock repeat offenders out. Three strikes in ten minutes, or any watermarked secret sent back to the site, puts the address in time out. Every page answers 403 until the timer expires: 30 minutes the first time, 4 hours the second, and 24 hours from the third on.
What happened to the fake secrets?
Watermarked decoy values were sent back to the fleet 4,590 times during the 26-day window. Most came from automated credential stuffers submitting the fake WordPress login form with its tagged hidden field, while 160 requests attempted to log in using database, mail, or control-panel credentials lifted from a decoy .env or installer file. Every one of those requests triggered an immediate time out.
| Replay request | Decoy source | Times caught |
|---|---|---|
POST /wp-login.php | WordPress login decoy | 2,840 |
POST /wordpress/wp-login.php | WordPress login decoy | 870 |
POST /cms/wp-login.php | WordPress login decoy | 570 |
POST /wp/wp-login.php | WordPress login decoy | 150 |
POST / | .env credential decoy | 90 |
POST /wp-admin/install.php | WordPress installer decoy | 50 |
POST /cpanel | .env credential decoy | 10 |
POST /login/ | .env credential decoy | 10 |
How do the bad actors connect across a fleet?
Four patterns tied separate addresses to the same operators across the fleet: coordinated single-day sweeps, identical ordered probe scripts, cross-site rotation across deployments, and watermarked canary secrets handed off from one address to another inside the same hosting network.
- Coordinated one-day sweeps. On October 29, strikes jumped to 20,630, more than three times the daily average of 6,228. Over 11,500 distinct addresses swept nearly every application in the fleet on that single day asking for
/wp-json/wp/v2/users, rotating through cloud ranges so no single address crossed a traditional per-IP rate limit. - Identical ordered probe scripts. Separate addresses across different autonomous systems walked the exact same five-file sequence in the same order within seconds:
/.env,/.git/config,/wp-login.php,/xmlrpc.php, and/.aws/credentials. - Cross-site rotation and browser spoofing. Across the window, 12,650 addresses probed multiple applications in the fleet, and 2,220 crossed separate deployments. Across all 220,720 probes, 83% (183,400 requests) sent a standard desktop browser user-agent string rather than identifying as a crawler or HTTP library.
- Reused watermarked secrets across addresses. Canary tokens issued to one scanner IP during a
GET /.envorGET /wp-login.phpprobe were replayed minutes later by a different IP in the same cloud provider range. Because each token is signed for the single request that generated it,clearhouse:tracelinks the harvesting address and the replay address without storing visitor data.
Do escalating time outs stop repeat scanners?
Yes: 84.6% of probing addresses never earned a second time out. Of the 59,430 addresses that probed the fleet, 30,380 (51.1%) were struck once or twice and stopped before reaching a time out, and 19,880 (33.5%) earned a single 30-minute time out and never returned.
| Address group | Addresses | Share of total |
|---|---|---|
| Struck once or twice, never timed out | 30,380 | 51.1% |
| Timed out once (30 minutes) | 19,880 | 33.5% |
| Timed out two to five times (4 hours to 1 day) | 8,060 | 13.6% |
| Timed out six or more times | 1,110 | 1.9% |
The remaining 9,170 addresses came back after their first lockout, earning 9,800 four-hour time outs and 10,300 full-day time outs, with 1,110 persistent addresses timed out six times or more. Once two separate deployments time an address out, Clearhouse’s shared blocklist turns that address away across every other application in the fleet before its first probe.