Letter A of The Web Siege — a forensic series documenting the multi-vector attacks observed at our Traefik ingress layer during June 2026.

Unlike our previous honeypot dossiers — which captured SSH brute-force operators, Outlaw botnets, and IRC-controlled cryptominers — this series shifts the lens to the HTTP attack surface. The layer where every web application lives. The layer where a single misconfigured deployment can expose database credentials, API keys, payment tokens, and the keys to entire cloud infrastructures.

What we found was not random noise. It was an economy.

Data source: 87,883 requests from 4,446 unique IPs captured by our Traefik reverse proxy → Loki log aggregation → web_threats PostgreSQL pipeline over 25 days. Cross-referenced with SSH honeypot (threat_intel DB, 8,000+ IPs), CrowdSec threat intelligence, MikroTik address lists, and entity crosslinks (Qdrant vector store, 15,392 relationship edges).

Before we show you the attack, you need to understand the target.

A .env file is the standard way modern web applications store their secrets. Every Laravel app, every Node.js API, every React frontend that talks to a backend — they all use .env files to hold the credentials that make everything work. Database passwords. AWS keys. Stripe payment tokens. JWT signing secrets.

The security model is simple: the .env file should never be accessible via the web. Your .gitignore excludes it from version control. Your web server should refuse to serve it. In theory.

In practice? Developers make mistakes. A misconfigured Nginx. A Docker build that copies the entire project root into the public directory. A .env.bak file created during debugging and forgotten. A staging server with directory listing enabled.

The attackers in this dossier know this. They don't need to exploit a vulnerability. They don't need a zero-day. They just need one misconfigured server out of the millions they scan. And when they find it, they get everything.

Beginning June 8, 2026, our automated campaign detection algorithm flagged something unusual.

It wasn't a single scanner. It wasn't the background radiation of the internet. It was coordinated: 5-12 Google Cloud Platform IPs appearing within minutes of each other, all requesting the same exhaustive list of .env path variants, then vanishing. Forever. The next day, entirely new IPs. Same behavior. Same paths. Same ASN.

Jun 08 14:23:17 traefik GET /.env                34.129.126.223 → 404  [AS396982]
Jun 08 14:23:17 traefik GET /.env.local           34.118.27.145  → 404  [AS396982]
Jun 08 14:23:18 traefik GET /.env.production      34.176.151.233 → 404  [AS396982]
Jun 08 14:23:18 traefik GET /laravel/.env         34.125.48.170  → 404  [AS396982]
Jun 08 14:23:18 traefik GET /app/.env             34.151.74.196  → 404  [AS396982]
Jun 08 14:23:19 traefik GET /.env.backup          34.104.178.132 → 404  [AS396982]
Jun 08 14:23:19 traefik GET /backend/.env         136.110.87.228 → 404  [AS396982]
Jun 08 14:23:19 traefik GET /.env.bak             136.110.77.61  → 404  [AS396982]

All 404s. Our infrastructure returned nothing. But the pattern told us everything about the attacker.

7 campaigns. 54 unique IPs. Zero reuse. Someone was burning through Google Cloud instances like matchsticks — and they'd been doing it for three weeks before we even noticed.

This is not a script-kiddie's wordlist downloaded from GitHub. This is compiled operational intelligence — a carefully curated enumeration covering every major web framework's .env convention, plus the backup patterns that lazy developers create:

What this wordlist tells us about the operator:

• They know Laravel, Express, React, Vue, Django, Symfony, Rails, and Docker directory conventions
• They target backup artifacts (.bak, .old, .save, ~) — demonstrating awareness that developers rename files instead of deleting them
• They check environment-specific variants (.production, .staging, .development) — knowing these often contain the most sensitive credentials
• They probe monorepo structures (/backend/, /api/, /server/, /src/) — modern architecture awareness
• This wordlist is the product of operational experience, not theoretical knowledge. Someone built this by analyzing which paths actually return results across thousands of targets.

This is the operational signature that elevates this from "noisy scanner" to "professional operation":

Every single IP was used for exactly one day. Not approximately one day. Exactly.

54 IPs. 54 single-day lifespans. Zero reuse across the entire 19-day observation window.

Think about what this means operationally:

• The operator has a reliable pipeline for creating and destroying cloud instances daily
• By the time any threat feed or blacklist adds the IP, it's already been destroyed
• Traditional IP-based blocking is completely useless against this operator
• The only effective detection is behavioral: catching the pattern, not the specific IP

At an average of 7.7 IPs per campaign day and ~117 requests per IP, each instance lives for approximately 4-6 hours before termination. The infrastructure cost is negligible: at $0.01/hour for GCP e2-micro instances, the entire 3-week operation cost less than $15.

While analyzing individual IP behavior, we caught one of the broader .env scanning network (a DigitalOcean IP, not the Google Cloud fleet) demonstrating the user-agent rotation toolkit in a single burst. IP 104.248.56.87 sent 21 requests in 0.63 seconds:

21 requests. 7 identities. Under 1 second. The same machine pretending to be an Android phone, then ChatGPT, then Chrome on Windows, then Firefox, then Googlebot, then Safari on Mac.

The choice of ChatGPT-User and Googlebot is particularly revealing:

• Googlebot is whitelisted by virtually every WAF and bot-detection system — nobody wants to accidentally block Google's crawler
• ChatGPT-User is a newer UA that many systems have whitelisted to allow AI crawling — a fresh trust vector being exploited
• This tells us the scanning tool is actively maintained and adapts to current trust relationships in the security ecosystem

The 361 unique IPs we observed scanning for .env files are not a single operation. When we decomposed them by behavior, infrastructure, and cross-referenced with our SSH honeypot, three entirely distinct operational tiers emerged:

Why the SSH overlap matters:

Our Cowrie SSH honeypot captures brute-force attackers separately from the web layer. When an IP appears in both datasets, it means the same machine is running both HTTP .env scanning AND SSH password guessing — a "multi-vector" attacker that throws everything at every target.

The Google Cloud fleet has zero such overlap. The Advin fleet has 100%. This single datapoint proves they cannot be the same operator. They represent entirely different business models in the underground economy:

• Tier 1 (Google): A specialized credential theft service. They only do HTTP. They only target .env. They invest in OPSEC. They sell credentials.
• Tier 3 (Advin): A general-purpose botnet. They attack everything — SSH, HTTP, whatever ports are open. They sell access, not specific data.

We cross-referenced all 54 Google Cloud campaign IPs against our Cowrie SSH honeypot — a dataset containing 8,000+ unique attacker IPs accumulated over 5 months of continuous operation:

Zero. Not one. Out of 54 IPs that scanned our web layer, not a single one ever attempted SSH login.

Now compare with Advin Services (AS22295) — the "criminal multi-vector" tier:

This is not coincidence. This is operational doctrine. The Google Cloud operator understands something that the Advin botnet does not: SSH scanning gets you blacklisted fast. CrowdSec, fail2ban, and every security tool on Earth watches SSH. By avoiding SSH entirely, the Google operator stays below the radar of most automated defenses.

They sacrifice the additional attack surface in exchange for longevity and stealth. That's a trade-off only a professional makes.

How does one acquire 54 disposable Google Cloud IPs over three weeks?

The most elegant possibility is a self-reinforcing loop: harvest .env files → steal GCP credentials from them → use those credentials to spin up scanning infrastructure → harvest more .env files. The operation feeds itself.

But even without that loop, the economics are staggering:

The success rate doesn't need to be high. If even 0.1% of targeted servers return a valid .env file, and the operation scans thousands of targets per day (we only see our own single server), the revenue dwarfs the cost by orders of magnitude.

Google has not terminated this operation despite 3+ weeks of daily abuse from their infrastructure. Whether this reflects poor abuse detection, deprioritization of "low-volume" scanning, or deliberate tolerance of paying customers remains an open question.

When this operation finds a server that actually serves its .env file — and across thousands of daily targets, some inevitably do — here's what they harvest:

DB_HOST=production-rds.us-east-1.rds.amazonaws.com
DB_USERNAME=app_prod
DB_PASSWORD=s3cr3t_pr0d_p4ss!

AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

STRIPE_SECRET_KEY=sk_live_4eC39HqLyjWDarjtT1zdp7dc
MAIL_PASSWORD=smtp_prod_password
REDIS_PASSWORD=redis_cluster_pass
JWT_SECRET=your-256-bit-secret

GITHUB_TOKEN=ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
SENTRY_DSN=https://key@sentry.io/1234567

From a single file, the attacker gains:

• 🗄️ Full database access — customer data, PII, financial records
• ☁️ Cloud infrastructure control — spin up resources, access S3 buckets, pivot to other services
• 💳 Payment processing — refund fraud, test charges, or dump card data
• 📧 Email system — phishing from legitimate accounts, password resets
• 🔑 Session hijacking — JWT secrets allow forging any user's authentication
• 📦 Supply chain access — GitHub tokens can inject backdoors into dependencies

This is not a "scan." This is a key to everything. One exposed .env file can compromise an entire organization's infrastructure, customer data, and financial systems. The attackers know this. That's why 361 IPs are hitting our single server. Imagine the scale across the entire internet.

1. This is a professional, dedicated credential harvesting service — not a hobbyist, not a researcher, not background noise. The operational security (daily rotation, zero SSH contamination, framework-aware tooling) indicates a mature criminal operation.
2. The .env scanning ecosystem is a multi-tier market with distinct professional (Google Cloud), commercial/research (LeakIX/DigitalOcean), and criminal (Advin Services) participants — each with different methods, infrastructure choices, and business models.
3. Google Cloud Platform is enabling this operation through insufficient abuse detection. Three weeks of daily IP rotation, 54 instances, zero intervention. The asymmetry between Google's security marketing and their actual abuse response is notable.
4. Specialization proves market maturity. When criminal operations specialize to this degree — avoiding SSH entirely, investing in OPSEC, maintaining framework-specific wordlists — it means the market for stolen credentials is large enough to support dedicated specialists.
5. Traditional defenses are irrelevant. IP blacklists, rate limiting, even WAF rules — none work against an operator who uses each IP once and rotates user agents per-request. The only effective defense is not exposing .env files in the first place.
6. The economic asymmetry is extreme. ~$15/month operational cost versus potentially $50,000+ monthly revenue from harvested credentials. This is one of the highest-ROI operations in cybercrime — which guarantees it will continue and intensify.

If you run a web application:

• Verify your web server explicitly denies requests to .*env* paths (don't rely on default behavior)
• Check for backup files: .env.bak, .env.old, .env~, .env.save in your document root
• Audit your Docker builds — does COPY . . include your .env file?
• Use secret managers (Vault, AWS Secrets Manager) instead of .env files in production
• Rotate credentials immediately if you find evidence of .env exposure in your access logs

The attackers documented in this dossier scanned us 6,313 times and found nothing. But they only need to succeed once, somewhere, to make the entire operation profitable.

📍 You are here: Letter A — The .env Harvesters

• 🕸️ A: The .env Harvesters — Google Cloud credential scanning fleet (this article)
• 👻 B: The WordPress Ghosts — Azure fleet systematically checking for pre-planted backdoors
• 🔭 C: The Reconnaissance Industrial Complex — Palo Alto, LeakIX, DeepSeek scanning at scale
• ⚔️ D: The Multi-Vector Operators — 1,751 IPs attacking both SSH and HTTP simultaneously
• ☁️ E: The Cloud Mercenaries — When cloud providers become attack platforms