VECERT's November 8, 2026 Operation Ghost-Campus report describes more than academic fraud at a Shanghai college. On a Tencent Cloud VPS at 134.175.71(.)194, researchers recovered artifacts for an autonomous resource-acquisition agent that registers FOFA accounts at scale, searches the internet for exposed .env files, Docker configs, and Git repos, extracts OpenAI and DeepSeek API keys, validates balances, and pipes working keys into attacker tooling—including a GoTTY terminal presented as "Pi — AI Coding Assistant." The case reference is VECERT-TI-2026-1107-B.
If you run coding agents locally, the relevant slice is not the campus fraud module. It is Phase B and C of the chain: industrialized OSINT plus live API validation against keys developers often leave on misconfigured servers.
| Question | Short answer |
|---|---|
| Am I affected? | Yes if an OpenAI or DeepSeek key was ever on an internet-indexed server, public repo, or leak FOFA can query |
| Is there a vendor patch? | No CVE—this is credential exposure plus abuse of FOFA free tiers |
| What keys are hunted? | sk-proj-… (OpenAI) and sk-[a-f0-9]{32} (DeepSeek), per VECERT |
| Does data leave my machine? | The campaign reads keys from remote misconfigs; your laptop is at risk only if you published secrets |
| What should I do first? | Revoke and rotate exposed keys, check usage/billing logs, keep keys out of .env on web roots |
Attack chain step by step
VECERT frames the FOFA module as three phases that run without hand-operated searches.
Phase A: Catch-all mail and mass FOFA registration
FOFA free accounts cap web queries (VECERT cites 0/300 for "Registered User" status with 0 F-points). The actor did not depend on disposable inboxes. VECERT's DNS write-up says melocc.cc exposes mail, api, pop, imap, and smtp subdomains to 156.251.234.242, plus a separate U.S. mail backend at 156.233.234(.)242 (Cognetcloud INC, ASN 401701).
Automation then:
- Registers a FOFA account with a unique
fofa*@melocc.ccaddress. - Pulls the confirmation message over the actor's POP/IMAP.
- Activates the account in seconds.
Recovered fofa_accounts.csv and panel screenshots document at least 1,438 accounts with passwords and JWT tokens ready for API use (examples in the report include [email protected] and [email protected]).
Phase B: Token rotation and internet-wide dorks
Each token carries a small quota. The operator rotates all 1,438 JWTs so daily query volume scales to tens of thousands of FOFA lookups, VECERT says. Queries target patterns associated with exposed .env files, Docker configurations, and poorly secured Git repositories—the same classes of leaks that fuel GhostAction-style GitHub workflow theft and Mandiant's LLMjacking tracking.
This parallels how Symantec documented a FOFA-scanning botnet operator in Skynet Mode LLMjacking, though Ghost-Campus adds private mail farms rather than only rotating public inboxes.
Phase C: Regex extraction and live API validation
When a host matches, the agent applies regular expressions and sorts keys:
- OpenAI (
sk-proj-…): HTTP checks to api.openai.com. VECERT's dashboard taxonomy includes valid keys, 429 "no credits" (valid_no_balance), and 401 revoked responses. - DeepSeek (pattern
sk-[a-f0-9]{32}): validation plus balance queries. VECERT's screenshots reference three usable keys with balances 50.68, 8.52, and 0.80 taken from labibiyat.com and nyisu.com.
Working keys are injected into the operator environment. VECERT explicitly links that compute to the GoTTY "Pi" terminal and to other automation on the same host (academic bots are out of scope for this post but show why attackers want free model spend).
How this differs from generic secret scanners
Public .env hunters are not new. What VECERT highlights is orchestration:
- Provisioning at scale (private catch-all mail beats one-off temp inboxes).
- Quota fragmentation (1,438 × ~300 queries) to stay under per-account caps.
- Financial triage before keys enter playbooks (valid, empty balance, revoked).
That last step matters for agent defenders. A key that still "works" but returns 429 insufficient quota may sit unused in the panel while a sibling key with balance powers the Pi terminal. Your billing alert might fire on the valuable key while the leaked backup key lingers in a forgotten staging server.
Google's threat reporting cluster around LiteLLM routers and stolen inference keys (Fireworks October update) shows the same economic logic from the victim side: attackers treat model spend like cloud credits. Ghost-Campus is the acquisition lane; Operation Snowball is an example of consumption once access exists—though Snowball used jailbreak harnesses rather than stolen SaaS keys.
Timeline and disclosure notes
| Date | Event |
|---|---|
| 2026-11-08 | VECERT publishes Operation Ghost-Campus on Medium (TLP:AMBER) |
| 2026-11-10 | Secondary security press summarizes FOFA rotation and key validation |
| Ongoing | VECERT states OSINT-only collection; no claim of intrusive victim validation |
VECERT's disclaimer says the team did not hack victim universities or FOFA to produce the report. Treat student-record counts and financial QR-code risk as researcher-visible artifacts on the attacker panel, not as court-ready victim notifications.
Attribution language is cautious: Chinese-language infrastructure on Tencent Cloud and Shanghai-adjacent targeting are consistent with a regional operator but are not proof of sponsorship. For coding-agent teams, the actionable slice remains credential exposure physics, not geopolitics.
What developers should verify today
VECERT and secondary reporting agree on defender actions that matter for agent teams:
- Never serve
.envon the public internet. Scanners hunt them by name and content. The fake ChatGPT/Claude bots that scan.envpaths show the same economics from a different angle. - Treat repo history as permanent. A removed
.envcommit still appears in FOFA-adjacent Git dorks until history is purged and keys rotated. - Read provider logs like intrusion data. Victim logs may show your key calling models from unfamiliar regions while you sleep.
- Set billing caps and alerts on OpenAI, DeepSeek, and any router (LiteLLM, OpenRouter) that fronts them.
Concrete checks (from vendor docs, not campaign-specific):
# Git: search local clones for committed env files (example)
git log --all --full-history -- '*.env' '.env*'
# OpenAI usage review (after browser login)
# https://platform.openai.com/usage
If a key was exposed, revoke before hunting for "who stole it." LLMjacking cases such as Operation Snowball illustrate how fast stolen model access converts into intrusion labor.
What this means if you run AI coding agents
Coding agents amplify the blast radius of a leaked key:
- A stolen project key can power unattended scripts that look like legitimate CI or "coding assistant" traffic.
- Agents that read
.envinto context can accidentally re-exfiltrate a still-valid key if a prompt or skill is poisoned. - Local-only keys stored under
~/.claude/or~/.codex/are not what FOFA indexes—but synced dotfiles, screenshots, and backup buckets sometimes are.
Hardening that matches this threat model:
| Control | Why it helps here |
|---|---|
| Separate dev vs prod API keys with low caps | Limits spend when a dev server leaks |
No secrets in agent instructions (CLAUDE.md, skills) | Stops second-hop leaks via prompt injection |
| Egress-aware routers | Surfaces odd model call geography early |
Periodic git secrets / trufflehog on repos agents touch | Catches .env before indexers do |
Monitoring signals that fit agent workflows
When a coding agent shares a developer laptop with leaked keys, abuse can look like normal IDE traffic. Useful owner-side checks:
- Provider dashboards: model listings sorted by last used and source IP. FOFA-sourced keys often call APIs from VPS ranges unrelated to your office egress.
- Organization audit logs (if enabled): sudden new API key creation after an old key appeared in a FOFA-adjacent leak is a common rotation mistake—attackers win twice.
- Repo metadata: if FOFA indexed a private repo mirror or debug endpoint, GitHub/GitLab secret scanning may surface the finding before you do—do not wait for the vendor alone.
- Agent transcripts: if Beam or another local collector is running, search stored events for sk-proj- or sk- fragments after a suspected leak. Beam redacts on persist, but raw hooks may still echo secrets during the session unless redaction rules cover them.
None of these replace rotation. They help you learn whether the Ghost-Campus class of scanner already burned a key that still appears in a developer's .env.example "for local testing."
What Beam can and cannot do here
Beam does not scan FOFA or your cloud perimeter. On the machine where you run Claude Code or Codex, it can still reduce adjacent risk:
beam scan … --mcpruns offline heuristics on MCP JSON, including version-pin checks, before you trust a new server definition (scanning docs). That does not validate API keys on remote hosts.- Hook-based PreToolUse deny (where your harness supports it) can block destructive recovery commands agents might suggest after a breach—see how Beam watches agent actions.
- Redaction before local storage limits how much of a key ends up in on-device audit files if an agent prints secrets.
Beam does not revoke OpenAI keys, detect FOFA queries against your domains, or close the fail-open gap when cached policy expires. Treat it as local observability and config hygiene, not LLMjacking prevention by itself.
How Beam handles this
Overlapping products focus on cloud secret scanning or SIEM correlation. Beam stays local-first: it inspects skills, MCP configs, and hook files on the workstation that actually holds agent credentials, flags risky patterns (curl-to-bash, unknown MCP servers, missing pins), and keeps reports on-device unless you enroll a collector. For teams already cleaning up exposed .env files, Beam is a better fit when the next question is "what on this laptop can re-leak keys into agent context?" than when you need internet-wide attack surface management.
Indicators worth sharing with your IR team
VECERT and Cyber Security News publish overlapping IoCs. Defang only inside your TI platform:
| Type | Indicator | Context |
|---|---|---|
| Domain | melocc.cc | Catch-all FOFA registration mail |
| IP | 134.175.71(.)194 | Tencent Cloud control panel (Guangzhou) |
| IP | 156.251.234.242 | Mail/automation per DNS section |
| File | fofa_accounts.csv | Bulk account dump |
| Domain | labibiyat.com, nyisu.com | Named DeepSeek key sources |
Related reading
- Operation Snowball: jailbroken DeepSeek agent intrusion — what stolen model access funds in another November campaign
- Mandiant LLMjacking and stolen API keys
- Symantec Skynet Mode and FOFA-driven LLMjacking
- October 2026 supply-chain tracker (GhostAction AI keys)
- Fake AI bots scanning for
.envfiles - Claude Code settings leaked via public GitHub
Primary sources: VECERT Operation Ghost-Campus (Medium, Nov 8, 2026). Secondary context: Cyber Security News summary (Nov 10, 2026).
Frequently asked questions
What did VECERT document about fake FOFA accounts?
In case VECERT-TI-2026-1107-B, published November 8, 2026, VECERT says it recovered fofa_accounts.csv and control-panel screenshots confirming at least 1,438 FOFA accounts registered through melocc.cc catch-all mail, each with passwords and JWT tokens used to rotate search queries.
Which API key formats does the harvester target?
VECERT describes regex extraction for OpenAI keys beginning with sk-proj- validated against api.openai.com, and DeepSeek keys matching the pattern sk-[a-f0-9]{32} with balance checks. Cyber Security News and VECERT both note keys taken from servers such as labibiyat.com and nyisu.com.
Does this mean my local Claude Code API key was stolen?
Only if the key was exposed on an internet-facing host, in a public or leaked Git repository, or in another asset FOFA can index. Keys that never leave your laptop filesystem are not in scope for this internet-wide scan chain.
How is this related to coding agents?
VECERT ties stolen keys to a GoTTY web terminal branded Pi — AI Coding Assistant and to broader automation on the same Tencent Cloud VPS. Mandiant and other vendors have tracked similar LLMjacking where stolen keys fund attacker-side agent tooling.
What should I do if I ever committed a .env file?
Revoke the key at the provider, rotate any sibling secrets in that file, review provider usage logs for unknown IPs, set billing alerts, and scan Git history locally. Do not rely on deleting the commit without rotation.
Can FOFA or search engines stop this alone?
VECERT shows the actor bypassed per-account query caps by industrializing registration with private mail infrastructure. Defenders still need to remove secrets from indexed surfaces; platform rate limits are not a substitute for key hygiene.
VECERT publication dates, FOFA quota details, and IoCs are accurate as of November 10, 2026. VECERT states its work is OSINT-only; treat victim counts and attribution as researcher reporting until independently confirmed.

