Clinton, This is excellent information. While it's not possible to see passwords in netflows (only headers are included, not packet contents), it's a sure thing that attacked victims could extract a list of infected machines from the IP address scan and then run verification scans against just those devices. Any confirmed infected devices could then be published on a blacklist, a la spam blockers. Providers then could either blackhole (at the source) or filter those addresses.
-mel > On Oct 23, 2016, at 5:20 AM, clinton mielke <[email protected]> wrote: > > 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 > love feedback. > > The source code of Mirai is here, and Ive had some fun taking it apart over > the last week: > https://krebsonsecurity.com/2016/10/hacked-cameras-dvrs-powered-todays-massive-internet-outage/ > > Notable findings: > > * 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 > line 88: > https://github.com/jgamblin/Mirai-Source-Code/blob/master/mirai/bot/killer.c > > * 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 : > https://github.com/jgamblin/Mirai-Source-Code/blob/master/mirai/bot/table.c > > 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 > sample: > https://detux.org/report.php?sha256=0b28b39f25c748b69369c18f72e937950826f189cd43227431384d34a0dce6fa > > 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: > https://github.com/jgamblin/Mirai-Source-Code/blob/master/mirai/bot/scanner.c > - Googling around, you can find the make and model number that each of > those user/password combinations are associated with. Brian compiled a list > actually: > https://krebsonsecurity.com/wp-content/uploads/2016/10/IoTbadpass-Sheet1.csv > > 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: > https://detux.org/report.php?sha256=996167e00f2aef787c432ca4ce4613edf39c5f83363b269137aff3a3e75af5a9 > > 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 > the bots. > > 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 > Robert Morris. > >> On Sun, Oct 23, 2016 at 3:16 AM, Florian Weimer <[email protected]> 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). >>
