Death of the Internet, Film at 11
clinton.mielke at gmail.com
Sun Oct 23 12:12:49 UTC 2016
A number of people are asking for advice on how to detect this bug. Here
are some thoughts. Im a mathematician, and not a network operator, so would
The source code of Mirai is here, and Ive had some fun taking it apart over
the last week:
* Primary infection vector is via telnet scanning. Port 23 is literally
hardcoded in. 10% of the time, it scans for port 2323. Found that odd, but
I suppose one of the devices its targeting uses that port.
* The malware disables any services running on ports 22, 23, and 80,
primarily to prevent other infection opportunities. This surprises me, for
I figured that killing port 80 might attract attention from the device
owner, but evidently the risk of reinfection is too high to not do it. See
* The malware uses a large set of signatures to kill other bots running in
memory, like QBot. I find this interesting. A script kiddie wont, but a
more sophisticated adversary could add Mirai itself to this list of
signatures to out compete the released variant of the code. You can see the
library of signatures here :
Digging around, I found that several samples of Mirai related malware have
been uploaded and processed by the Indian honeynet's Linux sandbox. Heres a
>From the host connectivity log, you can see all of the port 23 scanning
activity. The scanning is completely random, and not sequential, hopping
all over the place. From a detection standpoint, that is where I would
start, but this assumes that the hosts on your network are actively
scanning and not lying dormant.
This file, starting on line 124, has all of the hard-coded passwords that
the malware uses to login to telnet sessions:
- Googling around, you can find the make and model number that each of
those user/password combinations are associated with. Brian compiled a list
My question for you guys, since Im a theoretician and not a seasoned
operator: how feasible or legal is it to find telnet scanning activity or
any of these passwords in high-bandwidth netflows? If its feasible, then
this at least gets you the active scanning population of hosts, along with
the IPs of all of their victims.
Aside from the active scanning population, finding dormant hosts might only
be feasible if we know the list of C&Cs used, which can very widely. For
Mirai in particular, the actual bot itself is delivered via tftp or wget
from another dropper host. Take a look at this other sample for this kind
of behavior. It connects to a webserver in the netherlands and pulls down
the payload binary:
I think its unlikely that skilled users of this malware would keep using
the default 'mirai.arm7' payload, but evidently some are in the wild!
Finding these http drops might help you find recent successful infections.
More importantly however, the payload delivered itself will have
information about the C&C, which if we as a community gather and analyze,
we can find more easily the total set of dormant devices waiting to attack.
Ultimately if you know the C&C being used, you can much more easily find
Im going to pull apart the server code next. About time I learn GO...
Lastly, studying this malware long enough, some techniques jump to mind
which could hypothetically infect and patch a large number of vulnerable
hosts. Im sure someone brave enough might do this. Totally worked out for
On Sun, Oct 23, 2016 at 3:16 AM, Florian Weimer <fw at deneb.enyo.de> wrote:
> * Randy Bush:
> >> What does BCP38 have to do with this?
> > nothing technical, as these iot attacks are not spoofed.
> How do you know? Has anyone disclosed specifics?
> I can understand that keeping details under wraps is sometimes
> required for operational security, but if the attacks are clearly
> succeeding, I would have expected those who posted “do something,
> now!” messages at least some pointer to technical details of what was
> going on.
> Not that the underlying threat will go away until we find a way to
> clean up almost all of the compromised devices (and without breaking
> the Internet along the way, forever).
More information about the NANOG