AI-Nomenclature Honeypot Poisoning

01 Executive Summary

Beginning 2026-05-26, a botnet distributed across seven /24 subnets began flooding 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). Volume escalated 5–6× on 2026-06-02 and has sustained ~700–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 — if a server accepts them, it may be running AI workloads with service accounts matching current tech-brand keywords.

cowrAI's AI sanity check on tuning report #24 flagged the additions. Manual review confirmed poisoning; a partial apply on 2026-06-25 accepted the three legitimate co-additions (openvpn, gpadmin, rancher) and excluded the poisoned entries. Zero logins to claude, nvidia, or onkar were accepted across the fleet.

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 106,616 successful logins and 83,140 failed logins against all other cowrAI-monitored usernames — standard SSH brute-force activity. The poisoning usernames are an added layer in an existing botnet's wordlist, not a dedicated attack infrastructure.

03 Timeline

Daily Volume Chart

04 Botnet Infrastructure

Subnet Concentration

Highest-Volume Nodes

IP Overlap Proof

05 Observed Payloads

All observed traffic is SSH login attempts — no command execution, no dropper activity. Full credential lists observed during the 30-day campaign 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           (99 IPs)
nvidia:nvidia123         (8 IPs)
nvidia:nvidia@1234       (1 IP)
# ... 26 additional brand-variation passwords (nvidia2025!, nvidia#2024, etc.)

onkar username — full credential list

onkar:onkar123         (100 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 stopped this campaign:

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 Jaccard similarity across candidate-username IP sets; >70% overlap 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.

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 was the first to surface this campaign at sufficient volume for recommendation; the AI gate blocked auto-apply and triggered operator review.

IP-overlap analysis (Jaccard similarity) computed directly against the events table partitioned by timestamp. No external enrichment (ASN/geo) applied — userdb poisoning classification based solely on observed traffic patterns and username semantics.