Investigation Writeup: Automated SSH Credential-Testing Session via Honeypot

Environment

• Honeypot: Cowrie SSH honeypot deployed on a VPS, internet-facing (real SSH moved to a non-standard port to avoid Cowrie intercepting legitimate access)
• Pipeline: Cowrie → Wazuh (SIEM) → TheHive (case management) → MISP (threat intelligence)
• Collection period: Honeypot has been live and accumulating traffic for roughly two weeks; the session investigated here occurred on 2026-06-25

Summary

Six Wazuh alerts, generated across three SSH connections from a single source IP (46.29.25.17), were investigated end-to-end: from the initial Wazuh alert, through case-building in TheHive, to raw log verification on the honeypot itself, and enrichment against MISP, AbuseIPDB, and Cloudflare Radar. The investigation concluded this was a low-sophistication, automated credential-testing script rather than a targeted or high-capability actor. No shell commands were executed, and no evidence of follow-on exploitation exists.

The Alert (Hypothesis)

Wazuh’s alert view was filtered across roughly 870 accumulated Cowrie-sourced alerts, grouped by source IP to identify a small, contained candidate rather than a sprawling multi-IP campaign. 46.29.25.17 stood out with exactly six alerts across a short window, demonstrative of a single attacker session, not an ongoing campaign.

Initial hypothesis: an SSH client authenticated successfully against the honeypot and may have attempted post-login activity.

Investigation

Step 1: Initial triage and case-building in TheHive

The six alerts (three pairs of “public key login failed” → “password login succeeded” events, one pair per connection) were pulled into a single TheHive case. Chronological ordering by data.timestamp — not the order TheHive listed them in — was necessary to correctly reconstruct the sequence, since two events in the same session landed only ~15ms apart.

#	Timestamp (UTC)	Session ID	Event	Rule / MITRE
1	17:13:04.802	c68d69d57f61	Public key login failed	100100 / T1110
2	17:13:04.817	c68d69d57f61	Password login succeeded (wronguser/wrongpassword)	100101 / T1078
3	17:16:05.174	e26af0a575e7	Public key login failed	100100 / T1110
4	17:16:05.189	e26af0a575e7	Password login succeeded	100101 / T1078
5	17:19:05.668	e564eb4ba94c	Public key login failed	100100 / T1110
6	17:19:05.684	e564eb4ba94c	Password login succeeded	100101 / T1078

Step 2: Verifying against raw Cowrie logs

Wazuh’s alerts only reflect events matching a configured rule, so the raw cowrie.json log on the VPS was pulled directly (via out-of-band console access, after confirming the real SSH port had itself been intercepted by Cowrie) to check for any activity beyond what was alerted on.

Findings, per session:

• Sessions 1 and 2 authenticated, then never requested a shell channel at all (no cowrie.log.closed event present). The connection simply sat open until the client dropped it at almost exactly 180 seconds in both cases (180,350ms and 180,451ms respectively). This is consistent with a client-side timeout.
• Session 3 did request a shell (a TTY log was opened and closed), but disconnected in under 2 seconds. Its shasum e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855matches the SHA-256 hash of an empty input; Cowrie hashes attacker input only (not honeypot output), meaning zero keystrokes were typed before disconnect.
• All three sessions shared an identical client fingerprint: SSH client version OpenSSH_10.0, hassh eddaa729291d392ab89d32773bd23ef9, and the same offered SSH public key, confirming one automated script, not multiple actors or a human retrying manually.

(Confirmed: zero cowrie.command.input events across all three sessions)

Step 3: MISP correlation

Feed cache status was confirmed fresh (cached within the prior 24 hours) before treating an empty result as meaningful. Searching MISP’s attribute index for 46.29.25.17 returned no correlation, concluding that this IP has no known-bad history in any currently subscribed OSINT feed.

Step 4: External reputation check (AbuseIPDB)

46.29.25.17 returned a 13% confidence of abuse across 20 reports from 6 distinct sources spanning roughly a year (March 2025 – present). Categories were generic and inconsistent (Port Scan, Hacking, Brute-Force, DDoS Attack, Bad Web Bot) rather than a concentrated pattern of SSH-specific attacks. Consistent with low-grade, opportunistic scanning infrastructure rather than a serious, targeted actor.

Step 5: Hosting/ASN context

The IP resolves to AS215224 (NovoServe B.V.), a Dutch hosting provider. Cloudflare Radar’s ASN-level bot traffic tool showed 91.6% bot traffic originating from this ASN over the prior 4 weeks, with a visible spike between June 24–26. This provides broader context on the hosting environment generally, but since this reflects aggregate HTTP traffic across NovoServe’s entire customer base, not SSH traffic specifically, nor traffic attributable to this IP alone, it isn’t presented as evidence connecting this spike to the sessions investigated in this report.

MITRE ATT&CK Mapping

| Technique | Name | Evidence | | ——— | ————– | ————————————————————————————————————- | | T1110 | Brute Force | Public key authentication attempts, rejected, prior to password fallback | | T1078 | Valid Accounts | Password login “succeeded” (Cowrie’s default accept-anything behavior — not an actual compromised credential) |

Attack Narrative

A single automated script connected to the honeypot three times over a five-minute window, on an almost exact three-minute cadence. Each connection followed the same pattern: offer a public key (rejected), fall back to password authentication (accepted, per Cowrie’s default behavior), then either sit idle until a ~180-second client-side timeout (sessions 1 and 2) or open a shell and abandon it within two seconds without typing anything (session 3). No commands were ever executed. This is consistent with a mass-scanning credential-testing tool checking for open SSH access at scale, rather than a targeted intrusion attempt.

Verdict

Confirmed benign automated reconnaissance/credential-testing activity. No shell commands were executed in any of the three sessions, and no evidence of follow-on exploitation, payload delivery, or data exfiltration exists. Consistent with routine internet background noise rather than a targeted attack.

(Note: this source IP shares a campaign UUID with unrelated IPs seen elsewhere in the honeypot’s traffic, suggesting shared botnet infrastructure. That broader campaign was deliberately left out of scope for this writeup and ==may be a subject for future investigation==.)

Lessons Learned

• Wazuh’s alert view only shows what matched a configured rule. Raw log verification on the source system caught meaningful detail (the zero-byte session, the missing shell requests) that the alerts alone didn’t surface.
• A “no results” MISP search is only meaningful once feed cache freshness is confirmed, otherwise it’s indistinguishable from stale data.
• A well-known constant (the SHA-256 hash of an empty string) turned out to be directly diagnostic here, once I understood exactly what Cowrie’s shasum field measures (attacker input only).
• Keeping this investigation scoped to one IP, instead of following the shared campaign UUID out to every other IP using it, kept the writeup focused and finishable.

Appendix: Sanitized Log Excerpt

{"eventid":"cowrie.session.connect","src_ip":"46.29.25.17","src_port":52445,"dst_ip":"[HONEYPOT_IP]","dst_port":2222,"session":"c68d69d57f61","protocol":"ssh"}
{"eventid":"cowrie.login.failed","username":"wronguser","key":"ssh-ed25519 AAAA...","message":"public key login attempt for [wronguser] failed","session":"c68d69d57f61"}
{"eventid":"cowrie.login.success","username":"wronguser","password":"wrongpassword","message":"login attempt [wronguser/wrongpassword] succeeded","session":"c68d69d57f61"}
{"eventid":"cowrie.session.closed","duration_ms":180350,"message":"Connection lost after 180350 milliseconds","session":"c68d69d57f61"}