I noticed a high volume of SSH password attempts on my server and installed the Cowrie honeypot to see what the attacker(s) would do if they actually got access.

I've identified consistent patterns across many attacks that I believe are automated. Immediately upon identifying a working username/password, the remote system sends the following commands, with a 4 second delay between commands:

free -m
ps x

then the remote system disconnects.

Another variant sends 2 commands per second, starting with those 3 and adding cat /proc/cpuinfo before disconnecting.

I would like to identify the tool/script/attack framework that performs these automated attacks. Does that behavior pattern look familiar to anyone? I have searched for likely candidates without success.

  • Yes, "fingerprinting" the automated tool is exactly what I'm hoping to do. I looked for automated ssh attack tools/scripts but didn't find one that seems to match the behavior I'm seeing - but the attacks seem to be coming from different sources, even with very similar behavior, so I suspect that this is a script/bot/whatever that's being run by curious people, not a sophisticated attack from a determined adversary. But I'd like to understand what's being used against my server(s). – gbroiles Nov 28 '16 at 3:34
  • Honestly this looks like a bonnet trying random things that are successful now and then – Henry F Dec 16 '16 at 0:18

First, the pattern of behavior you're seeing is likely because the malware has detected that it's running in a sandboxed environment. CPU count for your honeypot should be greater than two, if it's not already because most new malware auto terminates if there are two or less CPU cores available, and the processes of your honeypot should not be visible to attackers' software because some of the better written malware will check if honeyd or other well known honeypot daemons are running or installed. An easy option for limiting process/fs visibility is to look up "firejail" and how to setup custom profiles. Hint: strace output can be parsed and added to firejail profiles to hide/disable listing of host file system and running processes.

Second, look into running a Snort tap between your honeypot and its network connection to capture and fingerprint the attacks network traffic in near real time. I've had good luck with using Raspberry Pis for network monitoring for low cost.

Third, consider using dedicated hardware for your honeypot to make it look more like a legit victim; search term "system on a chip" (wiki has a list of manufacturer) for available cheap options. The one from Intel is the one I'd suggest for this because the architecture looks very close to a legit victims' desktop.

Fourth, look into Metasploit honeypot detection source code for kippo and others to make your honeypot less detectable because there maybe some other clever ways that attacks are detecting their being observed.

Fifth, checkout detection of metasploit reverse shells article using "carbon black" for after honeypot intrusion detection. Be careful using the tools to hack them back; if you're going to try, do only the minimum investigation needed to identify the criminals. Even if they attacked you first, it is still a crime to hack them back.

  • Thanks John Deters for the edit, note on fifth option, I'm not suggesting to hack back but instead notifications of reverse shell activity ;-) hack backs are generally a bad idea beyond the simi-legalities involved; instead I'd suggest toying with attackers in order to discern if they're live or bot based off behavior. – S0AndS0 Dec 16 '16 at 0:48

Your Answer

