{
	"id": "ebb07f09-ea18-4794-994b-df7bff437b77",
	"created_at": "2026-04-06T00:22:14.241772Z",
	"updated_at": "2026-04-10T03:21:41.419973Z",
	"deleted_at": null,
	"sha1_hash": "6c45c51f995a2fe6cb498bdf31dca18fc3318815",
	"title": "MMD-0065-2020 - Linux/Mirai-Fbot's new encryption explained",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2001445,
	"plain_text": "MMD-0065-2020 - Linux/Mirai-Fbot's new encryption explained\r\nPublished: 2020-01-15 · Archived: 2026-04-05 14:48:17 UTC\r\nPrologue\r\n[For the most recent information of this threat please follow this ==\u003e link]\r\nI setup a local brand new ARM base router I bought online around this new year 2020 to replace my old pots, and\r\nyesterday, it was soon pwned by malware and I had to reset it to the factory mode to make it work again (never\r\nhappened before). When the \"incident\" occurred, the affected router wasn't dead but it was close to a freeze state,\r\nallowing me to operate enough to collect artifacts, and when rebooted that poor little box just won't start again. So\r\nfor some reason the infection somehow ruined the router system.\r\nAs the summary for this case, in the router I found an infection trace of Mirai Linux malware variant called\r\n\"FBOT\", an ARM v5 binary variant, and it is just another modified version of original Mirai malware (after a long\r\nlist of other variants beforehand). The infection came from a malware spreader/scanner attack from \"another\"\r\ninfected internet of things explained later on.\r\nThere is an interesting new encryption logic on its configuration section in the binary, alongside with the usage of\r\n\"legendary\" Mirai table's encryption, so hopefully this write-ups will be useful for others to dissect the threat. This\r\nmay not be an easy reading one you and is a rather technical post, but if you are in forensics or reverse\r\nengineering on embedded platforms i.e. IoT or ICS security, you may like it, or, please bear with it. To make the\r\npost small and neat I won't go to further detail on router matter itself, and just go straight to the malicious binary\r\nthat caused the problem, Mirai, is also a malware with a well-known functionality by now. It would be helpful if\r\nyou know how it works beforehand. So I'll focus to the new decryption part of the artifact.\r\nI changed my analysis platform since SECCON 2019, I use \"Tsurugi Linux SECCON edition\", a special built\r\nversion by Giovanni, with hardened/tested by me, supported by the \"Trufae\" for radare2's r2ghidra \u0026 r2dec pre-installing process during the SECCON 2019 time. It's a Linux distribution for binary \u0026 forensics analysis, Tsurugi\r\nis enriched with pre-compiled r2 with many architecture decompilers (i.e.: r2ghidra, r2dec and pdc), along with\r\nton of useful open source binary analysis, DFIR tools with the OSINT/investigator's mode switch. This OS should\r\nsuffice the analysis purpose. A new feature of r2ghidra (also r2dec) are used a lot. (The thank's list is in the\r\nEpilogue part).\r\nThe tool's version info:\r\n1\r\n2\r\n3\r\n:\u003e !r2 -v\r\nradare2 4.1.0-git 24455 @ linux-x86-64 git.4.0.0-235-g982be50\r\ncommit: 982be504999364c966d339c4c29f20da80128e14 build: 2019-12-17__10:29:05\r\nhttps://blog.malwaremustdie.org/2020/01/mmd-0065-2020-linuxmirai-fbot.html\r\nPage 1 of 14\n\n4\r\n5\r\n6\r\n:\u003e !uname -a\r\nLinux tsurugiseccon 5.4.2-050402-tsurugi #1 SMP Tue Dec 10 21:18:57 CET 2019 x86_64 x86_64\r\nx86_64 GNU/Linux\r\n:\u003e\r\n(click the image to check details..)\r\nOkay, let's write this, here we go..\r\nThe infection\r\nAfter successfully getting logs and cleaning them up, below is the timeline (in JST) that contains the infection\r\ndetail:\r\nWe can see one IP address 93(.)157(.)152(.)247 was gaining a user's login access, after checking of infection\r\ncondition and following by confirming previous infection binary instance, it downloaded and executed the \".t\"\r\nhttps://blog.malwaremustdie.org/2020/01/mmd-0065-2020-linuxmirai-fbot.html\r\nPage 2 of 14\n\npayload that was fetched from other IP 5(.)206(.)227(.)65 afterwards. Other interesting highlights from this\r\ninfection are: It flushes all the rules in the \"filter\" table of iptables; Scanning (previous) infections; The usage of\r\nSATORI keyword during checking (which is actually not the original one since the original author has been\r\narrested) and the downloading tool used is either the tftp or wget.\r\n1\r\n2\r\nfbot-arm: ELF 32-bit LSB executable, ARM, version 1, statically linked, stripped\r\n3ea740687eee84832ecbdb202e8ed743 fbot-arm\r\nThe compromised IoT that was infecting my device is this kind --\u003e [link] a made-in-China(PRC) \"GPON OLT\"\r\ndevice. It is important to know that they are vulnerable to this Mirai variant's infection.\r\nDuring firstly detected, FBOT was running as per Mirai suppose to work, and from the COMM serial connection\r\n(telnet \u0026 SSH wasn't accessible due to high load average) we can see it runs like below list of file result:\r\nThe IP 5(.)206(.)227(.)65 is also functioned as this FBOT C2 server that looks \"out of service\" during the above\r\nsnapshot was taken.\r\nSo the binary that was executed was somehow deleted the itself. I can not recover it. An interesting randomized\r\nprocess name is running on a memory area that is showing a successful infection. So, being careful not to shutting\r\ndown the load average 10 something small system I dumped the binary from memory as per I explained in the\r\nR2CON2018 [link] and 2019.HACK.LU [link] presentations I did, then, I saved and renamed the binary into\r\n\"fbot-arm\" for the further analysis purpose.\r\nThe memory maps is a good guidance for this matter, the rest of memory and user space are clean, note: you have\r\nto be very careful to not freezing the kernel or stopping the malware during the process. I was lucky to install tools\r\nneeded for hot forensics before the infection occurred.\r\nThe binary analysis\r\nhttps://blog.malwaremustdie.org/2020/01/mmd-0065-2020-linuxmirai-fbot.html\r\nPage 3 of 14\n\nThe dumped ARM binary can be seen in radare2 like this detail, which it looks a plain stripped ARM may came\r\nup as result from cross compilation.\r\nThe binary headers, entry points and sections don't show any strange things going on too, I think we can deal with\r\nthe binary contents right away..\r\nThe new encryption and the decryption\r\nWhen seeing Fbot binary's strings, I found it very interesting to see that there's a \"Satori botnet's signature\", that\r\nwas used for scanning vulnerable telnet by Satori botnets, that string is also written hard-coded in this FBOT\r\nhttps://blog.malwaremustdie.org/2020/01/mmd-0065-2020-linuxmirai-fbot.html\r\nPage 4 of 14\n\nbinary:\r\nThe same string is also detected during the infection log too. this coincidence(?) is really a \"Deja Vu\" to logs seen\r\nin the Mirai Satori infection era within 2017-2018. But let's focus to the encryption strings instead.\r\nThere are two groups of encrypted configuration data (Mirai usually uses encrypted configuration data before\r\nbeing self-decrypted during the related execution process), but one of group of data looks like encrypted in a new\r\ndifferent logic.\r\nThe first group of the data (the orange colored one) is in a form of encryption pattern that is not commonly found\r\nin Mirai binaries before, which is the point of this post actually. And the blue-colored one is the data configuration\r\nthat have been encrypted in pattern that is being used in table.c:table_init() of bot client, to then unlocking them\r\nfor the further usage in malicious process like telnet scanning (scanner_init), or the other functions in Mirai\r\nhttps://blog.malwaremustdie.org/2020/01/mmd-0065-2020-linuxmirai-fbot.html\r\nPage 5 of 14\n\noperation. The blue color part's encryption method is a known one, we can later see its decrypted values too.\r\nThe first configuration (encrypted) data will be firstly loaded by table.c:add_entry() variant function of MIrai,\r\nbut during the further process it is processed using a new different decryption. Summarizing this method in a\r\nsimpler words: that different decryption is a shuffle of alphabetical character set, based on a XOR'ed key that\r\npermutes its position.\r\nLet's access the .rodata section in address 0xf454 where the first group data-set is located. When you get there,\r\nafter checking the caller reference, it will lead you to a function at 0x9848 that's using those crypted values, see\r\nbelow:\r\nhttps://blog.malwaremustdie.org/2020/01/mmd-0065-2020-linuxmirai-fbot.html\r\nPage 6 of 14\n\nIf you go to the top of the function and see (address 0x984c and 0x9858) how two string-sets are loaded from\r\naddresses 0x10020 and 0x10062 to be passed into a function in 0x975C with their length of 0x42 as secondary\r\nargument.\r\nThe two set loaded string-sets are saved in the ARM binary in this location:\r\nhttps://blog.malwaremustdie.org/2020/01/mmd-0065-2020-linuxmirai-fbot.html\r\nPage 7 of 14\n\nThere is a XOR key with value 0x59 applied to obfuscate the strings that was previously mentioned..\r\nBack to the function in 0x9848, the rest of the encrypted configuration data (the rest of \"orange\" ones) is parsed\r\ninto function in 0x9780.\r\nFunction 0x9780 seems to be a modification of a table.c:add_entry() function in the original Mirai code (or\r\nsimilar variants), the modified (or additional) part is a decoder logic of the parsed data. The parsed data will be\r\ntranslated against the character map formed after XOR'ed that is stored in the memory, to have its desired result.\r\nI hope the below loop graph is good enough to explain how the decoder works statically (I have adjusted\r\neverything to fit into one image file).\r\nhttps://blog.malwaremustdie.org/2020/01/mmd-0065-2020-linuxmirai-fbot.html\r\nPage 8 of 14\n\nI think it would be better for you to see this first modified encryption config data process in the way it is called\r\nfrom the Mirai's table_init() function reversed as per below:\r\nThis should be close enough to what adversary has coded.\r\nDynamically, the character mapping process used to translate the encrypted strings can also be simulated in\r\nradare2 during on-memory analysis (it will be in the heap memory area somewhere if you want to confirm it) as\r\nhttps://blog.malwaremustdie.org/2020/01/mmd-0065-2020-linuxmirai-fbot.html\r\nPage 9 of 14\n\nper below result:\r\nSo, additionally, static or dynamic reversing can produce same result. I always prefer the static one since I don't\r\nhave to run any malware code just to crack its configuration.\r\nThe encoder table, in text! (enjoy!)\r\n1\r\n2\r\n3\r\nMLSDFQWYXNCZRPOKGIUTABVHEJtfqomaechlynudwvjrxigkzsbp7890254163=@^$\r\nABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789./ -\r\nI announced it yesterday in twitter [link], below is the decryption result:\r\nhttps://blog.malwaremustdie.org/2020/01/mmd-0065-2020-linuxmirai-fbot.html\r\nPage 10 of 14\n\nSince Mirai is coded in a way to make reverse engineering difficult, what you reverse in its binary's code-flow is\r\nnot what has actually had been coded in C, please noted this, in example, In Mirai, the usage of global variables\r\nand the global structs, the #define or #ifdef directives used, the method to unlock encryption process-used-variable values and then lock them all back afterwards, and many other tricks used and designed for the sake of\r\nobstruction the reverse engineering. There is no shame in not reversing the overall codes into original ones,\r\nespecially what you get is embeded-platform system's binary like ARM or MIPS or SH with way simpler\r\nassembly code. Reversers know this. Don't let this discourage you for not be proactive in reversing, but keep\r\nlearning from it and learning it more.\r\nBack to our binary, the timing on when the first and second encrypted configuration were decrypted during\r\nmalware execution process is different too. This is is the rough C flow of what this ARM binary process looks like\r\nduring being executed, it's enough to explain my point, which is, the timing when the first configuration was\r\nexecuted is when the process of infection is happening, and the second configuration is used for the\r\nspreading/scanning purpose, which will be used afterward.\r\n(Warning! The function's namings above are self-made naming for my reversing purpose and not the actual ones, I\r\ndon't have ESP power to read the mind of the coder by reading his stripped binary, so please bear with differences\r\netc..)\r\nThe static code above can be easily filled with its argument values with two ways, following the registers or after\r\nyou see how the malicious binary can be simulated its system calls, below is the snip code of what I did (the latter\r\nmethod) to show how this binary was executed as per flow above to reveal its values:\r\nhttps://blog.malwaremustdie.org/2020/01/mmd-0065-2020-linuxmirai-fbot.html\r\nPage 11 of 14\n\nNow we know for sure why I didn't get the file because it was self-deleted after running at the first time.\r\nNo. We are not done yet..\r\nAs you can see in the decrypted strings, it has mentioned \"pizza dongs helper\". And the C2 for this Mirai variant\r\nhas been obviously shown during infection stage (the data is saved in the configuration part that can be achieved\r\nby table.c at \"init\" process), it is on IP 5(.)206(.)227(.)65, if you do OSINT and seeking passive DNS data of the\r\nIP address, you will see some similar hostnames and domains to the wording used in the decryption data.\r\nBelow is the example of hostnames \u0026 domains linked to the C2 IP from a passive database:\r\nIt's same domain that also has been registered in multiple IP around the globe:\r\nWe keep on monitoring the spreader movement of this malware, these are several pickups of IoT devices log that\r\nis actively seeking for other vulnerable ARM devices. I sorted out in timeline base. I hope the carriers that's\r\nhaving vulnerable devices on the list can pay attention to address this issue.\r\nThe IOC and STIX2 of this threat is in the posting process to usual portals.\r\nhttps://blog.malwaremustdie.org/2020/01/mmd-0065-2020-linuxmirai-fbot.html\r\nPage 12 of 14\n\nLastly, as additional, the alleged botnet coder/owner has just sent his compliment, which is rare, so I attached in\r\nthis blog too:\r\nEpilogue\r\nThis post is dedicated to wonderful people who fight tirelessly against IoT threat that keep on aiming our devices\r\nuntil now, and also to people who try very hard to push new policy to have us defend better for the threat. I hope\r\nthis post helps you.\r\nThank you very much to r2ghidra, r2dec, r2 folks, tsurugi linux folks, MMD mates and friends, and all I can not\r\nmention in here, for supporting our effort in analyzing Linux malicious code all the time.\r\n[Edit] Thu Jan 23 2020, thank you Security Affairs for the historical background and insights of Mirai and Fbot.\r\nThis technical analysis and its contents is an original work and firstly published in the current MalwareMustDie\r\nBlog post (this site), the analysis and writing is made by @unixfreaxjp.\r\nThe research contents is bound to our legal disclaimer guide line in sharing of MalwareMustDie NPO research\r\nmaterial.\r\nhttps://blog.malwaremustdie.org/2020/01/mmd-0065-2020-linuxmirai-fbot.html\r\nPage 13 of 14\n\nMalware Must Die!\r\nSource: https://blog.malwaremustdie.org/2020/01/mmd-0065-2020-linuxmirai-fbot.html\r\nhttps://blog.malwaremustdie.org/2020/01/mmd-0065-2020-linuxmirai-fbot.html\r\nPage 14 of 14",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blog.malwaremustdie.org/2020/01/mmd-0065-2020-linuxmirai-fbot.html"
	],
	"report_names": [
		"mmd-0065-2020-linuxmirai-fbot.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434934,
	"ts_updated_at": 1775791301,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/6c45c51f995a2fe6cb498bdf31dca18fc3318815.pdf",
		"text": "https://archive.orkl.eu/6c45c51f995a2fe6cb498bdf31dca18fc3318815.txt",
		"img": "https://archive.orkl.eu/6c45c51f995a2fe6cb498bdf31dca18fc3318815.jpg"
	}
}