Piping code

Discovered a “new” way in which an attacker can transfer files to the honeypot without HonSSH being able to detect or intercept the file. This issue was only detected when the IDS started sending alerts about outbound SSH attacks.

The instance was not configured to send any email alerts, so i figured that someone had compromised the honeypot and downloaded some malware but, there was no entries in the downloads.log or any downloads directory in the sessions file structure. The only obvious thing was a EXEC session log, these are the entries that show the activity of the attacker

20160214_122650_425601 - [EXEC0] Opened Channel
20160214_122650_426107 - [EXEC0] Command Executed: mkdir /tmp/.xs/
20160214_122651_364395 - [EXEC0] Closed Channel
20160214_122651_647226 - [EXEC1] Opened Channel
20160214_122651_647703 - [EXEC1] Command Executed: cat >/tmp/.xs/daemon.i686.mod
20160214_122714_097971 - [EXEC1] Closed Channel
20160214_122714_641976 - [EXEC2] Opened Channel
20160214_122714_642469 - [EXEC2] Command Executed: chmod 777 /tmp/.xs/daemon.i686.mod
20160214_122715_559964 - [EXEC2] Closed Channel
20160214_122715_836329 - [EXEC3] Opened Channel
20160214_122715_836800 - [EXEC3] Command Executed: /tmp/.xs/daemon.i686.mod
20160214_122716_420530 - [EXEC3] Closed Channel
20160214_122716_421130 - [SSH  ] Lost Connection with 1.2.3.4

The only thing that raised a red flag was the size of the adv-log’s, some of them were larger than 3 MB, after digging trough them i discovered the following strings

• \xeaUPX!\xd8
  UPX
• \x7fELF\x01
  ELF

Given the size of the adv-log’s and the presence of these strings we can assume that the attacker used SSH to move binary files to the honeypot.

After a couple of tests i think i figured out how the attacker did this. It’s possible to pipe things from the local host into a SSH EXEC session.

echo "Test Test Test" | ssh -l derp 10.13.111.57 'cat - > /tmp/pipe_in_exec.txt'

This will pipe the output from the echo over SSH to /tmp/pipe_in_exec.txt on 10.13.111.57. Given that this is possible, might it be that the attacker used a similar technique to transfer the file?

Is this something that should be within the scope of HonSSH to catch/intercept/detect?

[bang-uin]

@tnich would you mind having a look at https://github.com/bang-uin/honssh/commits/feature/fs_watch and telling me what you think about the inotify approach?

[bang-uin]

These are just hints and infos for everyone who likes to test that branch. I’ll create a wiki page if this branch gets at some point merged into the master.