• 15 min read

30 days of SSH honeypot observations

Patterns, credentials, and insights from a month of SSH brute-force attack data collected across our distributed sensor network.

honeypots research
⚠
Responsible Use

This content is published for defensive and educational purposes only. Do not use this information for unauthorized access or malicious activities.

Executive summary

Over 30 days, our distributed honeypot network observed 847,291 SSH connection attempts from 12,847 unique IP addresses across 142 countries. This report documents the attack patterns, credential combinations, and post-exploitation behavior we observed.

Scope

Infrastructure: 7 honeypot nodes deployed across North America, Europe, and Asia-Pacific

Timeframe: November 1-30, 2024

Collection method: Modified OpenSSH with session recording, integrated with Cowrie for extended interaction logging

Key findings

Attack volume

MetricValue
Total connection attempts847,291
Unique source IPs12,847
Countries observed142
Peak attacks/hour4,521
Average attacks/hour1,176

Top source countries

  1. China (CN) — 34.2%
  2. Russia (RU) — 18.7%
  3. Brazil (BR) — 8.4%
  4. Vietnam (VN) — 6.2%
  5. India (IN) — 5.1%

Note: Geographic attribution is based on GeoIP databases and may not reflect the true origin of attacks. Use of VPNs, proxies, and compromised hosts makes definitive attribution impossible.

Credential analysis

We captured 2,847,103 username/password combinations. The top 20 most attempted credentials reveal predictable patterns:

Most common usernames

root        - 67.3%
admin       - 12.1%
user        - 3.2%
test        - 2.8%
ubuntu      - 1.9%
postgres    - 1.4%
mysql       - 1.1%
oracle      - 0.9%
guest       - 0.7%
pi          - 0.6%

Most common passwords

123456              - 4.2%
admin               - 3.8%
password            - 3.1%
root                - 2.9%
123456789           - 2.4%
admin123            - 2.1%
1234                - 1.8%
12345               - 1.7%
password123         - 1.5%
changeme            - 1.3%

Interesting patterns

We observed several domain-specific credential patterns:

  • IoT-focused: admin:admin, root:root, pi:raspberry
  • Database-focused: postgres:postgres, mysql:mysql, oracle:oracle
  • Router-focused: admin:1234, admin:password, cusadmin:highspeed

Post-authentication behavior

When credentials succeeded (using deliberate weak passwords on select honeypots), we observed consistent post-authentication patterns:

Stage 1: Reconnaissance (0-30 seconds)

uname -a
cat /etc/passwd
w
id

Stage 2: Persistence (30-120 seconds)

Most attackers attempted to:

  1. Add SSH keys to ~/.ssh/authorized_keys
  2. Create new user accounts
  3. Modify crontab for persistence
  4. Download second-stage payloads

Stage 3: Payload deployment

The most common payloads observed:

Malware familyPercentagePurpose
XMRig variants42.3%Cryptomining
Mirai variants28.1%DDoS botnet
Generic backdoors15.7%Persistent access
IRC bots8.4%C2 communication
Unknown5.5%Under analysis

Temporal patterns

Daily distribution

Attack volume peaked between 14:00-18:00 UTC, correlating with business hours in East Asia. Minimum volume occurred between 04:00-08:00 UTC.

Weekly distribution

Surprisingly, we observed no significant variation between weekdays and weekends, suggesting these attacks are largely automated rather than human-operated.

Network indicators

Observed C2 infrastructure

During payload analysis, we identified command-and-control servers communicating over:

  • IRC: Ports 6667, 6697
  • HTTP(S): Ports 80, 443, 8080
  • Custom protocols: Ports 3333, 5555, 7777

Disclosure: We have shared relevant indicators with appropriate threat intelligence sharing communities.

Defensive takeaways

Based on our observations, we recommend the following defensive measures:

Immediate actions

  1. Disable password authentication — Use SSH keys exclusively
  2. Implement fail2ban — Automatic IP blocking after failed attempts
  3. Change default SSH port — Reduces automated scanning (not security through obscurity, but reduces noise)
  4. Use allowlisting — Restrict SSH access to known IP ranges where possible

Monitoring recommendations

  1. Monitor for SSH connections from unexpected geographic regions
  2. Alert on new entries in authorized_keys files
  3. Monitor for cryptocurrency mining processes (high CPU usage)
  4. Implement network flow analysis for unusual outbound connections

Infrastructure hardening

# Example sshd_config hardening
PasswordAuthentication no
PermitRootLogin no
MaxAuthTries 3
AllowUsers deployer

Methodology notes

  • All data was collected passively on systems we own
  • No active probing or exploitation was performed
  • IP addresses have been anonymized in this report
  • Full IoC data available to verified security researchers upon request

Conclusion

The SSH attack landscape remains dominated by automated credential stuffing campaigns. The consistent patterns we observed suggest a relatively small number of botnets responsible for the majority of activity. Organizations should treat any internet-exposed SSH service as under constant attack and implement appropriate defenses.

This research was conducted on infrastructure we own and operate. No unauthorized access to third-party systems was performed or attempted.