Two Clocks: Campaigns 126 and 157, and What Six Weeks of the Front Door Revealed

TI-2026-059F · Series: The Front Door · Classification: HIGH · Confidence: HIGH

The capstone of The Front Door series. Five dossiers followed five intent classes. This one steps back to the campaign layer — 124 coordinated operations the platform has clustered from six weeks of web-edge telemetry — and uses the two campaigns we were asked to examine, 126 and 157, to show that they are not two attacks but two settings of one dial.

Executive Summary

Behind the raw traffic sits a detector that groups coordinated activity into campaigns. As of this writing it has clustered 124 campaigns, covering 1,181 IPs with 1,758 memberships — meaning IPs recur across campaigns, and that recurrence is itself an operator fingerprint.

It clusters them by exactly three signatures:

temporal_burst          81 campaigns   (spin up, fire, vanish)
shared_exploit_paths    37 campaigns   (same wordlist, many flags)
empty_ua_asn_cluster     6 campaigns   (one header, one ASN, persistent)

Those three methods are not an implementation detail. They are the observable shadow of three ways coordinated web attacks are actually run — and each one is a dossier in this series. The two campaigns at the centre of this report, 126 and 157, sit at opposite ends of the same model: the persistent botnet and the ephemeral flash. Same cloud, same reputation-renting logic, two clock-speeds.

The Two Clocks

Campaign 126 is the marathon. Two hundred Azure nodes, unified by a single blank User-Agent, quietly hunting webshells across the internet for three weeks. It maximises coverage over time: keep a steady footprint, sweep everything, stay under the radar of anyone watching for spikes.

Campaign 157 is the sprint. Thirty-three Google Cloud VMs blink into existence, each fires roughly ninety distinct secret-file requests in about two seconds, and the whole operation is over in ten hours. It maximises evasion through speed: complete the survey before any reputation system can react, then discard every address.

They look like different threats. They are the same operator's model at two settings of a dial — and an operator can turn that dial at will.

The Same Cloud Underneath Both

The top campaigns by volume tell one story over and over:

Microsoft Azure (AS8075) dominates the leaderboard, and it appears in both detection classes — persistent empty-UA botnets and temporal bursts. That is the 059B finding confirmed at campaign scale: the same disposable cloud, run at both clock-speeds, is the engine of the modern web threat. Google Cloud supplies the sprints (157); AWS supplies a share of the harvest (059A). The hyperscalers are not the victims here. They are the launch pad.

What the Series Adds Up To

Five dossiers, one conclusion. Laid end to end:

• 059A — The Secret Harvest. The dominant web threat is not login brute force but exposed-secret exfiltration, cloud-hosted and ephemeral, its wordlist already updated for AI keys.
• 059B — The Azure Shell Game. The shell-upload surface is one empty-UA Azure botnet (campaign 126) hunting reusable backdoors, not planting new ones.
• 059C — Mapping the Estate. "CMS detection" is a cross-continent xmlrpc hunt for brute-force amplification and DDoS reflection, one operation wearing 28 flags.
• 059D — Scanners in the Mirror. The noisiest class is a triage bucket the auth proxy creates; honest reading separates real crawlers from five-identity impostors.
• 059E — The Keys Left in the Door. /.git/config outdraws /.env because it leaks the whole repo and its deleted history; specialists sit on documented bulletproof hosts.

The unifying architecture is a two-tier structure: a disposable, reputation-renting hyperscaler layer on top (Azure, GCP, AWS) for volume and evasion, and a thin, persistent bulletproof shell layer underneath (TechTies in Seychelles, Cloudzy/RouterHosting) for durability and monetisation. The cloud IPs rotate; the shells are the fixed point.

Read Between the Lines

Q: If IPs recur across 124 campaigns, why not just build a great blocklist? Because the recurrence is mostly in the shells and signatures, not the cloud endpoints — and the cloud endpoints are the volume. By the time an Azure or GCP address earns a place on your blocklist, the campaign that used it has ended and the address may now serve a legitimate customer. A blocklist of ephemeral hyperscaler IPs is a museum of addresses the attacker has already thrown away. The 1,758 memberships prove the operators recur; the individual IPs do not.

Q: Which is more dangerous — the persistent botnet or the ephemeral burst? Wrong question; they cover for each other. The burst out-runs reputation systems (gone before you can list it); the persistent botnet out-waits rate limiters (too slow to trip a spike alarm). A defence tuned to one is blind to the other. That complementarity is exactly why the operator keeps both in the toolkit — and why only detection that spans both timescales, keyed on behaviour rather than identity, actually works.

Q: The honeypot watched port 22 for years. Did the threat really move? The brute-forcers never left the back door — but the interesting money moved to the front. SSH brute force is a slow, expensive gamble on a weak password. The front-door model is a fast, cheap survey for an exposed secret that hands over a root cloud credential outright. Same operators, better economics, a different port. The Front Door series is the record of where they went.

The Alternative Interpretation

Steelman the deflation: 124 "campaigns" could be an artefact of an over-eager clustering algorithm — coincidental co-occurrence dressed up as coordination.

It is the right worry, and the data answers it. Coincidence does not produce 200 IPs sharing a single empty User-Agent in one ASN (126). Coincidence does not spin up 33 VMs in one cloud inside ten hours firing identical 90-path sweeps (157). Coincidence does not make a Hong-Kong shell and a Russian host fire the same ten xmlrpc paths in the same window (059C). Each detection method requires a specific, improbable agreement — same header, same burst window, same bespoke wordlist — that random background traffic does not generate. The clustering is conservative by construction, and 059D shows the platform is honest about its own false positives. The campaigns are real; the deflation does not survive the specifics.

Verdict

Campaigns 126 and 157 are the two clock-speeds of a single cloud-abuse model — persistent and ephemeral — and the 124-campaign taxonomy shows that model is the norm, not the exception, at the web edge. The series' cumulative finding is blunt: IP reputation is a dead control. The attacker rents reputable, disposable cloud compute on top of persistent bulletproof shells, and defeats any defence that keys on who is connecting. What actually caught them — every time — was keying on what they did: CrowdSec path-and-velocity signatures enforced at layer 3 by MikroTik. Confidence: HIGH on the model, the taxonomy and the reputation-is-dead conclusion; MEDIUM on single-operator attribution beneath the shell layer.

Defensive Response

• Defend by signature and behaviour, not identity. Path patterns, request velocity, header fingerprints, and coordination signatures survive IP rotation; blocklists do not.
• Span both timescales. Combine burst-rate detection (for sprints) with slow-and-low signature matching (for persistent botnets); neither alone is sufficient.
• Aim takedown at the shell layer. Attribution and abuse pressure concentrate on the persistent bulletproof ASNs (TechTies, Cloudzy), not the endlessly-rotating cloud endpoints.
• Enforce automatically at layer 3. The durable win in this series was CrowdSec decisions pushed to MikroTik address-lists — detection wired directly to enforcement, faster than any human triage.

Sources

• LSN web-threats platform — campaign taxonomy (124 campaigns / 1,181 IPs / 1,758 memberships), campaigns 126 and 157, top-volume campaign ranking (Traefik + CrowdSec + MikroTik).
• The Front Door series: TI-2026-059A (Secret Harvest), 059B (Azure Shell Game), 059C (Mapping the Estate), 059D (Scanners in the Mirror), 059E (Keys Left in the Door).
• Sysdig — EmeraldWhale — https://www.sysdig.com/blog/emeraldwhale
• Imperva — Was That Really a Googlebot? — https://www.imperva.com/blog/was-that-really-a-google-bot-crawling-my-site/
• Breakglass Intelligence — Cloudzy / RouterHosting analysis — https://intel.breakglass.tech/post/competent-malware-incompetent-infrastructure-a-vipkeylogger-operator-builds-a-steganographic-kill-chain-leaves-xampp-dashboard-open-and-leaks-their-own-smtp-credentials

Investigation TI-2026-059F · The Front Door series (finale) · 124 campaigns, three detection signatures, two clock-speeds · Capstone synthesis of 059A–059E · Confidence: HIGH.