THREAT INTEL · JUNE 2026 · 6 MIN READ

The 9,484 Session Hour: Anatomy of a Coordinated SSH Scanning Event

At 14:00 UTC on June 20, 2026, the MIRAGE Frankfurt sensor recorded 9,484 SSH intrusion sessions in a single hour — more than five times the dataset average of approximately 1,800 sessions per hour. The spike lasted exactly 60 minutes and then stopped. This post documents what the data shows about the infrastructure behind it.

THE NUMBERS

The hour-14 UTC spike is the single largest traffic event in the 11-day MIRAGE capture window. For context:

Dataset average: ~1,800 sessions/hour
Hour 14 UTC: 9,484 sessions
Multiplier: 5.3x the average

The spike was not distributed across many IPs arriving simultaneously. It was dominated by a single source:

IP              | Sessions | Avg Duration | Window
45.74.0.24      | 7,562    | 169ms        | 14:19–14:47 (27 min)
176.65.132.17   | 622      | 129ms        | 14:26–14:59
176.65.139.102  | 511      | 163ms        | 14:00–14:59
176.65.139.249  | 427      | 195ms        | 14:00–14:54
91.92.42.64     | 255      | 3,401ms      | 14:00–14:59

45.74.0.24 alone accounts for 79.8% of the hour's traffic. It fired 7,562 sessions in 27 minutes — approximately 4.7 sessions per second sustained for the entire window — then stopped completely at 14:47.

TWO DISTINCT SCANNER PROFILES

The data reveals two behaviorally distinct scanner classes operating simultaneously during hour 14.

Profile A — High-velocity, short-duration (45.74.0.24, 176.65.132.x):
Average session duration: 129–195ms
Sessions per minute: sustained high rate
Behavior: connect, submit one credential, disconnect immediately
This is pure credential stuffing at maximum throughput. The 169ms average duration for 45.74.0.24 is below the TCP handshake + SSH negotiation + auth round-trip floor for most connections — suggesting the scanner is optimized to minimize time-per-attempt above all else.

Profile B — Lower-velocity, longer-duration (91.92.42.64, 91.92.40.240):
Average session duration: 1,987–3,401ms
Sessions per minute: ~4 (one every ~14 seconds)
Behavior: connect, wait, submit credential, disconnect

91.92.42.64 maintained 14-second intervals almost exactly, consistent with a configured rate limiter — possibly to avoid triggering fail2ban or similar defenses on target infrastructure. The 3,401ms average duration suggests this scanner waits for a full server response before proceeding.

These two profiles operating simultaneously from different IPs suggests coordinated infrastructure with differentiated roles: one component floods at maximum rate while another probes more carefully.

THE CREDENTIAL PATTERNS

The credentials attempted during the spike reveal something unexpected. The top attempts during hour 14 included:

username: claude    credential: claude        (4 attempts)
username: claude    credential: 123           (4 attempts)
username: claude    credential: claude123     (4 attempts)
username: claude    credential: password      (4 attempts)
username: pi        credential: 12345678      (5 attempts)
username: postgres  credential: 123           (5 attempts)
username: crafty    credential: 12345678      (4 attempts)

The claude username targeting is notable. claude is not a standard Linux system username and does not appear in common wordlists for generic credential stuffing. Its presence suggests either a purpose-built wordlist targeting Anthropic-adjacent infrastructure naming conventions, or an unusually comprehensive general wordlist that includes names unlikely to appear on most servers.

WHAT STOPPED IT

At 14:47 UTC, 45.74.0.24 stopped. Not gradually — completely. The session rate from that IP dropped to zero inside one minute. The remaining IPs continued at their lower baseline rates through the rest of the hour.

This termination pattern — abrupt, complete, time-bounded — is consistent with a scheduled job completing its run rather than a human operator deciding to stop. The 27-minute window for 7,562 sessions suggests a pre-configured batch size or time limit was reached.

INFRASTRUCTURE CONTEXT

45.74.0.24 is part of a cluster that appears repeatedly in the MIRAGE dataset. Earlier analysis identified coordinated IPs across 3 Dutch ASNs with mathematically symmetric session counts (1,522 and 761 exact counts across multiple IPs). 45.74.0.24 with 7,562 sessions sits outside that symmetric pattern — suggesting it operates at a higher tier within the same infrastructure, handling burst scanning while the symmetric-count IPs maintain steady-state coverage.

WHAT THIS TELLS US

Three conclusions from the hour-14 data:

1. The infrastructure is tiered. Different IPs within the same botnet operate at different rates, with different session durations, suggesting role differentiation — bulk scanners and careful probers coordinated from the same C2.

2. The scanning is scheduled. Abrupt starts and stops on minute boundaries, pre-configured batch sizes, and consistent inter-session intervals all point to automated orchestration rather than manual operation.

3. Wordlists are broader than expected. The claude username in a scanning event at this scale suggests operators are using wordlists comprehensive enough to include non-standard usernames that would only matter against specific infrastructure.

DATASET

All findings derived from the MIRAGE honeypot dataset: 44,118 sessions, June 16–26 2026, Frankfurt sensor. Source: https://github.com/Mirage-Source/mirage-core