AI-nomenclature honeypot poisoning

01 Executive summary

For over a month, a single botnet fed three fake usernames into every honeypot in the fleet, betting that cowrAI's own tuning automation would add them to the real credential list. If it had worked cleanly, an attacker could have told the honeypots apart from real servers just by trying to log in as claude. It mostly didn't work — except for a 24-hour window on 2026-06-08 where an unrelated auto-apply quirk let nvidia through with a wildcard password, and attackers used the resulting shell access to run hardware-fingerprinting commands. This report walks through both the failed campaign and that one real near-miss.

A botnet distributed across seven /24 subnets flooded all 36 cowrAI honeypots with login attempts for three usernames: claude (AI assistant brand), nvidia (GPU/AI hardware brand), and onkar (personal name used as padding). All three usernames are already present in the earliest data our retention window covers (2026-05-21), so the true campaign start predates our visibility — this report's 2026-05-26–2026-06-25 window is an analysis window, not necessarily the campaign's actual onset. Volume escalated roughly 5–7× on 2026-06-02 and sustained ~450–1,100 claude-username attempts per day through June 24.

The attack goal is userdb injection: force automated honeypot tuning systems to add these accounts by exceeding the minimum distinct-IP threshold. A honeypot that subsequently accepts claude:claude can be fingerprinted as honeypot infrastructure. The same usernames pushed into real SSH targets serve as a reconnaissance signal: a server that accepts them may be running AI workloads with service accounts matching current tech-brand keywords.

cowrAI's AI sanity check on tuning report #24 (2026-06-25) flagged the claude/onkar additions and manual review confirmed poisoning; a partial apply that day accepted the three legitimate co-additions (openvpn, gpadmin, rancher) and excluded the poisoned entries. But report #24 wasn't the campaign's only brush with success: an earlier auto-apply cycle (report #43, 2026-06-08 02:20 UTC) had already added nvidia to the applied userdb as a wildcard-password entry (nvidia:x:*, matching any password) — a shape the credential-pair overlap heuristic doesn't examine, because it isn't a specific observed credential pair. That entry accepted 132 successful nvidia logins across 31 of the fleet's 36 honeypots over the following ~24 hours before the next day's auto-apply (report #44) rebuilt the userdb without it. See Timeline for the full sequence and what attackers did with that access.

02 Attack methodology

Honeypot userdb poisoning

Automated honeypot platforms that learn from observed traffic periodically update their accepted credential list (userdb). A common tuning heuristic: if a username:password pair is seen from N distinct source IPs within a window, it likely represents real-world credential usage and is added to the accepted list.

Attackers exploit this by coordinating botnets to generate synthetic-but-convincing traffic against a target username. Once the account is accepted by the honeypot, two outcomes are possible:

• Fingerprint confirmation — the attacker's tool observes that claude:claude now logs in successfully and infers the target is a dynamic-userdb honeypot, not a real server.
• AI infrastructure profiling — scanning real SSH targets with claude and nvidia credentials; a server that accepts them may be running AI workloads with matching service accounts.

Username selection logic

Password strategy

The three usernames use distinct password approaches, likely from different tooling configurations running under the same botnet controller:

Dual-purpose botnet

The core high-volume IPs (45.153.34.x, 45.156.87.x, 176.65.132.x, 176.65.139.x) are not single-purpose poisoning bots. Across the same 30-day window they generated 357,971 successful logins and 291,103 failed logins against all other cowrAI-monitored usernames, ordinary SSH brute-force activity. The poisoning usernames are an added layer in an existing botnet's wordlist, not a dedicated attack infrastructure. (Corrected from an earlier draft's 106,616/83,140 figures, which undercounted by roughly 3.3×/3.5× — re-derived directly from the same four /24 subnets against all non-poisoning usernames.)

03 Timeline

Daily volume chart

04 Botnet infrastructure

Subnet concentration

Highest-volume nodes

176.65.139.181 is the single highest-volume node overall (678 hits, all claude) but was only active for ~28 hours (2026-06-21 to 2026-06-22) — a compressed high-rate burst, not a long-running node like the rest of this table. All other rows are consistent with sustained activity since 2026-05-26/27.

IP overlap proof

Set sizes: claude 614 distinct IPs, nvidia 238, onkar 226 (report window 2026-05-26–2026-06-24). Overlap % below is shared IPs ÷ the smaller of the two sets.

05 Observed payloads

Nearly all observed traffic is SSH login attempts with no follow-up. The one exception is the 2026-06-08 nvidia wildcard-userdb window (see Timeline): 112 of the 132 accepted sessions ran commands, exclusively hardware/OS recon (uname, nproc, uptime, and a GPU check via lspci) — no dropper or persistence activity in any session. Full credential lists observed during the 30-day analysis window:

claude username — top credentials (by IP spread)

claude:claude           (231 IPs)
claude:claude123        (133 IPs)
claude:12345678         (131 IPs)
claude:123              (116 IPs)
claude:1234             (112 IPs)
claude:123456           (107 IPs)
claude:password         (104 IPs)
claude:1                 (88 IPs)
claude:root              (87 IPs)
claude:abc123            (85 IPs)
claude:Claude2026!       (35 IPs)
claude:claude2025        (30 IPs)
claude:claude!           (30 IPs)
claude:Claude2025!       (20 IPs)
claude:claude2026        (19 IPs)
# ... 39 additional low-spread passwords (claude12345, claude@123, Claude11!, etc.)

nvidia username — top credentials

nvidia:nvidia          (236 IPs)   ← includes the 132 accepted logins during the 2026-06-08 wildcard-userdb window
nvidia:nvidia123        (12 IPs)
nvidia:nvidia@1234       (1 IP)
# ... 26 additional brand-variation passwords (nvidia2025!, nvidia#2024, etc.)

onkar username — full credential list

onkar:onkar123         (226 IPs)   ← single-password campaign

06 MITRE ATT&CK mapping

07 Indicators of compromise

Poisoning usernames

High-confidence botnet IPs (all 3 poisoning usernames observed)

Botnet subnets (block at network perimeter)

Password patterns (detection/blocklist)

08 Detection & hardening

Userdb tuning hardening

Three controls that ultimately stopped this campaign — plus one gap the 2026-06-08 near-miss exposed:

1. AI sanity check on tuning reports — LLM review of proposed additions flags AI-brand and personal-name usernames as anomalous before auto-apply.
2. IP-overlap cross-analysis — computing overlap across candidate-username IP sets; 70%+ shared IPs is a strong coordination signal.
3. Poisoning shape filter in honey-tune — success=0, count <= distinct_ips × 1.5 heuristic. Note: this filter did not catch this campaign because count > distinct_ips × 1.5 for all three usernames. A stronger heuristic: flag usernames with no prior appearances in any tuning report that appear from >50 IPs simultaneously.
4. Gap found in this campaign — wildcard-password entries bypass all three of the above. The 2026-06-08 near-miss got through because nvidia:x:* is a wildcard-password entry, not a specific observed credential pair — none of the three controls above evaluate that shape. Recommendation: automated tuning should never emit user:x:* wildcard entries from candidate additions; only exact observed credential pairs should reach auto-apply.

Suricata rules

alert ssh any [45.153.34.0/24,45.156.87.0/24,176.65.132.0/24,176.65.139.0/24,91.92.40.0/22,192.109.200.0/24] any -> $SSH_SERVERS any (msg:"SSH brute-force from AI-username poisoning botnet subnet"; flow:to_server,established; threshold:type both,track by_src,count 5,seconds 60; sid:9100001; rev:1;)

alert ssh any any any -> $SSH_SERVERS any (msg:"SSH login attempt with AI-brand username claude"; flow:to_server; content:"claude"; nocase; threshold:type both,track by_src,count 3,seconds 300; sid:9100002; rev:1;)

alert ssh any any any -> $SSH_SERVERS any (msg:"SSH login attempt with AI-brand username nvidia"; flow:to_server; content:"nvidia"; nocase; threshold:type both,track by_src,count 3,seconds 300; sid:9100003; rev:1;)

Blocklist recommendation

Operators running adaptive honeypot userdb tuning should add claude, nvidia, and onkar to a permanent exclusion list — these should never be auto-added regardless of observation count. The subnets listed above are suitable for SSH blocklist or rate-limit application.

Broader implication: AI-brand username campaigns

09 Collection methodology

All data collected via a distributed SSH/Telnet honeypot fleet spanning multiple cloud providers and geographic regions. Login attempts are captured in near-real-time with source IP, username, password, and timestamp fields preserved for analysis.

Tuning analysis via honey-tune cron worker (daily, 02:17 UTC): aggregates top credential pairs by distinct-IP count over 7-day window, diffs against current applied userdb, runs AI sanity check, and gates auto-apply on sanity approval. Report #24 (2026-06-25) was the first to trigger the AI sanity gate on this campaign's exact-credential-pair additions and block auto-apply — but it was not the campaign's first brush with acceptance: report #43 (2026-06-08) had already auto-applied a wildcard-password nvidia entry that fell outside the exact-pair heuristic (see Timeline).

IP-overlap analysis computed directly against the events table, comparing distinct-src_ip sets per username. No external enrichment (ASN/geo) applied — userdb poisoning classification based solely on observed traffic patterns and username semantics.