The signature is the absence
3,399 sessions did something very specific: authenticate and hang up. Not a single ls, not a wget, not one line. That's 2.4% of the traffic — a minority, but with a clear intent. Unlike an intrusion, which leaves a trail (commands, downloads, files), the probe leaves exactly the opposite: a successful authentication followed by nothing.
That stillness is the signal. In your logs it doesn't look like an attack: it looks like a user who logged in and left. That's why it goes unnoticed, and why it's worth hunting before the validated credential is actually used.
Which credentials they try: the clue is crypto
Here's the interesting part. Looking at ALL of the honeypot traffic (not just the silent probes), the most-tried username/password pairs aren't generic: they point to Solana infrastructure.
solana / solana (2.930) · sol / sol (2.879) · solv / 123456 (2.322) · ubuntu / ubuntu (2.210) · sol / 123 (2.045)
Four of the five most-tried pairs are service accounts on the Solana network (sol, solana, solv): validators and nodes. This isn't generic brute force; it's a campaign that hunts crypto machines by name.
The rest of the noise: GPU hunting
The sessions that do run commands tell the other half of the story: the three most-used commands are uname (49.4%), lspci (20.2%) and nvidia-smi (12.4%). It's hardware reconnaissance — the attacker checks whether the machine has a GPU before deciding what to do with it. The silent probe and the GPU hunt could be two faces of the same operation: validating access and cataloguing crypto targets.
Validate today to use tomorrow? An honest hypothesis
The usual explanation for probing is credential validation for deferred use: one node confirms which pairs work and another, later and from a different IP, exploits them. Splitting the two tasks makes correlation harder and keeps the probe "harmless".
In all honesty: we present it as a hypothesis consistent with known botnet tactics. We're adding our own metric to measure how many of the probing IPs later come back to run commands; until it's consolidated, we don't claim the full chain as fact.
How to hunt it
Hunting a probe is easier than hunting an intrusion, precisely because its signature is inactivity:
- Alert on sessions with no commands: an SSH connection that authenticates and disconnects within seconds without running anything is a probe. Any SIEM detects it with a simple rule.
- Watch your service accounts by name: if you run crypto infrastructure, users like
sol/solana/solvare an explicit target; rename them and disable password access. - Disable password login: against a probe that only tries username/password pairs, SSH keys leave it with nothing to validate.
See it on your own dashboard
This isn't abstract theory: it's what you'd see on the CipherSentry dashboard with your own nodes — every probe, every credential tried and every origin, in real time.
What your logs aren't telling you
The most uncomfortable thing about this pattern is that it doesn't look like an attack. You won't see an "intrusion": you'll see a "successful authentication". If that credential is validated today, the day someone uses it they'll come in looking legitimate. Hunt the probe —the session that comes in and leaves without doing anything— instead of waiting for the noisy phase: by then, it won't look like an attack anymore.
Data collected for cybersecurity research purposes. Figures taken from the KPIs of the CipherSentry SSH honeypot in production (window 2026-06-11 to 2026-06-19). All information comes from unsolicited activity recorded on our own infrastructure.