← Back to Journal
• Cybersecurity

How I Caught a Credential-Stealing Malware Targeting Vibe Coders

How I Caught a Credential-Stealing Malware Targeting Vibe Coders

There's a malware toolkit that's been hunting vibe coders since September 2025. It avoids military sites, enterprise platforms, and big cloud providers. Instead, it targets indie developers who left their .env files exposed.

Last night I caught it running on my own cloud infrastructure. Here's the full story.

The Discovery

It started with unexpected Google Cloud charges. Someone had spun up three high-powered virtual machines on my GCP project — 8-core machines running 24/7 for days. I didn't create them.

Instead of panicking and deleting everything, I SSH'd into the VMs to see what they were doing. What I found was a fully automated credential theft pipeline scanning approximately 8,000 domains for exposed .env files — database passwords, Stripe keys, AWS secrets, JWT tokens — everything.

Meet Bissa

The toolkit is called Bissa. Its Docker image has been pulled over 1,200 times since September 2025. It runs in campaigns — the operator spins it up on compromised cloud infrastructure, harvests thousands of credentials, wipes the evidence, and disappears. I caught it mid-campaign.

Phase 1: Mass .env Theft

The tool streamed target domain lists from a command-and-control server, then probed each domain for exposed /.env files. It ran 4 parallel worker processes per VM, each handling up to 1,536 concurrent connections. Stolen credentials were archived and uploaded to S3-compatible storage in batches.

Phase 2: Active Exploitation

But .env scraping was just phase one. The toolkit also had active exploits for recent CVEs:

  • CVE-2025-55182 — Next.js Server Action RCE via Flight protocol prototype pollution, with polymorphic WAF evasion including Cloudflare bypass, Unicode obfuscation, and junk padding
  • CVE-2025-9501 — WordPress W3 Total Cache RCE targeting versions 2.0.x through 2.8.12

This wasn't just collecting — it was breaking in.

The Target Selection

What made this particularly interesting was how deliberate the targeting was. A built-in blocklist revealed exactly who the attacker chose to avoid:

Skipped entirely:

  • .mil — US military domains
  • .k12 — school domains
  • AWS, Azure, Cloudflare infrastructure
  • Shopify, Squarespace, Wix, WordPress.com
  • Enterprise SaaS (Zendesk, HubSpot, Salesforce, Atlassian)
  • NAS devices, mail servers, infrastructure panels

The attacker specifically hunted self-hosted applications deployed by solo developers and small teams — vibe coders who ship fast and forget to lock down their .env files. They avoided anything with enterprise WAFs or security teams that might notice and respond.

The Investigation

Here's where my AI assistant (OpenClaw) came in. I had it analyze everything in real time — running processes, Docker containers, full source code of the toolkit, and network connections.

In under 15 minutes, we mapped the entire operation.

What We Traced

  • 📦 Docker Hub — The full toolkit packaged as a Docker image
  • 🤖 Telegram Bot — Receiving real-time alerts for every successfully stolen credential
  • 🪣 S3 Storage — Three generations of loot buckets (Sep 2025, Nov 2025, Mar 2026) — the operator purges between campaigns
  • 🎯 C2 Server — A command-and-control domain feeding target lists to the scanning workers

The OPSEC Failures

The operator's operational security wasn't great. The C2 domain and its nameservers resolved to the same IP address — a single server running the whole thing.

From there, the identity chain unraveled:

  • Telegram bot token → operator's Telegram account and a private monitoring group
  • S3 bucket → registration email
  • C2 domain → hosting provider and registration details

The operator ran a private Telegram group for monitoring scans. Every time a credential was stolen, a bot notification hit the chat. Real-time dopamine hits from stealing people's database passwords.

Action Taken

We preserved everything — source code, process dumps, network connection logs, and stolen credential samples as evidence. Then we killed all three VMs immediately.

We're now reporting to every platform involved:

  • Google Cloud — Unauthorized compute usage
  • Docker Hub — Malware image hosting
  • Telegram — Bot used for criminal exfiltration
  • Domain registrar — C2 domain suspension
  • Storage provider — Stolen data buckets

Law enforcement reports are next.

Breach Notifications

We identified approximately 7,800 targeted domains and are sending breach notifications so affected developers can rotate their credentials immediately.

Takeaways

  1. If yourdomain.com/.env loads in a browser, you're already compromised. This is the single most common vulnerability for self-hosted apps. Block it in your web server config.

  2. Set up cloud billing alerts. That's what tipped us off. Without billing notifications, those VMs could have run for weeks undetected.

  3. Vibe coding is fun until someone vacuums your Stripe live keys. If you're shipping fast with AI-generated code, take 5 minutes to secure your deployment. It's not optional.

  4. When you find an intruder: investigate first, delete second. The evidence matters — for abuse reports, for law enforcement, and for understanding the scope of the breach.

  5. AI-assisted incident response is real. The entire investigation — from discovery to complete threat actor profiling — took about 15 minutes. The AI handled code analysis, OSINT, identity correlation, and report generation while I focused on the tactical decisions.

If you were affected by this breach or want more details, reach out at [email protected]. Secure your .env files. Tonight.