{
	"id": "f80f7076-cee3-48c3-a63c-b36854b888ef",
	"created_at": "2026-04-06T00:10:33.545916Z",
	"updated_at": "2026-04-10T03:21:33.831922Z",
	"deleted_at": null,
	"sha1_hash": "84bc4dab007d6281ee243aa9673996b32cc41409",
	"title": "MMD-0066-2020 - Linux/Mirai-Fbot - A re-emerged IoT threat",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 4349431,
	"plain_text": "MMD-0066-2020 - Linux/Mirai-Fbot - A re-emerged IoT threat\r\nPublished: 2020-02-24 · Archived: 2026-04-05 16:04:05 UTC\r\nChapters: [TelnetLoader] [EchoLoader] [Propagation] [NewActor] [Epilogue]\r\nPrologue\r\nA month ago I wrote about IoT malware for Linux operating system, a Mirai botnet's client variant dubbed as\r\nFBOT. The writing [link] was about reverse engineering Linux ELF ARM 32bit to dissect the new encryption\r\nthat has been used by their January's bot binaries,\r\nThe threat had been on vacuum state for almost one month after my post, until now it comes back again, strongly,\r\nwith several technical updates in their binary and infection scheme, a re-emerging botnet that I detected its first\r\ncome-back activities starting from on February 9, 2020.\r\nThis post is writing several significant updates of new Mirai FBOT variant with strong spreading propagation and\r\ncontains important details that have been observed. The obvious Mirai variant capabilities and some leak codes'\r\nadapted known techniques (mostly from other Mirai variants) will not be covered.\r\nThis is snippet log of FBOT infection we recorded, as a re-emerging \"PoC\" of the threat:\r\nThe changes in infection activity\r\nInfection method of FBOT has been changed to be as per shown below, taken from log of the recent FBOT\r\ninfection session:\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 1 of 43\n\nAs you can see, there are \"hexstrings\" blobs pushed into the compromised IoT on a telnet CLI connection. That\r\nhexstrings is actually a small ELF binary adjusted to the architecture of the infected device (FBOT has a rich\r\nbinary factory to infect various Linux IOT supported CPU), to be saved as a file named \"retrieve\". This method\r\nis significantly new for Mirai FBOT infection, and other infection methods (in their scanner funcion) is more or\r\nless similar to their older ones. Mirai FBOT seems not to drop the legacy infection methods they use too, and the\r\nadversary is adding \"hexstring push\" way now to increase the bot client's infection probability. I will cover some\r\nmore changes in the next section.\r\nThe binary analysis\r\nIn this part we will analyze two binaries of the recent FBOT. One is the pushed hextstrings one with the ELF\r\nformat is in ARM v5 32bit little-endian. And for the other ELF, in this post I am picking up the Intel 64bit\r\nbinary, since my recent blogs and image-posts are all covering enough ARM or MIPS.\r\n1. ARM 32bit ELF downloader (the \"telnet\" loader) in pipes\r\nThe pushed-hexstrings is saved as file called \"retrieve\" which is actually a downloader for the Mirai FBOT bot\r\nclient binary. It was not the smallest downloader I've seen in ELF samples all of these years but it does the job\r\nwell. The binary is having this information:\r\n1\r\n2\r\n3\r\nretrieve: ELF 32-bit LSB executable, ARM, EABI4 version 1 (SYSV),\r\nstatically linked, stripped\r\nMD5 (retrieve) = d0a7194be28ce86fd68f1cc4fb9f5d42\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 2 of 43\n\n4\r\n5\r\nSHA1 (retrieve) = c98c28944dc8e65d781c8809af3fab56893efeef\r\n1448 Feb 23 03:04 retrieve\r\nSmall enough to put all strings in binary in a small picture :)\r\nThe binary is a plain and straight ELF file, with normal headers intact, without any packing and so on, it contains\r\nthe main execution part which is started at virtual address 0x838c and it will right away call to 0x81e8 where the\r\nmain activity are coded:\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\n/ 388: entry0 ();\r\n| |\r\n| |\r\n| |\r\n| `=\u003c 0x0000838c 95ffffea b 0x81e8\r\n- - - - - - - - - -\r\n[0x000081e8]\u003e pd\r\n|\r\n| 0x000081e8 f0412de9 push {r4, r5, r6, r7, r8, lr}\r\n| 0x000081ec 74319fe5 ldr r3, [aav.aav.0x000083fd]\r\n| 0x000081f0 98d04de2 sub sp , sp , 0x98\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 3 of 43\n\n12\r\n13\r\n14\r\n15\r\n16\r\n| 0x000081f4 0080a0e3 mov r8, 0\r\n: 0x000081f8 000000ea b 0x8200\r\n: :\r\nThe other part is the data, where all values of variables are stored. it is located from virtual address 0x83f4 at\r\nsection..rodata (0x83fc), as per shown below:\r\nTo call the saved data the ELF is using below loader scheme that has been arranged by the compiler:\r\nTo be noted that this scheme is unrelated to the malicious code itself.\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 4 of 43\n\nNext, the malware is stripped, so in radare2 you will see the name like \"fcn.00008xxx\", for every function names,\r\nfrom the original function coded by the mal-coder, the used Linux calls and the system calls. So, at first, we have\r\nto put the right naming to the right function if we can (Please check out my previous blog about Linux/AirDrop\r\n[link] for this howto reference). In my case, I restored its naming to the correct location, as per shown in the table\r\nlike this:\r\nNow we can start to read the code better, the next thing to do is writing the close-to-original C-code by adjusting\r\nseveral ARM assembly to form the code. Remember to be careful if you use the decompilers, you still have to\r\nrecognize several parts that can not be processed automatically, in example, in DFIR distro Tsurugi Linux which is\r\nhaving radare2 precompiled with three versions of decompiler plugins, you will see a cool result like this from\r\nr2ghidra-dec, r2dec and pdc.\r\nI will demonstrate this Linux distribution in the FIRST annual conference 2020 at the lighting talk, so please stay\r\ntune.\r\nAfter you put your naming to each functions, and try to form the original code by the guidance of your\r\ndecompiler, then try to re-check again to your binary flow. This binary is quite small but it has several error\r\ntrapping checks in the step of execution, please make sure you don't miss them.\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 5 of 43\n\nIn my case I reversed the source code to be something like this:\r\nAt this moment we can understand how it works, after firstly confirming the binary is for ARM5, it wrote\r\n\"MIRAI\" and creating socket for TCP connection to remote IP 194(.)180(.)224(.)13 to fetch the download URL\r\nof the bot binary payload. And it open the \".t\" file with the specific file executable permissions, then saved the\r\nreceived data into that file. Upon socket creation error, or C2 connection error, or file creation error, or also data\r\nretrieving error, this program will just quit after writing \"NIF\", and upon a success effort it will write \"FIN\",\r\nclose its working sockets and quit. A neat downloader is it? Simple, small and can support many scripting effort\r\ntoo, along with merit to hide its payload source, why Mirai botnet original author was using this type of binary\r\nloaders in the first place.\r\nThe code I reversed won't work if used, since it is a pseudo code, compiler won't process it, but it is enough to\r\nexplain how this binary operates, and also explains where is the origin of this program too. I know this by\r\nexperience since I have been dissecting and following Mirai from the day one [0][1][2][3][4], but this downloader\r\nis based on Mirai downloader that has been modified by a certain actor, again a leaked code is proven recycling.\r\nFor the practical purpose to fast extracting the payload URL in this type of FBOT loader, I made a very practical\r\nreversing crash course in 4 minutes for the purpose as per embedded below:\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 6 of 43\n\nEtt fel inträffade.\r\nDet går inte att köra JavaScript.\r\n(pause the video by pressing space or click the video screen)\r\n2. x86-64 ELF bot client, what's new?\r\nNow we are done with the first binary, so it is the turn of the next binary. In the download server at the path of\r\npayloads resides several architecture of binaries too. That's where I picked the ELF x86_64 one for the next\r\nreversing topic. The detail is as follows:\r\n1\r\n2\r\n3\r\n4\r\n5\r\nbot.x86_64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),\r\nstatically linked, stripped\r\nMD5 (bot.x86_64) = ae975a5cdd9fb816a1e286e1a24d9144\r\nSHA1 (bot.x86_64) = a56595c303a1dd391c834f0a788f4cf1a9857c1e\r\n31244 Feb 23 20:09 bot.x86_64*\r\nLet's check it out..\r\nThe header and entry0 (and entropy values if you check further) of the binary is showing the sign of packed binary\r\ndesign.\r\n1\r\n2\r\n3\r\n4\r\nProgram Headers:\r\nType       Offset              VirtAddr PhysAddr\r\nFileSiz MemSiz Flags Align\r\nLOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 7 of 43\n\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24\r\n25\r\n26\r\n27\r\n28\r\n29\r\n30\r\n0x000000000000790c 0x000000000000790c R E 200000\r\nLOAD 0x0000000000000e98 0x000000000060fe98 0x000000000060fe98\r\n0x0000000000000000 0x0000000000000000 RW 1000\r\nGNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000\r\n0x0000000000000000 0x0000000000000000 RW 8\r\n[Entrypoints]\r\nvaddr=0x004067d0 paddr=0x000067d0 haddr=0x00000018 hvaddr=0x00400018 type =program\r\n/ 2701: entry0 (int64_t arg1, int64_t arg2, int64_t arg3, int64_t arg4, int64_t arg_10h);\r\n| ===\u003e 0x004067d0 e8cb0b0000 call 0x4073a0 \u003c===to unpacking\r\n| 0x004067d5 55 push rbp\r\n| 0x004067d6 53 push rbx\r\n| 0x004067d7 51 push rcx\r\n| 0x004067d8 52 push rdx\r\n| 0x004067d9 4801fe add rsi, rdi\r\n| 0x004067dc 56 push rsi\r\n| 0x004067dd 4180f80e cmp r8b, 0xe\r\n| ,=\u003c 0x004067e1 0f85650a0000 jne 0x40724c\r\n: : 0x004067e7 55 push rbp\r\n: :\r\n- - - - - - - - - - - - - - - - - - - - - - -\r\n/ 34: fcn.004073a0 (); \u003c== unpacking function\r\n|\r\n| 0x004073a0 5d pop rbp\r\n| 0x004073a1 488d45f7 lea rax, [var_9h]\r\n| 0x004073a5 448b38 mov r15d, dword [rax]\r\n| 0x004073a8 4c29f8 sub rax, r15\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 8 of 43\n\n31\r\n32\r\n33\r\n34\r\n35\r\n36\r\n37\r\n38\r\n39\r\n40\r\n41\r\n| 0x004073ab 0fb75038 movzx edx , word [rax + 0x38]\r\n| 0x004073af 6bd238 imul edx , edx , 0x38\r\n| 0x004073b2 83c258 add edx , 0x58\r\n| 0x004073b5 4129d7 sub r15d, edx\r\n| 0x004073b8 488d0c10 lea rcx, [rax + rdx]\r\n| 0x004073bc e874ffffff call fcn.00407335\r\n: : : :\r\nThe binary snippet code:\r\nThe unpacking process will load the packed data in 0x004073c2 for further unpacking process. You can check my\r\ntalk in the R2CON 2018 [link] about many tricks I shared on unpacking ELF binaries for more reference to\r\nhandle this binary.\r\nAfter unpacking you will get a new binary with characteristic similar to this:\r\n1 fbot2-depacked: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 9 of 43\n\n2\r\n3\r\n4\r\n5\r\nstatically linked, stripped\r\nMD5 (fbot2-depacked) = bf161c87d10ecb4e5d9b3e1c95dd35da\r\nSHA1 (fbot2-depacked) = 3aecd1ae638a81d65969c2e0553cfacc639f32a6\r\n58557 Feb 23 13:03 fbot2-depacked\r\nIf you will see these strings that means you un-packed (or de-pakced) successfully.\r\nIn the string above you can see the matched data with the infection log, which is telling us that this binary is\r\nactually infecting and attacking another IoT device for the next infection. You can see that hardcoded in teh binary\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 10 of 43\n\nin this virtual address:\r\nThe binary is working similar to older Mirai variants like Satori, Okiru or others, and having several ELF\r\ndownloaders embedded in the bot client to be pushed during the infection process to the targeted devices. It is hard\r\ncoded as per seen in this data:\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 11 of 43\n\nThe encrypted data part can be seen in this virtual address of the unpacked ELF:\r\nThis is where the pain coming isn't it? :) Don't worry, I will explain:\r\nThe decryption flow is not changing much, however the logic for encryption is changing. It seems the mal-coders\r\ndoesn't get their weakness yet and tried fixing a wrong part of the codes to prevent our reversing. Taking this\r\nadvantage, you can use my introduced decryption dissection method explained in the previous post about Linux\r\nMirai/FBOT [link] to dissect this one too. It works for me, should work for you as well.\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 12 of 43\n\nBelow is my decryption result for encrypted configuration:\r\nThe binary will operate as per commonly known Mirai variant bots, it will listen to TCP/3467 and callback to C2\r\nat 194(.)36(.)188(.)157 on TCP/4321 for the botnet communication purpose, and as per other Mirai variants the\r\npersistence factor is in the botnet communication. There are some parts taken from Satori and Okiru for\r\nembedding downloaders to be used in victim's IoT. The unique feature is the writing for\r\n\"9xsspnvgc8aj5pi7m28p\\n\" strings upon execution. This bot client is enriched with more scanner functions (i.e.\r\nhardcoded SSDP request function to scan for plug-and-play devices that can be utilized as DDoS amplification, in\r\nMirai this attack will use spoofed IP address of the victims to launch attack).\r\nFor getting more idea of what this binary does, the strings from the unpacked binary I dumped it here in a safe\r\npastebin source file. Combine the strings that I dumped from unpacked binary with the packed one under different\r\nsub_rules, and use the hardcoded unpacking functions opcodes for your Yara rules to detect this packer, hashes\r\nand IP from this post are useful also for IOC/Yara detection. VirusTotal can help to guide you more OSINT for the\r\nsimilar ones.\r\nI think that will be all for FBOT new binary updates. So let's move on to the much more important topic..reversing\r\nthe botnet instance itself, how is the speed, spreads and how big, to understand how to stop them.\r\nThe \"worrisome\" infection speed, evasion tricks and detection ratio problem\r\n1. Infection and propagation rates of new FBOT\r\nThe new wave of infection of the new version is monitored rapidly, and the sign is not so good.\r\nSince the firstly detected until this post was started to be written (Feb 22), FBOT was having almost 600 infection\r\nIP addresses, and due to low scale network monitoring we have, we can expect that the actual value of up to triple\r\nto what we have mentioned. Based on our monitoring the FBOT has been initially spread in the weaker security of\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 13 of 43\n\nIoT infrastructure networks in the countries sorted as per below table:\r\nIn the geographical map, the spotted infection as per February 22, 2020 is shown like this:\r\nThe IP addresses that are currently active propagating Linux Mirai FBOT infection up to February 22, 2020 can\r\nbe viewed as a list in this safe pastebin link, or as full table with network information.\r\nThe IP counts is growing steadily, please check and search whether your network's IoT devices are affected and\r\ncurrently became a part of Mirai FBOT DDoS botnet. The total infection started from around +/- 590 nodes, and it\r\nis increasing rapidly to +/- 930 nodes within less than 48 hours afterwards from my point of monitoring. I will try\r\nto upgrade the data update more regularly.\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 14 of 43\n\n2. Update information on FBOT propagation speed (Feb 24, 2020)\r\nI just confirmed the infection nodes of FBOT is growing rapidly from February 22 to February 24, 2020. Within\r\nless than 48 hours the total infected nodes is raising from +/- 590 nodes to +/- 930 nodes. In the mid February 25\r\nthe total infection is 977 nodes. After the botnet growth disclosure the speed of infection has dropped from\r\naverage 100 nodes new infection to 20 devices per day, concluded the total botnet of infected IP on March 2, 2020\r\nis +/- 1,410 devices.\r\nThe speed of infection is varied in affected networks (or countries), and that is because the affected device\r\ntopology is different. I managed to record the growth of the nodes from my point of monitoring under the table\r\nshown below from top 15 infection rank, we will try the best to update this table.\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\nMirai FBOT Infection growth,\r\nFrom Feb 22 to Feb 25, 2020 JST\r\n-------------------------------------------\r\nCountry Feb22 Feb24 Feb25 Feb25\r\n(day) (night)\r\n(582) (932) (977) (1086)\r\n-------------------------------------------\r\nTaiwan 190 =\u003e 284 =\u003e 302 =\u003e 340\r\nHongKong 107 =\u003e 132 =\u003e 132 =\u003e 140\r\nVietnam 109 =\u003e 134 =\u003e 135 =\u003e 139\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 15 of 43\n\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24\r\n25\r\n26\r\n27\r\n28\r\n29\r\n30\r\nKorea 6 =\u003e 74 =\u003e 84 =\u003e 104\r\nChina 40 =\u003e 74 =\u003e 79 =\u003e 93\r\nRussia 14 =\u003e 29 =\u003e 31 =\u003e 35\r\nBrazil 19 =\u003e 27 =\u003e 28 =\u003e 30\r\nSweden 13 =\u003e 26 =\u003e 26 =\u003e 27\r\nIndia 7 =\u003e 21 =\u003e 22 =\u003e 24\r\nUSA 15 =\u003e 17 =\u003e 17 =\u003e 20\r\nUkraine 4 =\u003e 14 =\u003e 15 =\u003e 15\r\nPoland 7 =\u003e 10 =\u003e 10 =\u003e 10\r\nTurkey 0 =\u003e 4 =\u003e 6 =\u003e 9\r\nRomania 4 =\u003e 6 =\u003e 7 =\u003e 7\r\nItaly 3 =\u003e 6 =\u003e 6 =\u003e 6\r\nCanada 4 =\u003e 5 =\u003e 5 =\u003e 6\r\nNorway 3 =\u003e 5 =\u003e 5 =\u003e 6\r\nSingapore 3 =\u003e 5 =\u003e 5 =\u003e 6\r\nColombia 1 =\u003e 4 =\u003e 4 =\u003e 6\r\nFrance 2 =\u003e 4 =\u003e 5 =\u003e 5\r\n------------------------------------------\r\nAverage spread speed = +/- 100 nodes/day-as per Feb 25, 2020 - malwaremustdie, org    \r\nThe February 24, 2020 Mirai FBOT infection information update (mostly are IoT's nodes), in a list of unique IP\r\naddresses can be viewed in ==\u003e[here].\r\nFor the network information of those infected nodes can be viewed in ==\u003e[here].\r\nThe February 25 (daylight/JST), 2020 Mirai FBOT infection information update, in a list of unique IP addresses\r\ncan be viewed in ==\u003e[here].\r\nFor the network information of those infected nodes can be viewed in ==\u003e[here].\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 16 of 43\n\nThe February 25 (midnight/JST), 2020 Mirai FBOT infection information update, in a list of unique IP addresses\r\ncan be viewed in ==\u003e[here].\r\nFor the network information of those infected nodes can be viewed in ==\u003e[here].\r\nOn February 26, 2020 Mirai FBOT botnet has gained new 128 nodes of additional IOT IP, I listed those in ==\u003e\r\n[here]\r\nOn February 27, 2020 Mirai FBOT botnet has gained new 74 nodes of additional IOT IP, I listed those in ==\u003e\r\n[here]\r\nOn March 2, 2020 Mirai FBOT botnet has infected 1,410 nodes of IoT devices all over the globe. I listed those\r\nnetworks in here ==\u003e[here] for the incident handling purpose, if we breakdown the data per country it will look as\r\nper info below:\r\nIn the above data you see the \"hit cycle\" values, which is a value explaining the frequency of the botnet infected\r\nIoT in trying to infect other devices and recorded.\r\nThe latest renewed data we extracted is on March 4, 2020, where Mirai FBOT botnet has infected 1,430 nodes of\r\nIoT devices. I listed their IP addresses in here ==\u003e[link] with the network info is in here ==\u003e[link]. This is our last\r\ndirect update for the public feeds since the process is taking too much resources, and the next of data can only be\r\naccessed at IOC sites.\r\nIf you would like to know what kind of IOT devices are infected by Mirai Fbot malware, a nice howto in\r\nextracting those device information is shared by Msr. Patrice Auffret (thank you!) of ONYPHE (Internet SIEM)\r\nin his blog post ==\u003e[link].\r\nThe maximum nodes of Mirai FBOT botnet in the past was around five thousands nodes, we predicted this\r\nnumber (or more) is what the adversaries are aiming now in this newly released campaign's variant. However,\r\nafter the awareness and analysis post has been published the growth ratio of the new Fbot botnet is starting to\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 17 of 43\n\ndrop. The overall volume and growth for this new Mirai Fbot variant can be viewed as per below graph:\r\nIn order to reduce the threat from escalation process, it would be hard to block the whole scope of the infected IoT\r\nnetworks, but one suggested effective way to mitigate this threat is making efforts to clean them up first from the\r\ninfection, and then control the IoT infrastructure into always be into recent secure state along with replacing their\r\nfirmware, or even their hardware if needed. If you don't take them under your control, sooner or later the\r\nadversaries will come and they will do that in their botnet.\r\n3. About the C2 nodes\r\nThe C2 hosts, which are mostly serving the Mirai FBOT payloads and panels, are highly advisable for the\r\nblocking and further legal investigation. The C2 IP address data, their activity and network information that has\r\nbeen detected from our point is listed in a chronological activity time line as per below detail:\r\nA month ago, when I wrote about the new encryption of Mirai Fbot [link], the C2 nodes were spotted in the\r\ndifferent locations as per listed in the below table, and even now you can also still see the older version of Mirai\r\nFbot malware running on infected IoT too, that has not been updated to new variant are having traffic to these\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 18 of 43\n\nolder C2:\r\nThis information is shared for the incident and response follow up and IoT threat awareness purpose to support\r\nmitigation process at every affected sides. At this moment we saved the timestamp information privately due to\r\nlarge data, to be shared through ISP/Network CSIRT's routes.\r\n4. The detection ratio, evasion methods, IOC \u0026 what efforts we can do\r\nThe detection ratio of the packed binary of new Linux Mirai FBOT is not high, and contains misinformation.\r\nThis is caused by the usage of packer and the encryption used by the malware itself. The current detection ratio\r\nand malware names can be viewed in [this URL] or as per screenshot below:\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 19 of 43\n\nIn the non-intel architecture the detection ratio can be as bad as this one:\r\nSo, the detection ratio is not very good and it is getting lower for the newly built binaries for IoT platform. The\r\nusage of packer is successfully evading anti virus scanning perimeter. But you can actually help all of us to raise\r\ndetection ratio by sending samples for this related threat to the VirusTotal and if you see unusual samples and you\r\nwant me to analyze that, please send it to me through ==\u003e [this interface]. Including myself, there are many good\r\nfolks joining hands in investigating and marking which binaries are the Linux/Mirai FBOT ones, that will bring\r\nimprovement to the naming thus detection ratio of this variant's Linux malware.\r\nThe signature and network traffic scanning's evasion tricks of new Mirai Fbot binaries is not only by utilizing\r\n\"hexstring-push\" method, but the usage of packer, embedded loaders in packed binary \u0026 stronger encryption\r\nin config data that is actually contains some block-able HTTP request headers. By leveraging these aspects these\r\nMirai FBOT now has successfully evaded current setup perimeters and is doing a high-speed infection under our\r\nradars. This is the evasion tricks used by the adversaries that our community should concern more in the future, it\r\nwill be repeated again and maybe in a better state, since it is proven works.\r\nThe IOC for this threat contains more than 1,000 attributes and is having sensitive information, it is shared in\r\nMISP project (and also at the OTX) with the summary as per below. The threat is on-going, the threat actors are\r\nwatching, please share with OPSEC intact:\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 20 of 43\n\nIn our monitoring effort up to (March 3, 2020) the botnet IP addresses has volume about +/- 1,424. You can use\r\nthe data posted in MISP event to re-map them into your new object templates for IOT threat classification \u0026\r\ncorrelation, to follow the threat infection progress and its C2 activity better, to combine with your or other other\r\nmonitoring resources data/feeds.\r\n[UPDATE] In our latest monitoring up to (April 17, 2020) this botnet has volume about +/- 1,546 IP addresses\r\n[-1-] [-2-].\r\n[NEW] Another FBOT \"hexstring\" downloader, the \"echo\" type\r\nThere is FBOT pushed hexstring that is smaller in size. If you see the infection log there is a slight difference after\r\nhextrings pushed at \"./retrieve; ./.t telnet;\" and \"./retrieve; ./.t echo\", the token of \"telnet\" [link] and \"echo\" is\r\nthe difference, both token are coming from different built versions of FBOT scanner/spreader functions.\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 21 of 43\n\nWe have covered the \"telnet\" one in the beginning of this post [link], now let's learn together on how the \"echo\"\r\nloader's one works in this additional chapter. It is important for people who struggle to mitigate IoT new infection\r\nto understand this analysis method, in order to extract C2 information automatically from a specific offset address\r\nin the pushed binary of specific pushed \"hexstring\" types. In my case I am using a simple python script to\r\nautomatically extracting C2 data from several formats of hexstring attacks, and it works well.\r\nThe pushed binary in the \"echo\" version is smaller, it's about 1180 bytes [link] and working (and coded) in\r\nslightly different way. But how different is it? Why is it different? Where is it coming from? We need to reverse it\r\nto answer these questions. Let's start with seeing what it looks like.\r\nThe saved blob of the binary looks like this, I marked the part of where IP address of the payload server is actually\r\ncoded:\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 22 of 43\n\nNow let's start dissecting it. But beforehand, since I've been still asked questions on reversing ARM stripped\r\nbinaries, so I will make this additional chapter explanation clearer, in steps, for you. All you have to do is\r\ndownloading and using Tsurugi DFIR Linux SECCON version [link] that I use for this, then fire the pre-installed radare2 to load the binary of this example (again, it is ARM Embedded ABI arch made by ARM ltd\r\n[link], a default port in Linux Debian for ARM architecture, the blob of binary is a little endian binary in ELF\r\n[link] 32bits, hence many are calling this architecture as \"armel\"), and our reverse engineering result should be\r\nthe same :)\r\nAnother embedded Linux binary reversing guidance I wrote (in a different architecture), which is about analyzing\r\na MIPS big endian ELF, that is also talking about a different and more complex process on a new IoT malware,\r\nyou can read it on another post in here ==\u003e[link], as the next step after you get through this exercise.\r\nIf you want to practice more reversing on small size ELF sample, for the ARM architecture I have this sample\r\nwritten at this sub-section for you==\u003e[link]. And for Intel x86 architecture 32bits I have two other reversing\r\nposts that you can use to practice during corona virus isolation time, they are in here==\u003e[link1] and [link2]. Please\r\nhang in there!\r\nThe attribute (file information) of this binary, if you save it correctly, is like this:\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 23 of 43\n\n1\r\n2\r\n3\r\n4\r\n5\r\nMD5 (retrieve2) = d2cb8e7c1f93917c621f55ed24362358\r\nretrieve2.bin: ELF 32-bit LSB executable, ARM, EABI4 version 1 (SYSV),\r\nstatically linked, stripped\r\nstrings: GET /fbot.arm7 HTTP/1.0\r\n1180 Mar 14 21:50 retrieve2.bin*\r\nYou can start with going to this virtual address at 819c (it's 0x0000819c in your radare2 interface) and print the\r\ndisassembly in the function with \"pdf\" after analyzing the whole binary and the entry0 (this) function (af). In\r\norder to get you to a specific address in a binary you can use command \"s {address}\" (s means seek), in this\r\nexample type: s 0x0000819c.\r\nThis is the main operational function of the loader, but the symbol of this ELF has been \"stripped\" made function\r\nnames are not shown, so we don't know much of its operation. We can start to check how many functions are they.\r\nHere's a trick command in radare2 to check how many functions are used or called from this main operational\r\nroutine:\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 24 of 43\n\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 25 of 43\n\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24\r\n25\r\n26\r\n:\u003e af\r\n:\u003e pdsf~fcn\r\n0x000081c4 bl fcn.00008168 fcn.00008168\r\n0x000081d4 fcn.000080c0 fcn.000080c0\r\n0x000081e4 bl fcn.000080e0 fcn.000080e0\r\n0x000081f0 fcn.000080c0 fcn.000080c0\r\n0x00008200 bl fcn.00008110 fcn.00008110\r\n0x0000820c fcn.000080c0 fcn.000080c0\r\n0x00008228 bl fcn.0000813c fcn.0000813c\r\n0x00008234 fcn.000080c0 fcn.000080c0\r\n0x00008258 bl fcn.0000813c fcn.0000813c\r\n0x00008274 bl fcn.00008110 fcn.00008110\r\n0x00008280 bl fcn.000080c0 fcn.000080c0\r\n:\u003e aflt\r\n.--------------------------------------------------------------------.\r\n| addr         | size   | name           | nbbs | xref | calls | cc |\r\n)--------------------------------------------------------------------(\r\n| 0x0000829c | 264 | entry0 | 7 | 5 | 5 | 3 |\r\n| 0x000082a0 | 88 | fcn.000082a0 | 2 | 7 | 1 | 1 |\r\n| 0x00008300 | 44 | fcn.00008300 | 1 | 3 | 0 | 1 |\r\n| 0x00008168 | 44 | fcn.00008168 | 1 | 1 | 1 | 1 |\r\n| 0x000080c0 | 32 | fcn.000080c0 | 1 | 5 | 1 | 1 |\r\n| 0x000080e0 | 44 | fcn.000080e0 | 1 | 1 | 1 | 1 |\r\n| 0x00008110 | 44 | fcn.00008110 | 1 | 2 | 1 | 1 |\r\n| 0x0000813c | 44 | fcn.0000813c | 1 | 2 | 1 | 1 |\r\n`--------------------------------------------------------------------'\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 26 of 43\n\nThese are the all used functions, not so much, so please try to dissect this with static analysis only, you don't need\r\nto execute any sample, yet, please do this under virtual machine to follow below guidance to do so.\r\nNow, let's use my howto reference ==\u003e[link] to put the syscall function name and guess-able function name if any\r\ninto the places. After you figured the function, run the script below in your radare2 shell to register your chosen\r\nnaming to those virtual addresses where the functions are started:\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n:\u003e s 0x0000813c\r\n:\u003e s 0x00008110\r\n:\u003e s 0x000080e0\r\n:\u003e s 0x000080c0\r\n:\u003e s 0x00008168\r\n:\u003e s 0x000082a0\r\nSo you will find the nice table result looks like this:\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 27 of 43\n\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\n12\r\n13\r\n:\u003e aflt\r\n.--------------------------------------------------------------------.\r\n| addr         | size   | name            | nbbs | xref | calls | cc |\r\n)---------------------------------------------------------------------(\r\n| 0x0000829c | 264 | entry0 | 7 | 5 | 5 | 3 |\r\n| 0x000082a0 | 88 | svc_0 | 2 | 7 | 1 | 1 |\r\n| 0x00008300 | 44 | to_0xFFFF0FE0 | 1 | 3 | 0 | 1 |\r\n| 0x00008168 | 44 | ____sys_socket | 1 | 1 | 1 | 1 |\r\n| 0x000080c0 | 32 | ____sys_exit | 1 | 5 | 1 | 1 |\r\n| 0x000080e0 | 44 | ____sys_connect| 1 | 1 | 1 | 1 |\r\n| 0x00008110 | 44 | ____sys_write | 1 | 2 | 1 | 1 |\r\n| 0x0000813c | 44 | ____sys_read | 1 | 2 | 1 | 1 |\r\n`--------------------------------------------------------------------'\r\nIn figuring a correct system call (in short = syscall) name in this binary, you should find a number of which\r\nsyscall is actually going to be called (known as syscall_number), and for that svc_0 is the function/service to\r\ntranslate the requests to pass it (alongside with its arguments) to the designated syscall. This is why I listed the\r\nfunctions in 82a0 and 8300, which are the svc_0 and its component, and they both are used for syscall translation\r\npurpose.\r\nThe functions in addresses of: 80c0, 80e0, 8110, 813c and 8168 are the \"syscall_wrapper\" functions [link] that\r\nneeds a help from svc_0 to perform their desired system call operations (to trap to kernel mode to invoke a system\r\ncall). In our case, one of the argument in the syscall wrapper function will define a specific syscall_number\r\nwhen the wrapper functions are called from this main routine. The svc_0 is processing that passed argument to\r\npoint into a right system call function translated in the syscall table, and then to pass additional\r\nargument(s)needed for the operation of the designated syscall afterward, that's how it works in this binary.\r\nSo in the simple logic, the syscall_wrapper looks like this:\r\n1\r\n2\r\n3\r\n@ SOME_ADDRES_SYSCALL_WRAPPER\r\nint ____sys_SOME_SYSCALL( int arg)\r\n{\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 28 of 43\n\n4\r\n5\r\nreturn svc_0(SYSCALL_NUMBER, arg);\r\n}\r\nThe above code can be further applied better in every wrapper functions as per below:\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n@ 0x00080c0\r\nint ____sys_exit( int arg)\r\n{ return svc_0(1, arg); }\r\n@ 0x00080e0\r\nint ____sys_connect( int arg)\r\n{ return svc_0(283, arg); }\r\n@ 0x0008110\r\nint ____sys_write( int arg)\r\n{ return svc_0(4, arg); }\r\n@ 0x000813c\r\nint ____sys_read( int arg)\r\n{ return svc_0(3, arg); }\r\n@ 0x0008168\r\nint ____sys_socket( int arg)\r\n{ return svc_0(281, arg); }\r\nThose numbers of \"1\", \"3\", \"4\", \"281\" and \"283\" are all the syscall numbers that the designated Linux OS will\r\ntranslate them to the correct system call according to the kernel's provided syscall table in the file:\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 29 of 43\n\n1 /usr/ include /{YOUR_ARCH}/asm/unistd_{YOUR_BIT}.h\r\nI hope up to this point you can understand how to figure the syscalls used in this stripped ARM ELF binary, a little\r\nbit different than the MIPS one but the concept is the same, there is a syscall_wrapper functions, there is the\r\nsyscall translator service, the number and a table to translate them, and voila! You know what the syscall name is,\r\nand you're good to go to the next step!\r\n..just remember that we are still at virtual address 0x00008198 that's referred form entry0 with b ARM assembly\r\ncommand. Go back to the entry0 and after analysis you can print again the assembly, and under it (scroll down if\r\nyou need), you should see the renamed functions are referring to the syscall wrapper (svc_0) in the result now.\r\nAnd then you can go to address 0x0000819c again and print out the disassembly result, which is now it is showing\r\nthe function namings :) yay!\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 30 of 43\n\nFor reverser veterans maybe up to this step is enough to read how this binary works, but for beginners that is not\r\nyet familiar with non-Intel architecture maybe you will need to follow these next steps too.\r\nLet's now fire the r2Ghidra-dec (or r2dec) to disassembly the function, use the additional command option \"o\" in\r\nthe end of \"pdg\" to see the offset (You can use pdda for r2dec).\r\n(Pardon to my poorly chosen naming on variables that may confuse you, like, connect_length which is more to\r\nstring_length used for write(), etc)\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 31 of 43\n\nYou may want to know a way my reading IP address in hex fast by radare2:\r\nYou should see that your reversed function names should be appeared in the result, along with the commented part\r\non the radare2 shell console too. You can change the variable namings too if you want but first let's simplify this\r\nresult, the next paragraph will explain a further reason for that.\r\nGhidra decompiler by default will show values as variables for those that are pushed into the stacks by registers.\r\nYou should trace them well, because these bytes pushed are important values as per marked in the printed\r\ndisassembly pictures above, yes, they are arguements for the called functions, and having important meanings.\r\nAfter understanding those, at this point you can try to simplify and reform the ghidra decompiling result into a\r\nsimpler C codes. Minor syntax mistakes are okay..I do that a lot too, try to make it as simple as you can without\r\nlosing those arguments.\r\nr2dec de-compiles the ARM opcodes very well too, the pdda command's result includes the new function names\r\nand comments intact to the pseudo C generated, that can be traced to its offset. r2dec in ARM decompiling is\r\nreserving the register names as variables, referring to its assembly operation due to script parsing algorithm logic\r\nis currently designed that way.This is useful for you to elaborate which register that is actually used as argument\r\nfor what function, a bit lower level than r2ghidra, yet this will help you to learn how the ARM assembly is\r\nactually working. However in some shell terminals (like I am, using VT100 basis) maybe you can not see good\r\nsyntax highlight coloring, but you can copy them into any syntax highlight supported editor, to find it easier to\r\nread, as per following screenshot:\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 32 of 43\n\nAnother decompiler in radare2 that works fine for the case after you renamed the functions, and can give you\r\nsome hints in more simplify, in lower level syntax that is still highly influenced by the assembly code, it is called\r\nas \"pdc\".\r\nI refer to pdc when dealing with a complex binaries with many loops or branched-flow of logic, to guide me\r\ntracing a flow faster than reading only the assembly code, pdc is a very useful for that purpose since pdc can\r\nrecognize and handle cascade loops very well, I am using it a lot in reading a decoder or de-obfuscation assisting\r\nthe simple emulation operation (ESIL), or in the systems where r2ghidra or r2dec have not enough space to be\r\nbuilt. But today we are not going to discuss this de-compiler further to avoid confusion.\r\nJust for the reference, the pdc's de-compiling result is shown as per below, as a comparative purpose:\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 33 of 43\n\nIn my work desktop I reformed the simplification result of radare2's auto-pseudo-generated codes of this binary,\r\ninto this following C codes, after re-shaping it to the close-to-original one, Consider this as an example and not on\r\nthe very final C form yet, but more or less all of the argument values and logic work flow are all in there. Try to\r\ndo it yourself before seeing this last code, use what r2dec and r2ghidra gave you as reference.\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 34 of 43\n\nSo now you know about the extraction URL payload for \"echo\" loader hexstring. Don't worry If there is other\r\nslight change in way that ELF loader preserving download IP or URL data. You can always dissect it again easily\r\nby the same method, and in practical it is not necessary to reverse the whole loader binary but just aim the\r\ndownload IP and its URL (and or port number), depends on your flavor.\r\nBelow is the video tutorial for faster process and practical way to adjust the changes on download IP/URL. This\r\nconcept can be appied for FBot variants with a pushed-hexstring loaders especially the ones that are using Mirai\r\nbasis loader design. Noted that: this extraction concept is also worked to Hajime, LuaBot, and other Mirai\r\nvariants with a minor adjustments. For honeypot users, you can use this method to automate the payload URL\r\nextraction for each hexstring entries without even downloading the payload.\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 35 of 43\n\nEtt fel inträffade.\r\nDet går inte att köra JavaScript.\r\n(pause the video by pressing space or click the video screen)\r\nThe conclusion of this chapter:\r\nUnlike the \"telnet\" one, the difference on how this \"echo\" type of pushed hextring works, can be described as\r\nfollows, tagged with \"minor\" and \"major\" differences:\r\n1. (Major?) It does not confirming the architecture, frankly, that doesn't matter anyway.\r\n2. (Major) It doesn't save the read downloaded data into file, like \".t\" file that open() in \"telnet\" version, so\r\nthis \"echo\" version is just printout the download result to stdout, this explaining the piping handling, hard\r\ncoded in the FBOT spreader function is a must to save the payload into affected devices. This reduce big\r\nI/O operational steps.\r\n3. (Minor) It doesn't bother to close the connection after the writing is done, and just exit the program.\r\n4. (Minor) It isn't using IP reforming step, just using a hardcoded hexadecimal form of IP address.\r\nThis explains how the \"echo\" type is smaller in size compares to the \"telnet\" type. And in addition, the both of\r\n\"telnet\" (previously explained) and \"echo\" (now explained) pushed ELF loaders are all \"inspired\" from Mirai's\r\nOkiru and Satori ELF loaders.\r\nI hope you like this additional part too, thank you for contacting and asking questions, happy RE practise!\r\nFor the folks who have to get recovered or isolated due to corona virus pandemic, this chapter I dedicated to\r\nthem. Please try to spend your time at home in brushing your reverse engineering skill on Linux binaries with\r\npractising this example or sample.\r\nYou can download the Tsurugi DFIR Linux distro's ISO from the official side [link], or use the SECCON special\r\nedition I use [link], Tsurugi can be used in Live mode in several virtual machines (wmware, vbox, kvm) or USB\r\nbootable, or you can install it into your unused old PC. With a build effort, you can also install radare2 [link] with\r\nr2ghidra [link] and r2dec [link] from the github sites. These are all open source tools, it is free and good folks are\r\nworking hard in maintaining \u0026 improving them, please support them if you think they're useful!\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 36 of 43\n\nNew actor, old version [Update for April 24, 2020]\r\nWe have spotted the new spark of what looks like the FBOT activity, started from April 24th, 2020. as per\r\nrecorded in the following log screenshot below, this seems like the Mirai FBOT is downgraded to earlier era's\r\nversion, which I found it strange so I just need to look it further:\r\nTo make sure the payload is actually served, some testing and record to check them has been also conducted as per\r\nrecorded too in the screenshot below:\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 37 of 43\n\nThe bot binaries are all packed, but with the older ways, at this point it raises more suspicion:\r\nAfter the unpacking I found that the \"CTF like\" encryption that I was blogged in this post and previous post wasn't\r\nthere, took me like 5 minutes to decrypt this one, but I bet by now you all can do the unpacking and decrypting\r\nthis way much faster yes? After all of the exercises you took in previous chapter above. :D\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 38 of 43\n\nBack to this version's the scanner's atacker source IP as per shown in the picture above, I sorted all of the infection\r\neffort the per this list ==\u003e[link], and sort the source IP as per this list ==\u003e[link]. to then compared to what has\r\nbeen recorded so far as Mirai FBOT's scanner IP (read: IoT infected with Mirai FBOT) written in several links in\r\nprevious chapters.\r\nThe result is none of them is matched. It seems that there is another botnet is propagating infection using either\r\nthe copycat version or museum version of the FBOT with the very low quality on its core's code and just being\r\nadded with some new scanning interface.\r\nTo be more clear in the comparison betwen nea actor's FBOT and previous botnet's one. Below is the botnet\r\ngeographical map of the new actor's botnet, that's is showing an infection focus on Hongkong and China, that's is\r\ndifferent to the similar map made by infection of previous FBOT which was focusing on Taiwan, Vietnam, then to\r\nHongkong, the link is here==[link]\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 39 of 43\n\nAdditionally, on April 25, 2020, this new actor was started to launch the pushed hexstrings to infect new IoT via\r\necho command, that the video ccan be seen in here==\u003e[link]. In that case, the used IP address can be grep easily in\r\nthe hexstring itself, it's written like this: \\xa0\\xe3\\x12\\x30\\xa0\\xe3\\xce\\x10\\xa0\\xe3\\xe3\\x20 and these hexs\r\nmeans the last three digits IP address used to download the FBOT payload. You can adjust this string into a grep\r\ncommand to your honeypot or IoT log, by adding escape sequence backslash before the \"\\x\" . The latest new\r\nactor infection log I shared in the GIST link above contains the nodes that infects with this hexstrings from the\r\nsame C2.\r\nLet's go back to the binaries used of this FBOT version, if you can unpack it very well, you will see the below\r\ndetails that can support the theory.\r\nSome scanner strings used in this new actor's Mirai FBFOT version:\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 40 of 43\n\nThese are the payload binaries name:\r\nAnd this is the hardcoded Stupidly Simple DDoS Protocol(SSDP) headers used for amplification flood\r\nreflection attack:\r\nAgain, about SSDP flood in simple words: It's a flood composed by UDP packets using source port 1900. This\r\nport is used by the SSDP and is legitimately specified for UPnP protocols. In UPnP there's \"M-SEARCH frame\"\r\nas main method for device discovery using multicasting on 239.255.255.250:1900 (reserved for this purpose). The\r\nadversaries are taking advantage from three weaknesses of UPnP protocol in (1) utilizing it for amplification\r\nattack, or (2) reflection attack and while doing those it obviously can (3) spoof the source IP address. The above\r\npicture is showing that Mirai FBOT is having this flood functionality.\r\nWhat has been concluded in this additional (update) chapter is, there is more than one actor is using Mirai FBOT,\r\nthe one with the \"CTF like\" crypt function that looks like stopping its activity and abandon the botnet under the\r\nscale volume of 1,600 to 1,700 nodes, and there is a new one, using the older yet standard version, suspecting\r\ncould be a older version leaked/shared/re-used and now actively operated by another actor(s).\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 41 of 43\n\nThe IOC for this update chapter (new actor one):\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\nC2: 5[.]206[.]227[.]18 (same FBOT port number for nodes \u0026 C2)\r\nspf FQDN: darksdemon[.]gov\r\nPayloads: 5.206.227.18/bot/bot.{ARCH}\r\nTemporary filename: bot.{ARCH}.tmp\r\nPayloads:\r\nbot.arm4,5: dfa6b60d0999eb13e6e5613723250e62\r\nbot.arm7: 924d74ee8bfca43b9a74046d9c15de92\r\nbot.mips: 4b323cd2d5e68e7757b8b35e7505e8d9\r\nbot.x86: 591ca99f1c262cd86390db960705ca4a\r\nbot.x86_64: 697043785e484ef097bafa2a1e234aa0\r\nOthers payloads are not included: *.mipsel, *.superh\r\nUpdates on new actor's Mirai/FBOT:\r\nThe epilogue\r\nWe hope this post can raise attention needed to handle the worrisome of this new FBOT propagation wave in the\r\ninternet. Also we wrote this post to help beginner threat analysts, binary reversers, and incident response team,\r\nwith hoping to learn together about Linux malware in general and specifically on IoT botnet.\r\nThere is some more insight information about this threat that maybe can help you to understand the threat better,\r\nincluding a how to mitigate this, it is in this article ==\u003e[link] (thank you for the interview!). Also if you\r\nsuccessfully analyze and monitor similar threat, please don't forget to inform your CERT/CC so they can help to\r\ncoordinate the handling further to the CSIRT on every related carriers and services, and also those escalation\r\nrecords can be useful to be used during notification to the authority, for applying a better policy for IoT structure\r\nin your region.\r\nWe are in the era where Linux or IoT malware is getting into their better form with advantages, it is important to\r\nwork together with threat intelligence and knowledge sharing, to stop every new emerging activity before they\r\nbecome a big problem for all of us later on.\r\nOn behalf of the rest of our team, we thank all of the people who support our work, morally and with their\r\nfriendship. MMD understands that security information and knowledge sharing is also very important to maintain\r\nthe stability of internet to make our life easier. Thank you to all tools/framework's vendors and services who are so\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 42 of 43\n\nmany of them and who are so kind to support our research and sharing works with their environments, also, to the\r\nmedia folks who are helping us all of these yeas. I and the team will look forward to support more \"securee-tays\"\r\nfor 2020 and for more years to come.\r\nI will try to update regularly the information posted in this article, please bear with recent additional information\r\nand maybe changes, so stay tuned always.\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\nMalware Must Die!\r\nSource: https://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nhttps://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html\r\nPage 43 of 43",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blog.malwaremustdie.org/2020/02/mmd-0065-2021-linuxmirai-fbot-re.html"
	],
	"report_names": [
		"mmd-0065-2021-linuxmirai-fbot-re.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434233,
	"ts_updated_at": 1775791293,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/84bc4dab007d6281ee243aa9673996b32cc41409.pdf",
		"text": "https://archive.orkl.eu/84bc4dab007d6281ee243aa9673996b32cc41409.txt",
		"img": "https://archive.orkl.eu/84bc4dab007d6281ee243aa9673996b32cc41409.jpg"
	}
}