A few Mirai Updates: MIPS, PPC version; a bit less scanning

A few Mirai Updates: MIPS, PPC version; a bit less scanning
Since Friday, the Mirai botnet has become kind of a household name. I have been continuing to watch the botnet infect my test DVR over and over. A couple of things I have seen over the weekend: Overall port 23/2323 scanning activity seems to have gone down a bit. It looks like the countermeasures ISPs are taking show some limited success At least some of the host names Mirai uses for C&C no longer resolve. However, the host my copy uses to pull down the actual malware, 77.247.181.219 seems to be still active. So far I have observed versions for ARM, MIPS, and PowerPC (which would work for some Cisco equipment). Mirai is going after other devices then DVRs, but given the hard coded "xc3511" password, DVRs appear to be the richest source of vulnerable hosts. SHA1 hashes for the different versions: 8924926be722b5c50a16ed3c8a121dd81d229539 mirai.arm7 8c56f28cbe59724a7e63ecc4273dd1f661da8b7a mirai.mips c0c18e56bbf4c514f34ed8f6204fbe1dba351efe mirai.ppc We get a lot of requests from people asking how to identify infected devices. The simplest method is to look for devices that establish a lot of new outbound connections on port 23 and 2323. So just look for "tcp[13]=2 and (port 23 or port 2323)". They will stick out... look for dozens/hundreds of packets per second. But as a rule of thumb: if you know how to do this, chances are you are not vulnerable. Prior articles about Mirai: ISC Briefing: Large DDoS Attack Against Dyn (with PPT slides for you to use) Dyn.com DDoS Attack The Short Life of a Vulnerable DVR Connected to the Internet (includes full packet capture of an infection) The Internet of Evil Things: How to Detect and Secure Your Vulnerable Devices from the Mirai Botnet (Webcast) ------ Johannes B. Ullrich, Ph.D. STI\|Twitter\|LinkedIn	Johannes 4277 Posts ISC Handler Oct 24th 2016
Thread locked Subscribe	Oct 24th 2016 4 years ago
	John Hardin 62 Posts
Quote	Oct 26th 2016 4 years ago
I'm going to say the same thing I said on Krebs' blog: it looks like it's time to dust off LaBrea. https://sourceforge.net/projects/labrea/ My telnet tarpit is catching a lot lately (less so the last few days). If this was done more widely then scanning for vulnerable IoT (and other) devices would be a lot more difficult and less attractive.	John Hardin 62 Posts
Quote	Oct 26th 2016 4 years ago
I have been thinking about Mirai botnet for a while. As per the information that I have assessed. It's caused using IOT devices such as DVR's, IP Cameras etc which have the default password for telnet tcp 23 or 2323. So Mirai uses these IOT devices to attack using various denial of service attacks that I looked up on their source code page at git hub. But if I understand right most ISP's do not provide static IP Addresses. Without any type of NAT how would the hackers connect to the IOT devices? Even if Busybox was present on my IOT devices I can only connect to it from my internal network. Without NAT I wouldn't be able to connect to it from the external network at all. As per the Mirai Source code that I had a look at, the code includes a scanner to look for IOT devices and connect to it. Why cant we use the same scanner to detect these compromised devices and ensure remote connectivity is not possible by disabling NAT and providing some alternate solution. Am I on the right track or am I missing something from my assessment.	John Hardin 2 Posts
Quote	Nov 5th 2016 4 years ago

Since Friday, the Mirai botnet has become kind of a household name. I have been continuing to watch the botnet infect my test DVR over and over. A couple of things I have seen over the weekend:

Overall port 23/2323 scanning activity seems to have gone down a bit. It looks like the countermeasures ISPs are taking show some limited success
At least some of the host names Mirai uses for C&C no longer resolve.
However, the host my copy uses to pull down the actual malware, 77.247.181.219 seems to be still active.
So far I have observed versions for ARM, MIPS, and PowerPC (which would work for some Cisco equipment). Mirai is going after other devices then DVRs, but given the hard coded "xc3511" password, DVRs appear to be the richest source of vulnerable hosts.
SHA1 hashes for the different versions:
8924926be722b5c50a16ed3c8a121dd81d229539 mirai.arm7
8c56f28cbe59724a7e63ecc4273dd1f661da8b7a mirai.mips
c0c18e56bbf4c514f34ed8f6204fbe1dba351efe mirai.ppc
We get a lot of requests from people asking how to identify infected devices. The simplest method is to look for devices that establish *a lot* of new outbound connections on port 23 and 2323. So just look for "tcp[13]=2 and (port 23 or port 2323)". They will stick out... look for dozens/hundreds of packets per second. But as a rule of thumb: if you know how to do this, chances are you are not vulnerable.

Prior articles about Mirai:

ISC Briefing: Large DDoS Attack Against Dyn (with PPT slides for you to use)

Dyn.com DDoS Attack

The Short Life of a Vulnerable DVR Connected to the Internet (includes full packet capture of an infection)

The Internet of Evil Things: How to Detect and Secure Your Vulnerable Devices from the Mirai Botnet (Webcast)

------
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Johannes

4277 Posts
ISC Handler

Oct 24th 2016

John Hardin

62 Posts

I'm going to say the same thing I said on Krebs' blog: it looks like it's time to dust off LaBrea.

https://sourceforge.net/projects/labrea/

My telnet tarpit is catching a lot lately (less so the last few days). If this was done more widely then scanning for vulnerable IoT (and other) devices would be a lot more difficult and less attractive.

John Hardin

62 Posts

I have been thinking about Mirai botnet for a while. As per the information that I have assessed. It's caused using IOT devices such as DVR's, IP Cameras etc which have the default password for telnet tcp 23 or 2323.

So Mirai uses these IOT devices to attack using various denial of service attacks that I looked up on their source code page at git hub.

But if I understand right most ISP's do not provide static IP Addresses. Without any type of NAT how would the hackers connect to the IOT devices?

Even if Busybox was present on my IOT devices I can only connect to it from my internal network. Without NAT I wouldn't be able to connect to it from the external network at all.

As per the Mirai Source code that I had a look at, the code includes a scanner to look for IOT devices and connect to it.

Why cant we use the same scanner to detect these compromised devices and ensure remote connectivity is not possible by disabling NAT and providing some alternate solution.

Am I on the right track or am I missing something from my assessment.

John Hardin
2 Posts