🎯 TI-2026-011 — The Personal Touch: When Attackers Get Creative

🔴 HIGH — Coordinated Targeted SSH Attack Against Named Infrastructure Operator

TI-2026-011 — "The Personal Touch" — When Attackers Know Your Name, Your Family, Your Services, and Your Passwords

Two coordinated attack campaigns — linked by a shared IP using both toolkits — employed leaked credentials, deep personal OSINT (real names, family members reversed as usernames, internal service accounts, native-language passwords), and 326 algorithmically-generated domain-specific passwords to target a single infrastructure operator across 42 IPs spanning 16 countries over 44 days. The attacker knew the operator's full name, a family member's name (spelled it backwards), both owned domains, the mail server subdomain, internal Kubernetes service names, the admin handle, and multiple leaked passwords — including one confirmed from a previously-exposed Portainer instance and another constructed from the operator's handle combined with a keyboard-walk pattern. They even tried the default password for Apache Guacamole — guessing the wrong remote-desktop technology entirely. Zero successful logins. All credentials had been rotated. Emergency rotation was triggered by this analysis. Every web service is protected by multi-factor authentication. We see everything.

🎯 Targeted Attack Credential Stuffing Personal OSINT Leaked Credentials Algorithmic Wordlist Handle + Keyboard Walk Service Enumeration IP Rotation Botnet Post-Quantum SSH 42 IPs · 16 Countries · 44 Days 2 Campaigns · 1 Actor · 0 Successes

📋 Executive Summary

Between March 25 and May 7, 2026, our Cowrie SSH honeypot captured evidence of two distinct but coordinated attack campaigns targeting our infrastructure by name. Unlike the ~76,000 opportunistic brute-force attempts logged during this period from ~2,900 IPs, these campaigns demonstrate intimate knowledge of our domain, services, personnel, leaked credentials, and personal relationships.

Campaign A ("Wordlist Blitz") used 19 IPs to deliver 1,763 credential attempts with 326 algorithmically-generated passwords derived from our domain name. Usernames included actual running services on our Kubernetes cluster — Portainer, PeerTube, and Docker Registry. All attempts used automated libssh-based tooling with 64.2% round-robin IP rotation between consecutive attempts.

Campaign B ("Credential Leak / OSINT Recon") used 23 IPs to deliver 72+ surgical credential attempts using 6 confirmed targeted passwords — including credentials leaked from a previously-exposed service, a password constructed from our admin handle combined with a keyboard-walk pattern, a Romanian-language word meaning "Thank you," and even the default password for Apache Guacamole (wrong guess — we use KasmVNC). Usernames were derived from deep personal OSINT: the operator's real full name, a family member's name spelled backwards with a number appended, both owned domains, internal service account names, and the mail server subdomain.

Neither campaign achieved access. All leaked credentials had already been rotated. Every web-facing service is protected by Authelia SSO with mandatory two-factor authentication (TOTP / security keys) — even if a password were guessed correctly, the attacker would need a physical token or authenticator app. The previously-exposed service had been secured. When this analysis revealed that one of the targeted passwords was still active on internal systems, emergency credential rotation was triggered within hours, and all affected services were updated across the entire infrastructure.

Assessment: HIGH confidence same operator. A single IP address — 87.106.149.146 (IONOS, Germany) — was used in both campaigns: 177 brute-force attempts via libssh (Campaign A) followed by a single surgical attempt via SSH-2.0-Go with a post-quantum key exchange algorithm (Campaign B). This cross-campaign pivot eliminates the possibility of independent operations and proves shared infrastructure.

🍯 Combined Campaign Metrics — 44 Days of Intelligence

Unique Attacker IPs

1,835+

Total Credential Attempts

332

Unique Passwords

Countries Observed

Successful Logins

Coordinated Campaigns

Cross-Campaign IP Pivot

2FA

On All Web Services

🔗 Two Campaigns, One Operator — The Attack Architecture

These two campaigns use different tools, different IP pools, and different tactics — but share domain knowledge, timing, infrastructure providers, and one smoking-gun IP. Assessment: HIGH confidence same operator or coordinated group.

⚡ Campaign A — "Wordlist Blitz"

Period: April 3 – May 7, 2026 (35 days)
IPs: 19 (all libssh 0.7–0.11)
Attempts: 1,763
Passwords: 326 (algorithmically generated from domain name)
Strategy: Volumetric brute-force with round-robin IP rotation
IP Switch Rate: 64.2% between consecutive attempts
Waves: 5 distinct attack waves with progressive service enumeration
Key Tell: Targeted usernames match actual K8s services

🎯 Campaign B — "Credential Leak / OSINT Recon"

Period: March 25 – May 7, 2026 (44 days)
IPs: 23 (SSH-2.0-Go, paramiko, Ganymed, libssh2)
Attempts: 72+
Passwords: 6 (confirmed leaked + constructed credentials)
Strategy: Surgical credential stuffing with personal OSINT
Behavior: 1-2 targeted attempts per IP, then rotate
Phases: 4 progressive phases of escalating personal knowledge
Key Tell: Reversed family member name as username

🔗 THE LINK: IP 87.106.149.146 (IONOS, Germany) used libssh for Campaign A (177 attempts) then SSH-2.0-Go for Campaign B (1 attempt) — with a post-quantum key exchange algorithm (ML-KEM 768).
Campaign B validated leaked credentials (surgical) → Campaign A weaponized domain knowledge (volumetric). Different tools, same infrastructure.

⚡ Campaign A: "Wordlist Blitz" — 326 Algorithmic Passwords from Our Domain Name

🎯 Service-Aware Targeting

The attacker didn't guess usernames — they enumerated our actual running services and used them as SSH usernames. Three of the nine targeted usernames correspond to real services on our Kubernetes cluster:

portainer

Docker management UI — 72 attempts with 72 unique Portainer-specific passwords (portainer2026!, Portainer420!, etc.)

peertube

Video hosting platform — 81 attempts, added in Wave 4 after further reconnaissance

registry

Docker image registry — 58 attempts, also added in Wave 4

🧮 Password Generation Algorithm — Reverse-Engineered

We fully reverse-engineered the attacker's password generation algorithm. The 326 passwords are not from a generic wordlist — they follow a clear algorithmic pattern built entirely from our domain name:

BASE_WORDS = {
  domain_short:  ["on", "On"],
  domain_part:   ["shuffle", "Shuffle", "SHUFFLE"],
  domain_full:   ["shuffleon", "Shuffleon", "SHUFFLEON"],
  service:       ["portainer", "Portainer"]
}

LEETSPEAK_MAP (applied to "shuffle" variants only) = {
  'S' → ['$', '5'],     // Dollar sign, digit 5
  'l' → ['|', '1'],     // Pipe character, digit 1
  'e' → ['3', '0'],     // Digit 3, digit 0
  case → [lower, UPPER] // Applied to all combinations
}
// Generates: $huff|3, $HUFF1E0, 5HUFFL3O, SHUFF|EO, etc. (82 variants)

NUMERIC_STEMS = [0,1,2,3,4,5,6,7,8,9, 123, 420, 666, 69, 2025,2026,2027,2028]

SUFFIX_DECORATORS = ["", "!", "!!!", "!@#"]
// bare, single bang, triple bang, keyboard-shift-123

PASSWORD = BASE_WORD + NUMERIC_STEM + SUFFIX_DECORATOR
// Examples: On2026!, portainer420!@#, Shuffle123!!!, on666!

Leetspeak Variants

$HUFF|3O, 5huff1e, etc.

Plain Case Variants

Shuffle2026!, SHUFFLEON3!, etc.

"On" Suffix Matrix

On420!@#, on2028!!!, etc.

Portainer-Specific

portainer2026!, Portainer69!, etc.

The year range 2025–2028 in the suffixes is notable — the attacker anticipated passwords might be updated annually and covered future years. The inclusion of 420, 666, 69 as numeric stems reflects common "edgy" password choices users make. The triple-bang (!!!) and shift-sequence (!@#) decorators show awareness of common password complexity patterns.

📊 Attack Waves — Progressive Service Enumeration

Wave 1

Apr 3–4 — 712 attempts from 2 IPs (SPARKED HOST US + PROTON66 RU). Leetspeak-heavy: $HUFF|3O, 5huff1e. Opening salvo with most complex passwords first.

Wave 2

Apr 30 — 354 attempts from 10 IPs. Scale-up from 2→10 IPs. Portainer username added — confirms active recon between waves. "On" suffix matrix introduced.

Wave 3

May 2 — 5 attempts from 2 IPs. Quick IoT probe: pi:raspberry, root:openmediavault. Testing for Raspberry Pi or NAS devices on the same IP.

Wave 4

May 4–5 — 691 attempts from 14 IPs (7 new). PeerTube and Registry usernames added. Further service enumeration completed between waves. Full suffix matrix applied systematically.

Wave 5

May 7 — 1 attempt from 1 IP (87.106.149.146). Single root:Ferrari — but using SSH-2.0-Go instead of libssh. This is the cross-campaign pivot.

The progressive addition of service-specific usernames across waves (portainer in Wave 2, peertube+registry in Wave 4) reveals ongoing reconnaissance between attack phases. The attacker isn't just spraying — they're actively scanning, discovering new services, and updating their attack configuration.

🔄 IP Rotation — 19-Node Round-Robin Botnet

64.2% of consecutive attempts originate from a different IP — classic round-robin proxy rotation
Median inter-attempt interval: ~60 seconds
Top node (SPARKED HOST, US) contributed 30.8% of attempts across 4 of 5 waves
PROTON66 (Russian bulletproof hosting) contributed 13.3% but only appeared in Wave 1, then retired
All 19 IPs use libssh (versions 0.7.1–0.11.3) — same automated brute-force framework
Dominant HASSH fingerprint f93d28ee0c77e2612b27491518d909f4 shared across 11 of 19 IPs
Attacks occur during European/Americas business hours (10:00–20:00 UTC), no weekend activity

🎯 Campaign B: "Credential Leak" — The Personal Touch

⚠️ This campaign demonstrates deep personal knowledge of the infrastructure operator. The attacker used confirmed leaked credentials from a previously-exposed service, combined with personal names, family member information, internal account names, handle-derived password constructions, and native-language cultural knowledge. All personally identifiable information has been redacted in this public report.

🔑 Targeted Credentials — 6 Passwords, Each Telling a Story

[REDACTED_PASSWORD_A] — 43 attempts

Confirmed leaked from a previously-exposed Portainer instance. Primary credential tested across 18 IPs. Format: service provider + birth year + punctuation. The seed that initiated the entire campaign.

[REDACTED_PASSWORD_B] — 8 attempts

Native-language password meaning "Thank you" + numeric suffix. Demonstrates knowledge of operator's nationality and linguistic background. Not automatable — requires cultural intelligence.

[REDACTED_PASSWORD_C] — 1 attempt

Exact Portainer-specific credential variant — a mutation of Password A that was the actual service password. The attacker obtained this precise variant, confirming access to the real credential leak data, not just a generic breach dump.

[REDACTED_PASSWORD_D] — 1 attempt

Lowercase simplification of Password A. Paired with an internal project name as username. Testing whether a shorter variant works on a different service.

[REDACTED_PASSWORD_E] — 4 attempts

Handle + keyboard walk construction: the operator's 3-letter handle concatenated with a keyboard walk pattern (sequential keys across two keyboard rows) + punctuation suffix. This is not from a breach database — it's a constructed credential, demonstrating the attacker knows the operator's handle and applied common password-pattern knowledge to build a plausible guess. This credential triggered emergency rotation.

[REDACTED_PASSWORD_F] — 2 attempts

Apache Guacamole default credential. The attacker suspected a remote-desktop gateway service — they guessed wrong. The actual service uses KasmVNC behind Authelia forward-auth with mandatory 2FA. Tried first in the credential sequence, suggesting highest confidence. Wrong technology, wrong password, wrong assumption.

🔐 Defense Note — Two-Factor Authentication: Even if any of these passwords had been correct, all web-facing services are protected by Authelia SSO with mandatory two-factor authentication. Each user account requires either a TOTP authenticator app or a hardware security key to complete login. Credential knowledge alone is insufficient — the attacker would need physical access to the authentication device.

🧠 OSINT Knowledge Demonstrated — We Know What You Know

The attacker progressively revealed deeper levels of personal knowledge about the target. We have catalogued every piece of intelligence they demonstrated:

Knowledge Level	What the Attacker Knew	Likely Source	Severity
🟢 Public	Primary domain name	DNS / Web	Low
🟡 Semi-Public	Operator's real full name	WHOIS / LinkedIn / Breach DB	Medium
🟡 Semi-Public	Full email address	Breach database (associated with leaked password)	Medium
🟠 Private	Leaked password from previously-exposed service	Credential stuffing DB / Direct service access	High
🟠 Private	Service-specific credential mutation (exact variant)	Actual Portainer credential leak — not guesswork	High
🟠 Private	Operator's handle / alias pattern	GitHub/Gitea profile, service naming convention	High
🟠 Private	Handle + keyboard-walk password construction	Human analysis — constructed, not leaked	High
🟠 Private	Second owned domain	Web scraping / cert transparency / WHOIS cross-ref	Medium
🟠 Private	Internal service/admin account names	Gitea enumeration / K8s service discovery	High
🟠 Private	Mail server subdomain structure	Certificate transparency / DNS MX records	Medium
🟠 Private	Remote desktop service exists (guessed wrong technology)	Port scanning / service fingerprinting	Medium
🔴 Intimate	Family member's first name	Social media / public records / personal OSINT	Critical
🔴 Intimate	Family name reversed + number as username	Human intelligence analysis — not automatable	Critical
🔴 Intimate	Operator's nationality / native language	Cultural/linguistic knowledge ("Thank you" in native language)	Critical

The most striking findings: (1) the reversed family member name — reversing a name and appending a number is a human-creative operation that cannot be produced by automated OSINT tools; (2) the handle + keyboard-walk password construction — this is not from any breach database, it's a manually crafted guess combining the operator's known alias with a common password-building technique; (3) the native-language password — this places the attacker or their intelligence source within the operator's cultural sphere.

📅 Four Phases of Escalation

Phase 1: Generic Probing — Mar 25 – Apr 13 (20 days)

5 IPs from Brazil, Poland, Paraguay, Germany, DigitalOcean US | 15 attempts
Simple root:[leaked_password] pairs, 1–3 per IP. Diverse off-the-shelf SSH tools (Ganymed, paramiko).
Purpose: Testing whether the leaked credential still grants root access. Also: the most revealing single IP (MEVSPACE, Poland) tests ALL 6 passwords in priority order during this phase — [REDACTED_PASSWORD_F] first (highest confidence default), then [REDACTED_PASSWORD_E] (constructed), then [REDACTED_PASSWORD_A] (leaked), then [REDACTED_PASSWORD_B] (cultural). The ordering reveals a human operator, not a script.

Phase 2: Personal Targeting — Apr 15 – Apr 21 (7 days)

3 IPs from Ethiopia, UK, Cambodia | 27 attempts
Personal email address, real full name, operator handle, domain name — all as usernames.
Key event: Ethiopian IP fires 20 attempts in 75 seconds using a 5-username rotation cycle (full email, real name, root, admin, domain) repeated 4 times — automated loop with hardcoded personal data.
Purpose: The attacker has correlated the leaked credential with the domain owner's real identity.

Phase 3: Maximum OSINT Deployment — Apr 23 – Apr 30 (8 days)

13 IPs from France, Japan, USA, Germany, Estonia, Thailand, Bangladesh | 16 attempts
Each IP fires 1–2 unique targeted credentials. SSH-2.0-Go dominates (11 of 13 IPs) — consolidated tooling.
Key usernames deployed:
  • Internal Gitea project name → [redacted_service]:google
  • Reversed family name + number @ second domain
  • Full mail subdomain → webmaster@mailserver.[domain]
  • Family member service account → [family_prefix]-[family_name]
  • Primary admin account → [admin_handle]
  • Portainer-specific credential variant (exact mutation)
Purpose: Full OSINT dump — deploying everything gathered in a final coordinated burst.

Phase 4: Cross-Campaign Pivot — May 7 (single attempt)

1 IP (87.106.149.146, IONOS Germany) | 1 attempt
root:Ferrari via SSH-2.0-Go — from the same IP that ran 177 Campaign A libssh attempts days earlier.
HASSH includes mlkem768x25519-sha256 — a post-quantum key encapsulation mechanism (ML-KEM 768 / Kyber), indicating Go 1.23+ with x/crypto post-quantum support. This is cutting-edge SSH tooling.
Significance: This is the smoking gun — direct proof that Campaign A and Campaign B share infrastructure.

🔗 The Smoking Gun — Cross-Campaign IP Pivot Analysis

IP 87.106.149.146 (IONOS, AS8560, Germany) is the key that locks these two campaigns together:

Campaign A Activity (Apr 30 – May 5)

177 attempts via SSH-2.0-libssh_0.10.6
HASSH: f93d28ee...909f4
Usernames: shuffleon, on, root, registry, shuffle
Passwords: On/portainer mutations (algorithmic)

Campaign B Activity (May 7 — 2 days later)

1 attempt via SSH-2.0-Go
HASSH: 16443846...4397 (includes ML-KEM 768 post-quantum)
Username: root
Password: Ferrari (unique credential — not used elsewhere)

Same IP, different tool, different HASSH, different credential, 2 days apart.
Two toolkits deployed from one machine = one operator or shared access = coordinated operation.

🔍 Infrastructure-Wide Cross-Correlation

We queried every log source across our entire infrastructure for activity from all 42 campaign IPs:

System	Result	Detail
CrowdSec (IPS)	✅ ALL 42 BANNED	Every campaign IP is blocked via community threat-intel-feed (~26,742 IPs). Bans refreshed daily.
auth.log (real SSH)	✅ CLEAN	Zero hits — no campaign IP reached the actual SSH service. They only reached the honeypot.
syslog	✅ CLEAN	Zero hits from any campaign IP.
Traefik (reverse proxy)	✅ CLEAN	Zero HTTP/HTTPS requests — the attack was SSH-only, no web probing.
Authelia (SSO gateway)	✅ CLEAN	Zero login attempts via the web authentication gateway. 2FA never challenged.
Loki (centralized logs)	✅ CLEAN	Only cowrie (honeypot) logs contain campaign IPs. No other service was touched.
Remote Desktop Service	✅ PROTECTED	Behind Authelia forward-auth with mandatory 2FA. Attacker tried `guacadmin` (wrong technology — it's KasmVNC, not Apache Guacamole).

Key Conclusion: The attack was entirely contained to the SSH honeypot on port 2222. No lateral probing, no web-based attacks, no real service compromise. The attacker did NOT attempt to correlate SSH credentials with web-based authentication. All 42 IPs are banned at the network level via CrowdSec before they could reach any production service.

🕵️ Reconstructed Attacker OSINT Workflow

Based on every credential and username used, we can reconstruct the attacker's intelligence-gathering process with high confidence:

Step 1

Credential Database Search — Queried breach databases for the target domain → found leaked password and associated email address. This is the seed that initiated the entire campaign.

Step 2

Domain WHOIS / Registration — WHOIS lookup revealed registrant's real name. Cross-referenced with second domain registration.

Step 3

DNS Enumeration — MX records revealed mail server subdomain. Certificate transparency logs exposed additional subdomains (video, registry, etc.).

Step 4

Port Scanning / Web Enumeration — Discovered Portainer, PeerTube, Docker Registry, and a remote-desktop service. These became targeted usernames in Campaign A and default-password guesses in Campaign B.

Step 5

Code Repository Enumeration — Discovered admin handle and project names from Gitea instance. Identified the naming convention (handle-project pattern) used for internal accounts.

Step 6

Personal / Social OSINT — Identified family members (likely social media, public records). Recognized operator's nationality → crafted native-language password. Created reversed-name username variant. This level of creativity indicates a human intelligence analyst, not automated tooling.

Step 7

Password Construction — Combined handle knowledge with keyboard-walk pattern to construct a credential that never appeared in any breach. Also tested Apache Guacamole defaults against the remote-desktop service.

Step 8

Wordlist Generation + Deployment — Combined all intelligence into an algorithmic password generator: domain × leetspeak × suffixes × year range → 326 passwords. Deployed through 19-IP botnet with round-robin rotation (Campaign A) while continuing surgical targeted attempts (Campaign B).

🔬 Deep Dive: The Most Revealing Single IP

One IP — from MEVSPACE, Poland (AS201814) — is the most information-rich node in Campaign B. It used all 6 targeted passwords across 3 distinct visits spanning 15 days, always as root:

Visit 1 — April 4 (5 minutes, 4 credentials):
  root : [REDACTED_PASSWORD_F]  ← Guacamole default (tried FIRST — highest confidence)
  root : [REDACTED_PASSWORD_E]  ← Handle + keyboard walk (constructed)
  root : [REDACTED_PASSWORD_A]  ← Leaked credential (confirmed breach)
  root : [REDACTED_PASSWORD_B]  ← Native-language "Thank you" (cultural OSINT)

Visit 2 — April 9 (95 minutes, 4 credentials):
  root : [REDACTED_PASSWORD_E]  ← Retry
  root : [REDACTED_PASSWORD_A]  ← Retry
  root : [REDACTED_PASSWORD_F]  ← Retry
  root : [REDACTED_PASSWORD_B]  ← Retry

Visit 3 — April 19 (single attempt):
  root : [REDACTED_PASSWORD_A]  ← Final check — "does it work yet?"

Analysis: The credential ordering is significant. The Guacamole default is tried first (easiest default to verify), then the constructed handle+keyboard-walk (second-highest confidence — attacker thought this was the admin password), then the leaked credential, then the cultural password. This is a human operator making decisions about credential priority, not an automated rotation. The 10-day gap between Visit 2 and Visit 3, with only the leaked password retried, suggests the operator is checking whether the target re-enabled the compromised credential.

🛡️ Our Response — From Detection to Remediation

This dossier is not just analysis — it triggered a real defensive response. Here is what happened when we discovered the scope of the targeting:

Action 1

Honeypot Credential Analysis — Routine analysis of 76,249 honeypot credential attempts identified two campaigns with targeted, personal knowledge. Investigation escalated from "interesting patterns" to "active threat."

Action 2

Credential Audit — Verified whether any of the 6 targeted passwords were still active on any system. One constructed password (handle + keyboard walk) was found active on internal SSO accounts.

Action 3

Emergency Credential Rotation — All affected accounts had passwords rotated with new high-entropy credentials within hours of discovery. New passwords generated with argon2id hashing (time_cost=3, memory_cost=65536).

Action 4

Infrastructure-Wide Password Sweep — Every service, script, cron job, monitoring probe, and Kubernetes secret using the compromised credential was identified and updated. Multiple deployment targets (systemd services, K8s manifests, monitoring databases, deployed scripts) were all patched.

Action 5

Cross-Correlation Verification — All 42 campaign IPs were checked against CrowdSec, auth.log, syslog, Traefik, Authelia, and Loki. Confirmed: zero lateral movement, zero web-based attempts, zero compromise.

Action 6

2FA Verification — Confirmed all web-facing services protected by Authelia with mandatory TOTP or hardware security keys. Even if a password were guessed, the second factor blocks access.

Timeline: From initial honeypot analysis → credential identified as active → emergency rotation completed → all services verified → this dossier published. The honeypot didn't just detect the attack — it triggered the remediation that neutralized the risk before it could be exploited.

🚨 Indicators of Compromise (IOCs)

Campaign A — Source IPs (19)

136.0.251.107    # SPARKED HOST LLC, US (AS397032) — primary node, 543 attempts
37.77.150.223    # PROTON66, RU (AS198953) — known bulletproof hosting
161.132.53.175   # Red Cientifica Peruana, PE (AS3132)
87.106.149.146   # IONOS, DE (AS8560) — ⚠️ CROSS-CAMPAIGN PIVOT
174.138.57.46    # DigitalOcean, US (AS14061)
161.132.38.88    # Red Cientifica Peruana, PE (AS3132)
211.37.174.180   # Korea Telecom, KR (AS4766)
152.70.91.107    # Oracle Corporation, US (AS31898)
130.61.190.249   # Oracle Corporation, US (AS31898)
49.12.209.227    # Hetzner, DE (AS24940)
178.104.220.57   # Hetzner, DE (AS24940)
157.245.87.15    # DigitalOcean, US (AS14061)
204.168.170.106  # Hetzner, DE (AS24940)
185.182.187.151  # Contabo, DE (AS51167)
167.172.64.25    # DigitalOcean, US (AS14061)
212.227.146.182  # IONOS, DE (AS8560)
178.18.243.195   # Contabo, DE (AS51167)
86.48.25.218     # Contabo Inc., US (AS40021)
159.89.244.38    # DigitalOcean, US (AS14061)

Campaign B — Source IPs (23)

190.8.175.6      # SpedyNet Telecom, BR (AS271011) — Ganymed_null
195.3.220.88     # MEVSPACE, PL (AS201814) — MOST REVEALING: all 6 passwords across 3 visits
143.202.208.242  # Red Paraguaya Telecom, PY (AS264631) — Ganymed_null
161.97.175.65    # Contabo, DE (AS51167) — Ganymed_null
103.40.188.143   # UIH, TH (AS38794) — paramiko 2.12.0, [REDACTED_PASSWORD_E] only
146.190.230.216  # DigitalOcean, US (AS14061) — Ganymed_null
203.144.76.188   # CAMGSM Cellcard, KH (AS17976) — paramiko 4.0.0, personal usernames
197.156.73.177   # EthioNet, ET (AS24757) — 20 rapid attempts with full email + real name
150.241.116.234  # XORA, GB→US (AS215590) — paramiko 3.4.0
54.36.107.28     # OVH, FR (AS16276) — SSH-2.0-Go
146.56.175.142   # Oracle BMC, JP (AS31898) — SSH-2.0-Go, reversed family name
69.55.49.49      # DigitalOcean, US (AS14061) — SSH-2.0-Go, mail subdomain
62.171.187.208   # Contabo, DE (AS51167) — SSH-2.0-Go
51.195.118.158   # OVH, FR (AS16276) — SSH-2.0-Go
71.19.147.24     # prgmr.com, US (AS47066) — SSH-2.0-Go
193.40.147.36    # EENET, EE (AS3221) — SSH-2.0-Go, Estonian academic network
66.42.91.230     # Vultr, US (AS20473) — SSH-2.0-Go, mail subdomain username
88.99.38.128     # Hetzner, DE (AS24940) — SSH-2.0-Go
198.98.58.139    # FranTech/PONYNET, US (AS53667) — SSH-2.0-Go, known bulletproof hosting
116.203.142.168  # Hetzner, DE (AS24940) — SSH-2.0-Go
50.198.160.188   # Comcast Cable, US (AS7922) — SSH-2.0-Go, residential IP
103.26.136.30    # GRAMEEN Communications, BD (AS58946) — paramiko 2.12.0, [REDACTED_PASSWORD_E] only
87.106.149.146   # IONOS, DE (AS8560) — SSH-2.0-Go — ⚠️ CROSS-CAMPAIGN PIVOT (also Campaign A)

SSH Client Fingerprints (HASSH)

# Campaign A — libssh brute-force framework (19 IPs)
03a80b21afa810682a776a7d42e5e6fb  # libssh 0.11.x — primary SPARKED node
f93d28ee0c77e2612b27491518d909f4  # libssh 0.10.6 — dominant fingerprint (11 IPs)
3335afa7a75e84f8348f05c623c5ecf9  # libssh 0.9.6
944eec3005f2db3a98d8ac77f714d070  # libssh 0.9.3
495ca0813b1c4f9c1d7fc18e45e3956c  # libssh 0.7.1
70e363185f617f7b0e5aa1e6cba68722  # libssh 0.8.7

# Campaign B — OSINT / credential stuffing toolkit (23 IPs)
0a07365cc01fa9fc82608ba4019af499  # SSH-2.0-Go — Phase 3 dominant (12 IPs)
16443846184eafde36765c9bab2f4397  # SSH-2.0-Go — cross-campaign pivot, includes ML-KEM 768 (post-quantum)
1ab01ea559275860be73fe29c5d077bd  # Ganymed_null — Phase 1 (4 IPs)
a2de0f306611e0957be704f5b0e35a82  # paramiko 3.5.1 / 4.0.0
a704be057881f0b1d623cd263e477a8b  # paramiko 2.12.0 (TH + BD IPs — [REDACTED_PASSWORD_E] probes)
1df281da760a0c16d115179a9ea5957c  # libssh2 1.10.0 (ET IP — rapid personal targeting)
87e3d9ffee0540b0390f8a5b9c343c08  # paramiko 3.4.0

🗺️ MITRE ATT&CK Mapping

Tactic	Technique	ID	Campaign
Reconnaissance	Active Scanning: Vulnerability Scanning	`T1595.002`	A, B
Reconnaissance	Gather Victim Identity: Email Addresses	`T1589.002`	B
Reconnaissance	Gather Victim Identity: Credentials	`T1589.001`	B
Reconnaissance	Gather Victim Org: Business Relationships	`T1591.002`	B
Reconnaissance	Search Open Technical DBs: WHOIS	`T1596.002`	B
Reconnaissance	Search Open Technical DBs: Certificates	`T1596.003`	B
Reconnaissance	Search Open Websites/Domains	`T1593`	A, B
Resource Dev	Acquire Infrastructure: VPS	`T1583.003`	A, B
Resource Dev	Compromise Infrastructure: Server	`T1584.004`	B
Resource Dev	Obtain Capabilities: Tool	`T1588.002`	A
Initial Access	Brute Force: Credential Stuffing	`T1110.004`	B
Initial Access	Brute Force: Password Spraying	`T1110.003`	A
Initial Access	Brute Force: Password Guessing	`T1110.001`	A

📚 Lessons Learned & Defensive Takeaways

✅ What Worked (Defense)

Honeypot captured full attack telemetry — awareness before damage
Leaked credentials had already been rotated — zero successful logins
Previously-exposed service had been secured before the attack
All web services protected by Authelia SSO with mandatory 2FA (TOTP/security keys)
CrowdSec community threat-intel feed had all 42 IPs pre-banned
Emergency credential rotation triggered by analysis — remediated within hours
326 algorithmically-generated passwords: 0% success rate
72+ surgical OSINT-based attempts: 0% success rate

⚠️ What This Reveals (Risk)

Leaked credentials persist in attacker databases indefinitely
Exposed services get catalogued even after being secured
Personal information (names, family, nationality) is weaponizable
Running services can be enumerated and used as username targets
Attackers invest in multi-week, multi-phase reconnaissance
Password patterns (handle + keyboard walk) are predictable to sophisticated attackers
A single breach can seed entirely new attack campaigns months later
Attackers use post-quantum cryptography in their tools — they're evolving

🔧 Recommended Actions for Infrastructure Operators

SSH key-only authentication — disable password auth on all exposed SSH services
Multi-factor authentication — enforce 2FA (TOTP or hardware keys) on all web-facing services via a centralized SSO gateway
WHOIS privacy — enable registrant privacy on all domains to limit personal OSINT surface
Service exposure audit — regularly scan your own infrastructure and minimize exposed management interfaces
Breach monitoring — subscribe to HaveIBeenPwned and similar services for all associated emails
Certificate transparency monitoring — track new certificates issued for your domains
Avoid password patterns — handles, keyboard walks, and cultural words are predictable; use generated high-entropy passwords
HASSH-based detection — the identified HASSH fingerprints can be used in IDS/IPS rules
Deploy honeypots — this entire analysis was possible because a honeypot captured the attempts. Without it, the targeted nature of these attacks would have been invisible in standard firewall logs
Credential rotation after any exposure — rotate ALL credentials when any service is exposed, not just the directly affected ones

📌 We See Everything

This dossier documents what happens when opportunistic scanning meets targeted intelligence — and when the target is paying attention. Among ~76,000 generic brute-force attempts from ~2,900 IPs, two campaigns stood out — not because of their volume, but because of their knowledge.

The attacker knew our domain, our services, our names, our family, and our old passwords. They reversed a family member's name, wrote "thank you" in our native language, constructed a password from our handle and a keyboard walk, tried the default for Apache Guacamole (wrong technology), and generated 326 passwords from our domain using leetspeak and year-based suffixes. They used 42 IPs across 16 countries, rotated between SSH toolkits, and deployed a post-quantum key exchange algorithm in their final probe.

We reverse-engineered their password generation algorithm. We reconstructed their OSINT workflow step by step. We identified every IP, every fingerprint, every credential, every username they tried. We traced the single IP that links both campaigns. We checked every log source across our infrastructure and confirmed zero lateral movement. We identified the credential they constructed — and rotated it within hours.

They failed because every leaked credential had been rotated. They failed because the exposed service had been secured. They failed because every web service requires two-factor authentication — a password alone is not enough. And when their reconnaissance uncovered a constructed credential that was still active, our honeypot analysis detected it and triggered emergency rotation before it could be exploited.

The internet remembers every service you've ever exposed, every credential you've ever leaked, and every name you've ever published. The difference between a breach and a dossier is whether you're watching your own honeypots.

We were watching.

Data source: Cowrie SSH honeypot (port 2222). Analysis period: March 25 – May 7, 2026 (44 days). All IOCs are published for community defense. Personally identifiable information has been redacted from this public report. Full unredacted version retained for law enforcement and incident response purposes.