{
	"id": "967b045d-5672-48ed-aa73-b9cc0697038f",
	"created_at": "2026-04-06T00:14:45.536359Z",
	"updated_at": "2026-04-10T03:19:56.347191Z",
	"deleted_at": null,
	"sha1_hash": "6d97a17bca6f99909a203bb960b94c513bcbde5b",
	"title": "The Mirai Botnet: A Look Back and Ahead At What's Next",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 648562,
	"plain_text": "The Mirai Botnet: A Look Back and Ahead At What's Next\r\nBy SANS Internet Storm Center\r\nArchived: 2026-04-05 20:29:13 UTC\r\nIt is a bit hard to nail down when the Mirai botnet really started. I usually use scans for port 2323 and the use of\r\nthe password \"xc3511\" as an indicator. But of course, that isn't perfect. The very first scan using the password\r\n\"xc3511\" was detected by our sensor on February 26th, 2016, well ahead of Mirai. This scan hit a number of our\r\nsensors via ssh. At the time we did not collect telnet brute force attempts. Oddly enough, it was a singular scan\r\nfrom one IP address (185.106.94.136) . Starting August 9th, 2016, we do see daily scans for the password xc3511\r\nat a low level until they increase significantly around September 21st, which is probably the best date to identify\r\nas the outbreak of what we now call Mirai. I will use \"Mirai\" to identify the family of aggressive telnet scanning\r\nbots. It includes a wide range of varieties that all pretty much do the same thing: Scan for systems with telnet\r\nexposed (not just on port 23) and then trying to log in using a default password.\r\nFigure 1: Port 2323 Scanning for 2016.\r\nOne of the first questions that keep coming up is how many hosts were or still are infected with Mirai. A back of\r\nthe envelope calculation can be done by looking at the current rate of these scans. An average IP address will be\r\nhit once every 10 minutes. In my tests, I found that an infected system can scan about 200 IPs per second. To scan\r\nthe entire internet, it will take an infected system about 200 days (accounting for the fact that Mirai does not scan\r\nabout 20% of the IP address space). So to be hit about once every 10 minutes, we need only about 30,000 infected\r\nsystems. This is likely a low estimate. I have seen a lot of Mirai connection attempts fail because the scanning\r\nhttps://isc.sans.edu/diary/22786\r\nPage 1 of 3\n\nsystem isn't responding in time, likely because it is not able to keep up with the scans. For port 23 scans, we do\r\nsee around 100-150,000 sources each day. This is not just Mirai, but other bots as well. Port 2323 only sees around\r\n5-10,000 sources per day. These are likely remnants of the original Mirai versions. Later versions did not use port\r\n2323 as much as earlier versions. So a reasonable estimate of infected systems is likely in the \"more than 100,000\"\r\nrange. \r\nFigure 2: Decay of port 2323 scans and best fit.\r\nNow the next question is: \"How long will all this last\". I took a look a the port 2323 traffic, to see how it decayed\r\nover the last year. Like I have seen in prior bot outbreaks all the way back to Nimda/CodeRed, the decay is best\r\nmatched using two components: A \"fast part\" of systems that are patched relatively fast, and a \"slow\" part of\r\nsystems that take much longer to fix. For SQL Slammer, for example, the \"fast\" part was patched in a few hours,\r\nwhile the \"slow\" part was patched \"never\". For Mirai, the \"fast\" decay has a half life of 12 days, which is still\r\npretty slow. The \"slow\" part has a half life of 150 days, and 1/3 of infected systems are part of the \"slow\" curve.\r\nThe result: Mirai is going to stick with us for a few more years. There are many efforts underway to reach out to\r\ninfected systems and to protect them. But for Mirai, these efforts appear to have reached a point of diminishing\r\nreturns. Unlike SQL Slammer, Mirai does not affect the host network enough to force a fix, and the fix isn't all that\r\neasy (often there is no simple \"patch\". And the password can not be changed by the user). \r\nA system is only \"removed\" from the infected pool if it is patched, retired or placed behind a firewall. A system\r\nthat is rebooted will likely get infected immediatly so we do not have to account for them. The is possibly also a\r\ncomponent of new systems connected to the internet. I did not account for them, but they would become part of\r\neither the short or long \"half-life\" component and just increase the amplitude of either. I will try and run a\r\nsimulation for that as well later.\r\nhttps://isc.sans.edu/diary/22786\r\nPage 2 of 3\n\nSo what is next?\r\nMirai and related bots/worms will stay around for the foreseeable future. There is no reason to believe that all\r\nbackdoor passwords (aka \"Support Passwords\") have been found. Just last week news broke about such passwords\r\nin some Arris DSL modems. Exploiting these passwords is too easy and there isn't much that can be done by the\r\nuser to protect the device. These are often not passwords that the user can change. In some cases, a firewall may\r\nwork, unless the firewall itself is vulnerable. A lot of attention was paid to security camera DVRs and IP cameras,\r\nbut Mirai infects pretty much any Linux based device with guessable telnet password. SSH will not help either.\r\nSSH is as vulnerable to default passwords as telnet. Mirai itself doesn't scan for ssh, but other bots do and have\r\ndone so for a long time. In the end, this is something that has to be fixed by the manufacturer of these devices, not\r\nby the end user. The end user may be able to help by stop buying vulnerable devices, but then again, there isn't an\r\neasy way for the end user to tell. Maybe some kind of \"security seal\" that indicates that the device did go through\r\na basic pentest and will provide security updates for a specific number of years will help. But Mirai vulnerable\r\ndevices are likely still sold today, and due to a large variety of brand names reselling essentially the same device,\r\nit is hard to tell if a device is vulnerable or not.\r\n---\r\nJohannes B. Ullrich, Ph.D., Dean of Research, SANS Technology Institute\r\nSTI|Twitter|\r\nSource: https://isc.sans.edu/diary/22786\r\nhttps://isc.sans.edu/diary/22786\r\nPage 3 of 3",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://isc.sans.edu/diary/22786"
	],
	"report_names": [
		"22786"
	],
	"threat_actors": [],
	"ts_created_at": 1775434485,
	"ts_updated_at": 1775791196,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/6d97a17bca6f99909a203bb960b94c513bcbde5b.pdf",
		"text": "https://archive.orkl.eu/6d97a17bca6f99909a203bb960b94c513bcbde5b.txt",
		"img": "https://archive.orkl.eu/6d97a17bca6f99909a203bb960b94c513bcbde5b.jpg"
	}
}