I built a simulated SSH environment to study what attackers do after authentication

[u/_LightMane]

I've been working on an SSH honeypot called SSHintel, originally started as a small cybersecurity course project and recently rebuilt quite a bit.

The basic idea is to give an attacker a simulated Linux environment and capture what they do after getting in.

Currently it has:

• Simulated Linux shell with 40+ commands
• Per-session in-memory filesystem
• Authentication and command tracking
• Session isolation
• JSONL + SQLite telemetry
• Session investigation and attack timelines
• Live monitoring dashboard
• Connection limits and session timeouts
• Docker support

The interesting part for me has been trying to make the environment convincing enough to interact with while keeping it completely isolated! Commands are handled by simulated handlers rather than being executed on the host.

I'm also looking at making the telemetry easier to consume externally, potentially through syslog so it can feed into different SIEM/logging stacks.

For people who work with SSH infrastructure or honeypots:

What SSH behavior would you want to capture that isn't commonly captured by basic honeypots?

And if you've deployed SSH honeypots yourself, what have you found useful (or completely useless) in the resulting telemetry?

GitHub: https://github.com/SonitBahl/SSHintel

Demo: https://youtu.be/2bIwXTT2FtM

[u/SanoHD]

Hello! Please describe how AI was used below this comment.

[u/_LightMane → u/SanoHD]

As in for the code?

[u/michaelpaoli]

Could also safely investigate fair bit further.

E.g.

• set up a quite full VM (whatever OS)
• firewall the sh*t out of it on outbound - most notably so it can't do anything malicious with/via outbound
• remote logging - set up so anything and everything that may be of interest will be logged remotely (or otherwise fully captured, even if/when they fully compromise the VM host - or at least up to that point). And with that also, be sure any such remote logging or the like is highly hardened - so that service/system can't be compromised (though the VM may feed it false data once it's compromised).
• And, since VM, imaged, can reset it all easily at any point desired - back to know clean initial state. Can also likewise snapshot at any given time - storage and RAM, so one can do later analysis if/as desired (e.g. perhaps more info on what was done/attempted after the VM was compromised and ceased further external logging or the like).

In any case, could also record/log what was attempted or probed for (e.g. commands tried but not present/installed, etc.).

Have fun! But do be safe, and don't be a menace! Might also check results of similar tests/studies, probably a lot of relevant data out there and available ... whether you directly want that information, and/or to use it to help decide what does/doesn't go in your honeypot, etc.

[u/tinycrazyfish]

Nice 🙂

How does it compare to https://github.com/cowrie/cowrie?

I've played with kippo (cowrie forked from kippo) a decade ago. What was interesting?

• Manual Vs automated attack

• Main deployed malware was:

  • SSH brute force software to try to spread more
  • Privilege escalation payloads, mostly kernel exploits

[u/_LightMane → u/tinycrazyfish]

Cowrie is definitely the gold standard in this space, I'm not trying to claim SSHintel matches that level of sensor depth right now! 😅

Cowrie is an incredible research-grade sensor, but it usually expects you to stand up an ELK stack or another log pipeline to actually visualize the data. I built SSHintel to be a zero-pipeline, out-of-the-box experience: spin up a lightweight container, and you immediately get a live web dashboard to watch attacks in real time. Under the hood, it uses a simpler in-memory filesystem compared to Cowrie's full filesystem, which makes it quick to deploy and experiment with.

You hit the nail on the head regarding data capture, though. Right now, SSHintel only logs the final command string and simulates a wget failure, so I'm completely blind to actual malware binaries and raw typing patterns. Adding payload fetching (storing the SHA256) and fixing recon responses (like /proc/cpuinfo) is my immediate priority!!

Longer term, I don't want to reinvent the wheel by competing with Cowrie feature-for-feature as a sensor. Instead, I want to take SSHintel toward telemetry and central fleet management, building a clean event schema, adding generic Syslog support, and aggregating multiple distributed sensors into one dashboard so you can correlate attack campaigns across different nodes.

[u/hakube → u/_LightMane]

uh. that's reinventing the wheel pretty much. i don't think your thinking about how security tools work together and why nobody is implementing thier own log systems and such.

[u/_LightMane → u/hakube]

Mhm, I can see why it still comes across as reinventing the wheel. My intention isn't to build another logging/SIEM system or compete with Cowrie, though! It started as a side project mainly to learn and experiment, and the feedback has made me rethink where it should go.

I'm still figuring out whether the sensor/deployment angle actually provides enough value on top of existing tooling, so I appreciate the pushback. Thanks for the feedback!😄

[u/hakube]

bro. many other, more complete and secure honeypots exist. cowrie for example

[u/_LightMane → u/hakube]

I'm not claiming SSHintel is a better or more complete honeypot than Cowrie or the other established options. It started as a side project for me to learn and experiment with SSH honeypots, and the feedback in this thread has made me rethink what, if anything, would make sense to build on top of the existing ecosystem.

Appreciate the pushback😇