{ "id": "eb51b430-9353-46a7-9ebf-ff43a949545a", "created_at": "2026-04-06T00:08:35.895619Z", "updated_at": "2026-04-10T03:38:06.373853Z", "deleted_at": null, "sha1_hash": "ef694bc768601d892b1e613f6ab4cceff0ee933a", "title": "Virus Bulletin :: VB2018 paper: Tracking Mirai variants", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 2368303, "plain_text": "Virus Bulletin :: VB2018 paper: Tracking Mirai variants\nArchived: 2026-04-05 15:09:53 UTC\nYa Liu \u0026 Hui Wang\nQihoo 360 Technology, China\nCopyright © 2018 Virus Bulletin\nAbstract\nMirai, the infamous DDoS botnet family known for its great destructive power, was made open source soon after being\nfound by MalwareMustDie in August 2016, which led to a proliferation of Mirai variant botnets. Since then, the authors\nhave continuously updated their code (e.g. adding new types of exploits and attack methods), which has added to the\ndifficulty of detecting and mitigating Mirai-related threats. To solve that problem we present a set of Mirai variant\nclassification and tracking schemes developed during the process of analysing over 32,000 Mirai samples. In this paper we\nwill introduce:\n1. How to extract data including configurations, supported attack methods, and dictionaries of usernames and\npasswords from samples.\n2. How to use the extracted data to classify and track Mirai variants.\nTo demonstrate the effectiveness of our solutions, popular Mirai branches are investigated under the proposed schemes.\n1. Introduction\nMirai became well known in Autumn 2016 for overwhelming several high-profile targets including Krebs on Security, OVH\nand Dyn through DDoS attacks. Mirai overtook previous Linux DDoS botnet families (e.g. Gafgyt, Tsunami) in its capacity\nto infect hundreds of thousands of IoT devices in a short period of time, and to provide versatile attack method options. The\nMirai source code was released soon after having been found by MalwareMustDie. Inspired by the success of Mirai and the\nreleased source code, other bot masters/underground groups soon began to establish their own versions of Mirai botnets,\nwhich has caused a proliferation of IoT botnets over the past 1.5 years. While some of the new botnets only borrowed ideas\nor code from Mirai (e.g. Hajime [1], Reaper [2]), most of them are exact Mirai descendants [3, 4, 5]. In the post-Mirai era, it\nshould be routine work for security researchers to fight Mirai-like threats.\nCurrently, it is usual for Mirai variants to be classified with their branch names, which come from the command line\n‘/bin/busybox ’ found in the Mirai sample. While the default name is ‘MIRAI’, in later variants the ‘branch’ is\nusually replaced with an author-chosen name (e.g. MASUTA, SATORI, SORA, as shown in Table 1). However, we feel that\nsuch a classification scheme is too coarse-grained, and it cannot reveal the variances across variants.\nBranch name Sample count\nJOSHO 1,444\nOWARI 702\nMASUTA 438\nCult 434\nSORA 400\ndaddyl33t 343\nhttps://www.virusbulletin.com/virusbulletin/2018/12/vb2018-paper-tracking-mirai-variants/#h2-appendix-sample-sha256-hashes\nPage 1 of 25\n\nMIORI 244\r\nWICKED 128\r\ndwickedgod 125\r\nEXTENDO 100\r\nTable 1: Top 10 new Mirai branches in the past 1.5 years based on their sample count.\r\nOur Mirai tracking work started soon after the malware was first blogged about by MalwareMustDie in August 2016 [6].\r\nBetween then and May 2018, over 32,000 Mirai samples were collected, from which dozens of variants and 1,000+ C\u0026Cs\r\nhave been detected. According to our experience, automatic schemes to classify and track the proliferated variants must be\r\nable to do the following:\r\n1. Extract the C\u0026C information.\r\n2. Figure out the supported attack methods, since Mirai is mainly DDoS attack purposed.\r\n3. Provide clues for correlating variants and C\u0026Cs, and if possible, help to investigate the actors behind the attacks.\r\nIn this paper, we will introduce our Mirai variant classification and tracking schemes which mainly make use of the data\r\nrelating to configurations, supported attack methods and credential dictionaries. The remainder of this paper is organized as\r\nfollows: in Section 2, we introduce how to extract data including configurations, supported attack methods and attack\r\nmethod fingerprints automatically from samples; in Section 3, we introduce a set of schemes including variant clustering and\r\nclassification using the extracted data; in Section 4 we use our proposed schemes to investigate some typical Mirai branches.\r\nTo summarize, the contributions of this paper are as follows:\r\nWe demonstrate solutions for automatically extracting configurations, supported attack methods and credential\r\ndictionaries from Mirai samples.\r\nWe propose a fingerprint technique that can be used to recognize Mirai attack methods with the information extracted\r\nfrom binary code without the need for reverse engineering work.\r\nWe summarize the Mirai variants and introduce a set of classification schemes based on the extracted data.\r\nWe investigate popular Mirai branches with our proposed schemes.\r\nSince it’s common for Mirai botnet authors to compile the same code into binaries for different processors (e.g. x86, x64,\r\nARM, MIPS, SPARC, PowerPC), for reasons of simplicity and efficiency, we chose to consider only the subset of samples\r\nfor x86 and ARM in this paper. We believe these two kinds of samples are sufficient to study the Mirai variants due to the\r\nredundancy introduced by the ‘one-source-to-multiple-processors’ style of compilation. On the other hand, this paper mainly\r\nfocuses on Mirai variants with DDoS attack methods, and pays little attention to non-DDoS ones (e.g. Sartori.miner).\r\nThe SHA256 hashes for the samples discussed in this paper are given in Appendix A.\r\n2. Data extraction\r\nIt’s thought that malware variant classification and tracking is a classical, yet difficult problem. There is no industrial\r\nstandard on that. The de facto method is to make use of sample information including special code snippets, binary byte\r\nsequences or strings, calling function graphs, and size, etc. In this paper, we simplify the problem by limiting the used data\r\nto the following four kinds:\r\n1. Plaintext configurations, together with the encryption algorithm and key.\r\n2. The C\u0026C domain/IP and port. While originally stored in the configuration database, this information is now usually\r\nhard coded in a function named resolve_cnc_addr().\r\n3. The supported attack methods and their corresponding command codes.\r\n4. The dictionary of username/password pairs used in the scan module, if it exists.\r\nhttps://www.virusbulletin.com/virusbulletin/2018/12/vb2018-paper-tracking-mirai-variants/#h2-appendix-sample-sha256-hashes\r\nPage 2 of 25\n\nAll the data is extracted in an automated manner. Since the data is stored in a distributed manner in the samples (rather than\r\nall being in the same place), it’s difficult to extract all the required data with a single solution. Meanwhile, due to the ‘one-source-to-multiple-processors’ code compilation, solutions must be able to deal with different processor architectures. Our\r\nfinal solution is composed of four separate analyser programs, each of which includes a static and a dynamic analysis part.\r\nThe static analysis is done with IDAPython to make use of IDA’s multiple processor supporting feature, while the dynamic\r\nanalysis is based on a proprietary lightweight emulation framework which is designed to emulate binary code snippets of\r\ninterest (e.g. an instruction block). The open-source emulator Unicorn [7] is used as the core engine to support common\r\nprocessor architectures including x86/x64/ARM/MIPS/PowerPC/SPARC. Both ELF and PE formats are supported.\r\n2.1 Configurations\r\nIn Mirai, a self-defined database is designed to store most of the running parameters which we call configurations. The\r\ndatabase has the following characteristics:\r\n1. Each item is uniquely indexed with a number which is usually less than 256.\r\n2. Configurations are encrypted.\r\n3. Configuration is referenced in a pattern of ‘decrypt-\u003eretrieve-\u003ere-encrypt’.\r\nA completely extracted configuration database can be seen in Figure 1.\r\nFigure 1: A successfully extracted configuration database (md5 = 0ae272306d313c6abf1433b85e0a2352).\r\nThe first line holds the summary information, while the left lines correspond to individual configuration items. In this\r\nexample the C\u0026C port has an index number of 1, as indicated by ‘idx_port=1’ in the first line, which points to the item\r\n‘[0x01]: “\\x059”, size=2’. The C\u0026C port of 0x539 (a.k.a. 1337) is calculated from the item content of ‘\\x059’.\r\nBasically, configuration extraction can be divided into two steps: (1) extracting the indexes and cipher texts of all items; (2)\r\ndeciphering them with a self-implemented decryption program. Our analysis of the source shows that the database is\r\ninitialized in a function called table_init(), as shown in Figure 2.\r\nhttps://www.virusbulletin.com/virusbulletin/2018/12/vb2018-paper-tracking-mirai-variants/#h2-appendix-sample-sha256-hashes\r\nPage 3 of 25\n\nFigure 2: The table_init() function in source.\r\nIn table_init(), it’s the function named ‘add_entry()’ that is called repeatedly to install the individual items. In each call to\r\nadd_entry(), three parameters are passed which individually represent: item index, ciphertext address, and size. A new\r\nmemory block will be allocated inside add_entry() to store the cipher text, then it will be saved to a slot allocated from a\r\nglobal structure named ‘table’. The slot position is determined with the following formula:\r\nitem_addr=table_addr +item_id*tbl_item_size\r\nUnder 32-bit CPU architecture, the tbl_item_size always holds a value of 8, while its value is 16 for 64-bit CPU\r\narchitectures.\r\nIn the original versions, both the C\u0026C domain/IP and port are stored in the configuration database, which makes it possible\r\nto recover all necessary information simply by analysing the table_init() function. However, in later variants, C\u0026C\r\ndomains/IPs are usually hard coded in a function called\r\nresolve_cnc_addr(), as shown in Figure 1. Furthermore, due to compiler inline optimization and the fact that the first item is\r\nnot always indexed from a fixed number (e.g. 0), configuration indexing information is missing in table_init().\r\nFortunately, since both C\u0026C and port are referenced in resolve_cnc_addr(), the missing indexing information, together with\r\nthe hard-coded C\u0026C, can be calculated heuristically with the analysis of resolve_cnc_addr(). Therefore our configuration\r\nextraction solution comes as two analyser programs: one for table_init() and the other for resolve_cnc_addr().\r\n2.1.1 table_init() analyser\r\nThe table_init() function is called after the bot starts running. As shown in Figure 2, the item installation work is done by\r\nrepeatedly calling add_entry(). In the case of inline optimization, calls to add_entry() are optimized into those of\r\nmalloc()/util_memcpy().\r\nThe ‘decrypt-\u003eretrieve-\u003ere-encrypt’ style of item reference is done separately with the\r\ntable_unlock_val()/table_retrieve_val()/table_lock_val() functions, with decryption/encryption implemented in\r\ntable_unlock_val()/table_lock_val(). The encryption algorithm is summarized as follows:\r\n1. Decryption and encryption share the same single-byte XOR’ing algorithm.\r\n2. Key size is 4. The target byte is XOR’ed with each key byte in turn to get the final ciphertext/plaintext byte.\r\nGiven the associative law of XOR operation, the four-byte key can equivalently be mapped to a one-byte key, which greatly\r\nreduces the key space from 2^32 to 2^8, thus making it feasible to search the key with brute force enumeration.\r\nCandidate table_init() functions are found by the static analysis script which goes through all binary functions in samples\r\nand picks out those with the following characteristics:\r\nRepeatedly calling add_entry() or malloc()/util_memcpy() in the case of inline optimization.\r\nComposed of one very large instruction block because no branches are introduced by any switch/loop instructions.\r\nReferencing dozens of global variables which point to ciphertext memory.\r\nhttps://www.virusbulletin.com/virusbulletin/2018/12/vb2018-paper-tracking-mirai-variants/#h2-appendix-sample-sha256-hashes\r\nPage 4 of 25\n\nDynamic analysis of the candidate table_init() functions, together with false-positive removals, is done in an emulation\r\nprogram based on our lightweight emulation framework. The cases of non-inline and inline optimization are considered\r\nseparately. The key points of emulating a non-inline version of table_init() are as follows:\r\nNOP’ing all the CALL instructions and marking them as breakpoints.\r\nEmulating in single-step mode.\r\nIn the breakpoint handler, saving arguments 1–3 separately as id, ciphertext address, and size if argument 2 points to\r\na valid data area.\r\nWhen dynamically analysing the inline optimized code, a trick is used which is inspired by the fact that the return value of\r\nmalloc() would be used as the first argument of the next call (a.k.a. util_memcpy()). Every time a CALL breakpoint is\r\nhandled, the return value (e.g. EAX in the case of Intel x86 CPU) will be set to a magic value called MAGIC-RET. By doing\r\nthat, a call with the first argument equal to MAGIC-RET would be indicative of util_memcpy, thus triggering the saving of\r\narguments 2 and 3. Similarly, the operation of saving an item to the table can also be traced by checking whether the\r\ncurrently inspected MEM-WRITE operation has a source operand of MAGIC-RET. If it does, the slot address will be saved\r\nfor late index calculation with the following formula:\r\nitem_id=(item_addr-table_addr)/tbl_item_size\r\nThe table_addr is inferred heuristically from the analysis of resolve_cnc_addr() introduced in Section 2.1.2.\r\nThe key points of emulating an inline optimized table_init() are as follows:\r\n1. NOP’ing all the CALL instructions and marking them as breakpoints.\r\n2. Hooking all MEM-WRITE instructions.\r\n3. Emulating in single-step mode.\r\n4. In the CALL breakpoint handler, saving arguments 2 and 3 as ciphertext address and size if the first argument is\r\nMAGIC-RET, and setting the return value as MAGIC‑RET.\r\n5. In the MEM-WRITE handler, saving the destination memory address as item_addr if the source operand is MAGIC-RET.\r\nAfter emulation finishes, the ciphertext configurations are read for decryption. Every key in 2^8 is tested until any\r\nmeaningful plain configurations are found. The decrypted configurations will be cached for later synthesizing after\r\nresolve_cnc_addr() is analysed.\r\n2.1.2 resolve_cnc_addr() analyser\r\nThe resolve_cnc_addr() function, called in a SIGTRAP signal handler installed in main(), was originally responsible for\r\nretrieving the C\u0026C and port from the configuration database with their index numbers. However, more and more Mirai\r\nvariants have begun to hard code their C\u0026Cs in resolve_cnc_addr(), as illustrated in Figure 3, which mandates the analysis\r\nof resolve_cnc_addr() to retrieve the right C\u0026C value and port index number. The result will be used for inference of\r\nconfiguration indexing, as mentioned above.\r\nhttps://www.virusbulletin.com/virusbulletin/2018/12/vb2018-paper-tracking-mirai-variants/#h2-appendix-sample-sha256-hashes\r\nPage 5 of 25\n\nFigure 3: C\u0026C hard coded in\r\nresolve_cnc_addr() (md5 = 333d98e27cc885624f073e59fc40dfed).\r\nThe resolve_cnc_addr() function has the following characteristics:\r\n1. It writes at least two global variables (srv_addr.sin_addr and srv_addr.sin_port).\r\n2. It calls at least three different functions.\r\nCandidate resolve_cnc_addr() functions are found with an IDAPython script in the following ways:\r\n1. Heuristically finding the main() function.\r\n2. Finding all callback functions in main() as candidate signal handlers.\r\n3. Finding callback functions in each candidate signal handler found in (2) as candidate resolve_cnc_addr() functions.\r\n4. Filtering out those that don’t have reserve_cnc_addr() characteristics.\r\n5. Extracting the hard-coded C\u0026C if it exists.\r\nThe key steps of emulating resolve_cnc_addr() are as follows:\r\n1. NOP’ing all the CALL instructions and marking them as breakpoints.\r\n2. Hooking all MEM-WRITE instructions.\r\n3. Emulating in single-step mode.\r\n4. In the CALL breakpoint handler, saving a pair of {arg1, ‘CALL’} to an operation list OPS, and setting the return\r\nvalue (e.g. EAX in the case of Intel x86) as a magic value MAGIC-RET.\r\n5. In the MEM-WRITE handler, saving a pair of {write-bytes, ‘WRITE’} to OPS.\r\nAfter emulation stops, the C\u0026C (if not hard coded) and port index numbers are calculated in the following manner:\r\n1. The OPS list is iterated and the unique arg1 values saved in {arg1, ‘CALL’} pairs are counted until a {write-byes,\r\n‘WRITE’} pair is encountered.\r\n2. The most frequent arg1 value can be thought of as an index number. If write-bytes in {write-byes, ‘WRITE’} is equal\r\nto 4, the obtained number will be used as the C\u0026C index; if write-bytes is equal to 2, it is used as the C\u0026C port\r\nhttps://www.virusbulletin.com/virusbulletin/2018/12/vb2018-paper-tracking-mirai-variants/#h2-appendix-sample-sha256-hashes\r\nPage 6 of 25\n\nindex.\r\n3. The counting results are cleared for the next round of counting.\r\n4. Steps 1 to 3 are repeated until OPS is iterated over.\r\nThe indexes that are found are used for C\u0026C retrieval and for inferring the indexing number in the case of inline optimized\r\ntable_init(). The heuristic inference is based on the facts that: (1) although not fixed, the smallest index number must be\r\ngreater than 0 while usually less than 5; (2) the C\u0026C port item always has a size of 2. The detailed process is illustrated as\r\nfollows:\r\n1. Getting the first item’s address by sorting the values of item_addr obtained in Section 2.1.1, and taking it as\r\nfirst_item_addr.\r\n2. Assuming the value of first_item_index is 1.\r\n3. Calculating the table address with the formula: table_addr (=first_item_addr- first_item_index*item_size).\r\n4. Calculating all other item indexes based on the table_addr obtained in step 3 and the item_addr obtained in Section\r\n2.1.1.\r\n5. Retrieving the C\u0026C and port with indexes obtained from resolve_cnc_addr(). If the retrieved values make sense, the\r\nprocess stops here.\r\n6. Increasing the first_item_index by 1, and going back to step 3 if the first_item_index is less than 5. Otherwise the\r\nprocess stops.\r\nAn example result has been shown in Figure 1, where the C\u0026C and all index numbers have been inferred with the\r\ndemonstrated algorithm.\r\n2.2 Supported attack methods\r\nIt’s known that Mirai is designed for DDoS attacking purposes. Ten supported attack methods are found in the released\r\nMirai source [8]. Accordingly, ten command codes (e.g. ATK_VEC_xx in Figure 4) are defined in the C\u0026C protocol to\r\ndeliver attack method types in commands from the controller to bots.\r\nFigure 4: Ten attack methods found in the released source.\r\nOur analysis shows that the attack methods usually differ in variants in terms of method count, command code numbering,\r\nnew types of methods, and method implementation. From the point of view of supported attack methods, Mirai variants\r\ncould be clustered with combinations of ‘code‑attack_typen’, where n is the version number of a specific attack method. For\r\nexample, the original version of Mirai could be represented as:\r\n{0-atk_udp1, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn1, 4-atk_tcp_ack1, 5-atk_tcp_stomp_or_xmas1, 6-atk_gr\r\nMeanwhile, the version of the sample illustrated in Figure 1 (md5=0ae272306d313c6abf1433b85e0a2352) has the following\r\nrepresentation:\r\nhttps://www.virusbulletin.com/virusbulletin/2018/12/vb2018-paper-tracking-mirai-variants/#h2-appendix-sample-sha256-hashes\r\nPage 7 of 25\n\n{0-atk_udp1, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn1, 4-atk_tcp_ack1, 5-atk_tcp_stomp_or_xmas1, 6-atk_gr\r\nThe obvious difference is that command code 10 has different semantics in the two scenarios.\r\nTo achieve the combination of ‘code-attack_typen’ from a binary sample, we must: (1) extract the attack method codes and\r\ntheir function addresses from the sample; (2) figure out what attack types each function is used for. Accordingly, two\r\nanalyser programs are designed: one program is to extract {code, attack_function} sequences, while the other is to figure out\r\nthe extracted attack semantics, as will be introduced in Section 2.2.1.\r\nAs shown in Figure 4, Mirai attack methods, together with their command codes, are dynamically installed in a function\r\ncalled ‘attack_init()’. It’s the function named add_attack() that is repeatedly called in attack_init() to save the pairs of {code,\r\nattack_function} to a global structure named ‘methods’. Inside the add_attack() function, calloc() is called to allocate\r\nmemory for the item of {code, attack_function}, and realloc() is called to enlarge the methods by 1 to save the newly\r\nallocated item, as shown in Figure 5.\r\nFigure 5: add_attack() function in the released source.\r\nSimilar to add_entry() introduced in Section 2.1.1, the add_attack() function may also be inline optimized in some cases,\r\nwhich leads to two versions of binary add_attack(). Fortunately, the two versions share the following characteristics:\r\n1. Composed of a single block.\r\n2. A fixed set of one, or two in the case of inline-optimization, unique functions are called repeatedly.\r\n3. At least one callback function corresponding to the attack method function exists.\r\nThe candidate attack_init() functions are found by an IDAPython script according to the above three characteristics. Non-inline and inline versions are considered separately when emulating. The key points of emulating non-inline versions of\r\nattack_init() are as follows:\r\n1. NOP’ing all CALL instructions and marking them as breakpoints.\r\n2. Emulating in single-step mode.\r\n3. In the breakpoint handler, saving arguments 1–2 if the second argument points to a valid code area.\r\nWhen analysing the inline optimization version of code, a trick is used which is inspired by the fact that the newly allocated\r\nmemory returned from malloc() will be used as the destination operand in the next MEM-WRITE operation to save the code\r\nand atk_function. Every time a CALL breakpoint is handled, the return value (e.g. EAX in the case of Intel x86 CPU) will\r\nbe set to a magic value called MAGIC-RET. The key points of emulating an inline optimization version of attack_init() are\r\nas follows:\r\n1. NOP’ing all CALL instructions and marking them as breakpoints.\r\n2. Hooking MEM-WRITE instructions.\r\n3. Emulating in single-step mode.\r\n4. In the CALL breakpoint handler, setting the return value as MAGIC-RET.\r\nhttps://www.virusbulletin.com/virusbulletin/2018/12/vb2018-paper-tracking-mirai-variants/#h2-appendix-sample-sha256-hashes\r\nPage 8 of 25\n\n5. In the MEM-WRITE handler, saving the source operand value as atk_code if the destination operand equals\r\nMAGIC_RET.\r\n6. In the MEM-WRITE handler, saving the source operand as atk_function if the destination one equals\r\n(MAGIC_RET+4).\r\nAn example of the finally found {code, attack_function} pairs is as follows (md5 = 0ae272306d313c6abf1433b85e0a2352):\r\n{0_0x8FA0, 1_0xA4C4, 2_0xA988, 8_0x89D8, 3_0xC96C, 4_0xC1F8, 5_0xB998, 10_0xB138, 6_0x9DA8, 7_0x962C, 9_0x8CBC\r\nThe semantics of the found attack functions are inferred using the fingerprint technique introduced in the next section.\r\n2.2.1 Fingerprinting attack functions\r\nTogether with the attack method command codes, as many as 25 attack options (e.g. ATK_OPT_PAYLOAD_SIZE,\r\nATK_OPT_PAYLOAD_RAND, ATK_OPT_IP_TOS) are defined in the original Mirai C\u0026C protocol to deliver command\r\ndetails, as shown in Figure 6.\r\nFigure 6: Attack options defined in Mirai C\u0026C protocol.\r\nDetailed analysis shows it’s common for the same functionality to be expressed using different codes across different\r\nvariants. And some options are usually attack-command-specific, e.g. ATK_OPT_METHOD and ATK_OPT_POST_DATA\r\nare only used with ATK_VEC_HTTP (a.k.a. attack_app_http, as shown in Figure 7), while ATK_OPT_GRE_CONSTIP is\r\nonly used with ATK_VEC_GREIP (a.k.a. attack_gre_ip, as shown in Figure 8) and ATK_VEC_GREETH.\r\nFigure 7: Attack options used in attack_app_http().\r\nhttps://www.virusbulletin.com/virusbulletin/2018/12/vb2018-paper-tracking-mirai-variants/#h2-appendix-sample-sha256-hashes\r\nPage 9 of 25\n\nFigure 8: Attack options used in attack_gre_ip().\r\nFurthermore, different attack methods usually don’t share the same set of attack options, which inspired us to devise a\r\nfingerprint technique as follows:\r\nfingerprint(atk_function)={concatenation of used option codes}\r\nFor example, the attack_app_http in Figure 6 has a fingerprint of ‘0x15_0x14_0x08_0x16_0x18_0x07’, while attack_gre_ip\r\nin Figure 7 has a fingerprint of ‘0x02_0x03_0x04_0x05_0x06_0x07_0x00_0x01_0x13_0x19’.\r\nWith the fingerprint technique, not only can we cluster the variants based on their attack method fingerprints, but we are also\r\nable to recognize the supported attack methods of new samples with a signature database of {atk_fingerprint,\r\nmethod_name}. The used option codes are all the data that is needed for fingerprinting. They are always referenced in the\r\nfirst, yet large, instruction block of binary attack functions, as shown in Figure 9, by calling the parser functions of\r\nattack_get_opt_int()/attack_get_opt_str()/attack_get_opt_ip().\r\nhttps://www.virusbulletin.com/virusbulletin/2018/12/vb2018-paper-tracking-mirai-variants/#h2-appendix-sample-sha256-hashes\r\nPage 10 of 25\n\nFigure 9:\r\nAttack options used in attack_gre_ip().\r\nDetailed analysis shows that all parser functions share the same characteristics: taking four arguments with arguments 1–2 as\r\nsource data, arg 3 as option code and arg 4 holding a default value. Inspired by the findings, our option code extraction is\r\nachieved by emulating the first instruction block of the attack function. The static analysis part is relatively simple: splitting\r\nthe target attack function into blocks and finding the starting and ending addresses of the first block. A trick to recognize the\r\n‘attack_get_opt_’ prefixed parser functions in emulation is to set the first and second arguments of the target attack function\r\nas two magic values (e.g. MAGIC-VAL1 and MAGIC-VAL2) before emulation starts. The key points of emulation are as\r\nfollows:\r\n1. Setting arguments 1 and 2 of the target function as two magic values (e.g. MAGIC-VAL1 and MAGIC-VAL2).\r\n2. NOP’ing all the CALL instructions and marking them as breakpoints.\r\n3. Emulating in single-step mode.\r\nhttps://www.virusbulletin.com/virusbulletin/2018/12/vb2018-paper-tracking-mirai-variants/#h2-appendix-sample-sha256-hashes\r\nPage 11 of 25\n\n4. Saving arguments 3–4 when breakpoints are encountered with arguments 1–2 equal to MAGIC-VAL1–2.\r\nCurrently, 43 unique attack method fingerprints have been found from the 32,000+ samples, as illustrated in Appendix B.\r\n2.3 Dictionary of usernames/passwords\r\nIt’s the scanner module that enables Mirai to infect hundreds of thousands of vulnerable devices in a relatively short period\r\nof time. That module can be divided into two parts: (1) the TCP port prober; (2) a telnet brute force attacker with a\r\ndictionary of dozens of, default to 62, usernames/passwords. Due to its proven efficiency, the prober is not only retained by\r\nmost Mirai descendants, but also borrowed by other botnet families [9]. Meanwhile, telnet brute forcing is also kept by most\r\nvariants, sometimes used together with new exploits [3, 5], which makes it common to find a credential dictionary in Mirai\r\nvariant samples. Our analysis shows that different variants don’t usually share the same set of credentials, as shown in\r\nFigure 10. Since new usernames and passwords often indicate new infection vectors, the dictionary changes can be used for\r\nvariant detection and tracking [10].\r\nFigure 10: Two examples of extracted usernames and passwords (md5_1: dbba02b2d0ef42d2a1ebbab7f03f37f0; md5_2:\r\n2ff2d4feff4ffcec355f52993ce7b73e).\r\nIn Mirai, the scanning task, including the credential dictionary initialization, is done in a function called scanner_init(),\r\nwhich is characterized by having a complex binary control flow graph embedded with a very large instruction block, as\r\nillustrated in Figure 11.\r\nFigure 11: Binary version of scanner_init().\r\nhttps://www.virusbulletin.com/virusbulletin/2018/12/vb2018-paper-tracking-mirai-variants/#h2-appendix-sample-sha256-hashes\r\nPage 12 of 25\n\nDetailed analysis shows it’s the large block that is responsible for installing all the usernames and passwords, which inspires\r\nthe idea of extracting the credentials by emulating the large block. Candidate blocks are found using an IDAPython script\r\nthat iterates all binary blocks and picks out those with the following criteria:\r\n1. Having large block size and instruction count.\r\n2. Referencing dozens of global variables which point to ciphertext usernames and passwords.\r\n3. Writing at least five global variables which correspond to IP and TCP fields.\r\n4. Repeatedly calling a unique function (a.k.a. add_auth_entry()).\r\nThe found blocks are emulated based on our lightweight emulation framework. The key points of the emulation program are\r\nas follows:\r\n1. NOP’ing all the CALL instructions and marking them as breakpoints.\r\n2. Emulating in single-step mode.\r\n3. In the CALL breakpoint handler, saving arguments 1–3 separately as username, password and weight.\r\nThe finally extracted usernames and passwords are deciphered with a self-implemented decryption module similar to that\r\nintroduced in Section 2.1.1. Two examples of the extracted usernames and passwords are illustrated in Figure 10.\r\n3. Variant classification and tracking\r\nWhile variant classification and tracking is a complex topic, especially in the case of dozens of variants and tens of\r\nthousands of samples, in this section we will discuss such schemes with data limited to those introduced in Section 2.\r\n3.1 Configuration-based schemes\r\nSince the configuration database stores most of the running parameters, the variant evolution can be well detected from\r\ndatabase changes. For example, the samples illustrated in Figures 12 and 13 share the same C\u0026C and similar configurations,\r\nbut extra iptables commands are found in the second one, which indicates an exclusive infection and possible infection\r\nvectors.\r\nFigure 12: Configurations from a sample with md5 = dbba02b2d0ef42d2a1ebbab7f03f37f0.\r\nhttps://www.virusbulletin.com/virusbulletin/2018/12/vb2018-paper-tracking-mirai-variants/#h2-appendix-sample-sha256-hashes\r\nPage 13 of 25\n\nFigure 13: Configurations from a sample with md5 = 08abb658c6a293886a8000a31b900e88.\r\nConsidering that there are usually dozens of items in a single configuration database, and configurations vary greatly across\r\nvariants in terms of size and content, it might be not feasible to use all configurations for classification and tracking.\r\nTherefore, we devise two schemes which rely only on configuration size, count, and encryption key used.\r\n3.1.1 Clustering based on configuration count and size\r\nThis scheme is designed to cluster variants and quickly detect anomalous ones in cases where there are a large number of\r\nsamples. This is achieved by plotting all the samples according to their configurations’ counts and sizes, as shown in Figure\r\n14 where the x-axis represents size while the y-axis shows the count.\r\nFigure 14: Clustering samples based on configuration count and size.\r\nTwo clusters of samples with much larger configuration size can easily be identified in Figure 14. Further analysis shows\r\nthey can be classified as the same variant, as shown in Table 2. Detailed analysis shows the extraordinarily large\r\nconfiguration size is due to dozens of fake HTTP user-agents added by the author for better HTTP flooding attacks. In fact,\r\nthe correlated intelligence of branch names, keys and C\u0026Cs strongly suggests that the same underground group is behind the\r\nsamples.\r\nhttps://www.virusbulletin.com/virusbulletin/2018/12/vb2018-paper-tracking-mirai-variants/#h2-appendix-sample-sha256-hashes\r\nPage 14 of 25\n\nCriterion Branch name Key C\u0026C Samples\r\nsize \u003e 7400\r\n\u0026\u0026 count \u003e 100\r\n\u0026\u0026 count \u003c 120   \r\nMIRAI 0x22 cnc.ttoww.com 19\r\nKYUBI 0x34 cnc.aandy.xyz 4\r\nMIRAI 0x34 cnc.aandy.xyz 8\r\nMIRAI 0x34 www.aandy.cf 7\r\nMIRAI 0x34 www.askjasghasg.ru 16\r\nTable 2: A cluster with very large configuration size.\r\nThis clustering scheme can also be used with other schemes. For example, it can be used to cluster samples belonging to the\r\nsame branch (e.g. MASUTA, OWARI). Clustering results based on size and count can be useful for further analysis.\r\n3.1.2 Clustering based on encryption key\r\nExcept for SATORI, which is not discussed in this paper [5], all the Mirai samples we collected share the same encryption\r\nalgorithm, thus only the encryption key is considered in this paper. Since the key has a space of 2^8, there is a low\r\nprobability that two variants share the same key coincidentally. Therefore key sharing can be thought of as being caused by\r\ncode sharing, and can be used to correlate the botnet authors behind the samples.\r\nIn total, 31 keys have been detected from our collected samples. Their usage stats show a good long tail distribution of\r\nsamples, as illustrated in Table 3.\r\nKey Sample count\r\n0x22 4,755\r\n0x54 3,938\r\n0x3D 553\r\n0x45 542\r\n0x66 204\r\n0x37 163\r\n0x6F 125\r\n0x02 90\r\n0x62 77\r\n0x67 69\r\n0x55 52\r\n0x78 37\r\n0x34 35\r\n0x03 29\r\n0x56 20\r\n0x10 14\r\nhttps://www.virusbulletin.com/virusbulletin/2018/12/vb2018-paper-tracking-mirai-variants/#h2-appendix-sample-sha256-hashes\r\nPage 15 of 25\n\n0x11 13\r\n0x76 8\r\n0x42 8\r\nTable 3: Top 20 frequently used keys.\r\nAccording to our analysis, the keys located in the tail area usually indicate a single variant, while frequently used keys\r\nindicate a relative in the same family. For example, through the key of 0x54, the branches of Cult, JOSHO and OWARI can\r\nbe connected, as shown in Table 4.\r\nMD5 Config count Config size Branch C\u0026C\r\n0729b89281c831fc035d56fbf14631da 30 333 Cult 198.134.120.150\r\n23a98fc659982da993e7825eb87bb640 30 340 OWARI 198.134.120.150\r\n2ff2d4feff4ffcec355f52993ce7b73e 30 346 JOSHO 198.134.120.150\r\nTable 4: Connecting Cult, JOSHO and OWARI through the key of 0x54.\r\nThe connecting process works as follows:\r\n1. The three branches are connected by the samples sharing the same key.\r\n2. The grouped samples have a similar configuration count and size, which indicates that they probably belong to the\r\nsame variant.\r\n3. The samples share the same C\u0026C, which strongly suggests that they probably come from the same author(s).\r\nOur analysis shows that such connections can be extended to other branches, with most of them finally verified by the\r\nshared C\u0026Cs. Based on that finding, we devise a coarse-grained grouping scheme of ‘branch+key’ for quickly classifying\r\nnew samples. In total, 92 groups are produced. With the exception of ‘MIRAI_0x22’, which stands for the default branches,\r\nthe other top 10 groups based on their C\u0026Cs are shown in Table 5.\r\nVariant C\u0026C count\r\nJOSHO+0x54 216\r\nOWARI+0x54 134\r\nCult+0x54 81\r\nSORA+0x54 69\r\ndaddyl33t+0x3D 59\r\nMASUTA+0x45 53\r\nEXTENDO+0x54 21\r\nMIORI+0x54 12\r\ndwickedgod+0x3D 10\r\nSaikin+0x66 9\r\nKatrina+0x67 9\r\nTable 5: Top 10 groups of ‘branch+key’ based on C\u0026C count.\r\nhttps://www.virusbulletin.com/virusbulletin/2018/12/vb2018-paper-tracking-mirai-variants/#h2-appendix-sample-sha256-hashes\r\nPage 16 of 25\n\n3.2 Attack-method-based schemes\r\nSince Mirai was designed to launch DDoS attacks, the supported attack methods are a sound basis for variant classification.\r\nBased on the attack method fingerprinting technique introduced in Section 2.2, we develop a classification scheme based on\r\nthe combination of {code, attack-type} pairs extracted from samples, as illustrated in Section 3.2.1.\r\n3.2.1 Combination of supported attack methods\r\nAccording to our analysis, Mirai variants vary greatly in the supported attack methods in terms of method count, code\r\nnumbering, and implementation. To quickly distinguish different variants of samples, we devise a coarse-grained\r\nclassification method based on the combination of supported attack method codes (e.g. 0_1_2_3_4_5_6_7_9_10 for default\r\nMirai samples). Two samples are classified as possibly the same variant for further analysis only when they share the same\r\ncode combination. The top 10 combinations based on the sample count are shown in Table 6.\r\nAttack method code combination Count\r\n0_1_2_3_4_5_6_7_9_10 4,488\r\n0_1_2_3_4_5_6_7_8_9_10 3,890\r\n0_1_2_3_4_5_6_7_8 976\r\n0_1_2_3_4_5_6_7_8_9 353\r\n0_1_2_3_6_7_8 138\r\n0_1_2_3_4_5_6_7_9 96\r\n0_1_2_3_4 94\r\n0_1_2_3 75\r\n0_1_2_3_4_5_6_7_9_10_11_12 51\r\n0_1_2 48\r\nTable 6: Top 10 attack method code combinations.\r\nSince it’s common for the same code to be assigned to different attack methods in different variants, a more precise\r\nclassification can be achieved using the combination of code and the corresponding attack method fingerprint. With the help\r\nof the fingerprint technique introduced in Section 2.2.1, a total of 126 such unique combinations are found, as shown in\r\nAppendix C, where each combination can be thought to represent a variant. It’s worth mentioning that the fingerprints have\r\nbeen converted to the method name for better readability with the signature database we built, as shown in Appendix B.\r\n4. Typical variants analysis\r\nTo better demonstrate our proposed schemes, in this section we will investigate some popular Mirai variants with the\r\nproposed schemes.\r\n4.1 MASUTA\r\nIn total, four keys are found to be used in this branch. Their stats are shown Table 7.\r\nVariant Samples C\u0026Cs\r\nMASUTA+0x45 351 53\r\nMASUTA+0x02 90 5\r\nhttps://www.virusbulletin.com/virusbulletin/2018/12/vb2018-paper-tracking-mirai-variants/#h2-appendix-sample-sha256-hashes\r\nPage 17 of 25\n\nMASUTA+0x22 9 1\r\nMASUTA+0x55 8 1\r\nTable 7: Stats on MASUTA samples and C\u0026Cs.\r\nSample clustering on the largest branch of ‘MASUTA+0x45’ is shown in Figure 15.\r\nFigure 15: Clustering samples of ‘MASUTA+0x45’ based on configuration.\r\nBoth configuration size and count are relatively close. The slight changes in sizes are due to the following reasons:\r\n1. Two different prompt lines are used: ‘gosh that chinese family at the other table sure ate alot’ and ‘The Void’.\r\n2. In some samples the C\u0026Cs are hard coded in resolve_cnc_addr() but old default C\u0026Cs are still kept in\r\nconfigurations.\r\n3. Items of ‘Oaf3’, ‘AbAd’, ‘14Fa’ and ‘WsGA4@F6F’ are added in some samples.\r\nFrom the point of view of attack methods, as many as 25 combinations of {code, atk_type} are found in all MASUTA\r\nsamples, while there are eight combinations in the ‘MASUTA+0x45’ branch, as shown in Figure 16.\r\nFigure 16: Combinations attack methods found 'MASUTA+0x45' samples.\r\nThe UNK1 in Figure 16 represents a yet unrecognized fingerprint of\r\n‘0x02_0x03_0x04_0x05_0x07_0x0a_0x0b_0x0c_0x0d_0x0e_0x0f_0x00_0x01_0x06’.\r\n4.2 OWARI\r\nIn total, two keys are found to be used in OWARI samples. Their stats are shown in Table 8.\r\nVariant Samples C\u0026Cs\r\nOWARI+0x54 687 146\r\nOWARI+0x66 15 2\r\nTable 8: Stats on OWARI samples and C\u0026Cs.\r\nhttps://www.virusbulletin.com/virusbulletin/2018/12/vb2018-paper-tracking-mirai-variants/#h2-appendix-sample-sha256-hashes\r\nPage 18 of 25\n\nSample clustering of OWARI samples is shown in Figure 17.\r\nFigure 17: Clustering OWARI samples based on configuration.\r\nIt’s interesting that OWARI samples concentrate exactly on four points of (21, 265), (30, 340), (38, 409) and (41, 2524). The\r\nslight changes in size are due to the following reasons:\r\n1. Two different prompt lines are used: ‘OWARI09123id9i123xd912’ and ‘Follow twitter.com/1337Wicked’.\r\n2. In the samples with a size of 2524, several automatic download and killer command lines exist, as shown in Figure\r\n18.\r\nFigure 18: Command lines found in OWARI samples with size of 2524.\r\nIt’s interesting that as many as 12 unique C\u0026Cs are detected from samples with a size of 2424, while they all share the same\r\ndownload server of 185.246.152.173. We think that either they belong to the same group, or the download commands are\r\nbackdoored by the author (a.k.a. the so-called ‘twitter.com/1337Wicked’) in his code.\r\nFrom the point of view of attack methods, only two combinations of {code, atk_type} are found in all OWARI samples:\r\n15 {0-atk_udp1, 1-atk_udp_vse1, 2-atk_tcp_syn1, 3-atk_tcp_ack1, 4-atk_gre1, 5-atk_gre1, 6-atk_std_or_udp, 7-at\r\n642 {0-atk_udp1, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn1, 4-atk_tcp_ack1, 5-atk_tcp_stomp_or_xmas1, 6-at\r\nDetailed analysis shows the first combination corresponds to the branch of ‘OWARI+0x66’, while the second to ‘OWARI+\r\n0x54’.\r\nIt’s worth mentioning that, with the key of 0x66 and the first attack method combination, we successfully connected the\r\n‘OWARI+0x66’ to another branch named ‘kkuuaassaa’, where all 44 samples share the same C\u0026C of ‘46.243.189.109’. We\r\nthink they are either written by the same author, or there is heavy code sharing.\r\n4.3 WICKED\r\nhttps://www.virusbulletin.com/virusbulletin/2018/12/vb2018-paper-tracking-mirai-variants/#h2-appendix-sample-sha256-hashes\r\nPage 19 of 25\n\nThe WICKED branch became known for including multiple IoT exploits in 2018. In total, 128 samples have been collected\r\n(up to May 2018), with only one key of 0x37 found and six C\u0026Cs detected. Sample clustering is shown in Figure 19.\r\nFigure 19: Clustering samples of WICKED based on configuration.\r\nThe samples can be clustered into four groups, as shown in Table 9.\r\n(size, count) Samples C\u0026C\r\n(48, 614) 15 104.244.72.82\r\n(27, 737) 4 185.246.152.173\r\n(38, 833) 54\r\n104.236.224.5\r\n104.244.72.82\r\n167.99.220.44\r\n185.189.58.211\r\n185.246.152.173\r\n188.166.63.14\r\n(48, 1362~1376) 55\r\n167.99.220.44\r\n185.246.152.173\r\nTable 9: Stats on WICKED samples.\r\nGiven the fact that several C\u0026Cs are shared across clusters, we think that the WICKED samples are probably produced by\r\nthe same authors. On the other hand, since the IP of 185.246.152.173 is also shared by OWARI samples, the WICKED\r\nbranch could be connected to that branch.\r\nThe size changes in configurations are mainly due to the command lines shown in Figures 20 and 21. Contents shown in\r\nFigure 19 indicate an exclusive infection by this branch.\r\nhttps://www.virusbulletin.com/virusbulletin/2018/12/vb2018-paper-tracking-mirai-variants/#h2-appendix-sample-sha256-hashes\r\nPage 20 of 25\n\nFigure 20: iptables commands\r\nfound in WICKED samples.\r\nFigure 21: Echo commands found in WICKED samples.\r\nFigure 22: Combination attack methods found in WICKED samples.\r\nFrom the point of view of attack methods, combinations of {code, atk_type} are found in WICKED samples, as shown in\r\nFigure 22.\r\n5. Conclusion\r\nWe have introduced how to extract data including configurations, supported attack methods, and dictionaries of usernames\r\nand passwords from Mirai samples, and how to use the extracted data for variant classification and tracking, with different\r\nschemes discussed. Some popular Mirai branches have been investigated with our proposed schemes. In the future, we will\r\nkeep a close eye on the emerging Mirai variants, and will continue researching better classification schemes, e.g. using fuzzy\r\nhashing techniques to group samples based on their extracted configurations. We hope our work will help improve the\r\ndetection and mitigation of Mirai-like threats.\r\nReferences\r\n[1] Hajime: Analysis of a decentralized internet worm for IoT devices.\r\nhttps://security.rapiditynetworks.com/publications/2016-10-16/hajime.pdf.\r\n[2] IoT_reaper: A Few Updates. http://blog.netlab.360.com/iot_reaper-a-few-updates-en/.\r\n[3] Now Mirai Has DGA Feature Built in. https://blog.netlab.360.com/new-Mirai-variant-with-dga/.\r\n[4] Early Warning: A New Mirai Variant is Spreading Quickly on Port 23 and 2323. https://blog.netlab.360.com/early-warning-a-new-Mirai-variant-is-spreading-quickly-on-port-23-and-2323-en/.\r\n[5] Warning: Satori, a Mirai Branch Is Spreading in Worm Style on Port 37215 and 52869.\r\nhttps://blog.netlab.360.com/warning-satori-a-new-Mirai-variant-is-spreading-in-worm-style-on-port-37215-and-52869-en/.\r\n[6] MMD-0056-2016 – Linux/Mirai, how an old ELF malcode is recycled. http://blog.malwaremustdie.org/2016/08/mmd-0056-2016-linuxMirai-just.html.\r\n[7] Unicorn. https://www.unicorn-engine.org/.\r\n[8] Source Code for IoT Botnet ‘Mirai’ Released. https://krebsonsecurity.com/2016/10/source-code-for-iot-botnet-Mirai-released/.\r\n[9] ADB.Miner: More Information. https://blog.netlab.360.com/adb-miner-more-information-en/.\r\n[10] Early Warning: A New Mirai Variant is Spreading Quickly on Port 23 and 2323. https://blog.netlab.360.com/early-warning-a-new-mirai-variant-is-spreading-quickly-on-port-23-and-2323-en/.\r\nhttps://www.virusbulletin.com/virusbulletin/2018/12/vb2018-paper-tracking-mirai-variants/#h2-appendix-sample-sha256-hashes\r\nPage 21 of 25\n\nAppendix A: Sample SHA256 hashes\r\nMD5 hash: 0ae272306d313c6abf1433b85e0a2352\r\nSHA-256 hash: 0c5bc272d13fc05bca15babd83826ca51accf3a8bc0a52f7e0f7f79ea4496280\r\nMD5 hash: dbba02b2d0ef42d2a1ebbab7f03f37f0\r\nSHA-256 hash: 87f49c75ae9aa3138b893a6ff1c316be1c197bed2021ff84bc6a281b25543ee9\r\nMD5 hash: 08abb658c6a293886a8000a31b900e88\r\nSHA-256 hash: dab9ee751d591af93e998b56efa888ef09f50b2e74ab8a6f7b910b00350a866a\r\nMD5 hash: 2db905373ea58920f7dbf9f3e59ba990\r\nSHA-256 hash: 79c3d3b25aba02959ecf734e93b8c162851c11abe81bd7207a16d496ebfa6ab5\r\nMD5 hash: 82358453a5b5be7a54b7013b8f2ec21d\r\nSHA-256 hash: d7ca6f599d37fcfa146b5c044efda4199cb5713fca0984f93301a85b68934c4e\r\nMD5 hash: 0729b89281c831fc035d56fbf14631da\r\nSHA-256 hash: 3af17b130f9b41d5e3645c2622cfe4be5daee0316084cb10c05adf6d60ec1032\r\nMD5 hash: 23a98fc659982da993e7825eb87bb640\r\nSHA-256 hash: f227b9d6f59b27fce5f23551ea15794bd45e26f3eaab44136d6fdf9903992c3b\r\nMD5 hash: 2ff2d4feff4ffcec355f52993ce7b73e\r\nSHA-256 hash: 3cece358fecfc8fbe2e86a1b2c6ae3a0f34d9648cd2306cd734bc717216a728e\r\nMD5 hash: 333d98e27cc885624f073e59fc40dfed\r\nSHA-256 hash: 17a91b2632b625cbd02a009ef64f1faae016de497a7e3b1395e54dc32c8b12d3\r\nAppendix B: Signature of attack methods\r\nAttack method Fingerprint\r\natk_app_proxy null\r\natk_cf 0x08_0x18\r\natk_gre1 0x02_0x03_0x04_0x05_0x06_0x07_0x00_0x01_0x13_0x19\r\natk_gre2 0x02_0x03_0x04_0x05_0x06_0x07_0x00_0x01_0x12_0x13\r\natk_gre3 0x02_0x03_0x04_0x05_0x06_0x07_0x00_0x01_0x12_0x13_0x06\r\natk_gre4 0x02_0x03_0x04_0x05_0x06_0x07_0x00_0x01_0x12_0x18\r\natk_gre5 0x02_0x03_0x04_0x05_0x06_0x07_0x00_0x01_0x13_0x06\r\natk_gre6 0x02_0x03_0x04_0x05_0x06_0x07_0x00_0x01_0x11_0x12\r\natk_http1 0x15_0x14_0x08_0x16_0x18_0x07\r\natk_http2 0x14_0x13_0x08_0x15_0x17_0x07\r\nhttps://www.virusbulletin.com/virusbulletin/2018/12/vb2018-paper-tracking-mirai-variants/#h2-appendix-sample-sha256-hashes\r\nPage 22 of 25\n\natk_std_or_udp 0x07_0x06_0x00_0x01\r\natk_tcp_ack1 0x02_0x03_0x04_0x05_0x06_0x07_0x11_0x12_0x0b_0x0c_0x0d_0x0e_0x0f_0x10_0x00_0x01_0x19\r\natk_tcp_ack2 0x02_0x03_0x04_0x05_0x06_0x07_0x10_0x11_0x0a_0x0b_0x0c_0x0d_0x0e_0x0f_0x00_0x01_0x13\r\natk_tcp_ack3 0x02_0x03_0x04_0x05_0x06_0x07_0x10_0x11_0x0a_0x0b_0x0c_0x0d_0x0e_0x0f_0x00_0x01_0x13_\r\natk_tcp_ack4 0x02_0x03_0x04_0x05_0x06_0x07_0x10_0x11_0x0a_0x0b_0x0c_0x0d_0x0e_0x0f_0x00_0x01_0x18\r\natk_tcp_ack5 0x02_0x03_0x04_0x05_0x06_0x07_0x11_0x12_0x0b_0x0c_0x0d_0x0e_0x0f_0x10_0x00_0x01\r\natk_tcp_ack6 0x02_0x03_0x04_0x05_0x06_0x07_0x11_0x12_0x0b_0x0c_0x0d_0x0e_0x0f_0x10_0x00_0x01_0x06\r\natk_tcp_ack7 0x02_0x03_0x04_0x05_0x06_0x07_0x10_0x11_0x0a_0x0b_0x0c_0x0d_0x0e_0x0f_0x00_0x01\r\natk_tcp_ack_or_synack 0x02_0x03_0x04_0x05_0x06_0x07_0x0f_0x10_0x09_0x0a_0x0b_0x0c_0x0d_0x0e_0x00_0x01_0x12\r\natk_tcp_stomp_or_xmas1 0x02_0x03_0x04_0x05_0x07_0x0b_0x0c_0x0d_0x0e_0x0f_0x10_0x00_0x01\r\natk_tcp_stomp_or_xmas2 0x02_0x03_0x04_0x05_0x07_0x0a_0x0b_0x0c_0x0d_0x0e_0x0f_0x00_0x01\r\natk_tcp_stomp_or_xmas3 0x02_0x03_0x04_0x05_0x07_0x09_0x0a_0x0b_0x0c_0x0d_0x0e_0x00_0x01\r\natk_tcp_syn1 0x02_0x03_0x04_0x05_0x06_0x07_0x11_0x12_0x0b_0x0c_0x0d_0x0e_0x0f_0x10_0x19\r\natk_tcp_syn10 0x00_0x02_0x03_0x04_0x05_0x06_0x07_0x10_0x11_0x0a_0x0b_0x0c_0x0d_0x0e_0x0f_0x13\r\natk_tcp_syn2 0x00_0x02_0x03_0x04_0x05_0x06_0x07_0x10_0x11_0x0a_0x0b_0x0c_0x0d_0x0e_0x0f_0x18\r\natk_tcp_syn3 0x02_0x03_0x04_0x05_0x06_0x07_0x0f_0x10_0x09_0x0a_0x0b_0x0c_0x0d_0x0e_0x12\r\natk_tcp_syn4 0x02_0x03_0x04_0x05_0x06_0x07_0x10_0x11_0x0a_0x0b_0x0c_0x0d_0x0e_0x0f\r\natk_tcp_syn5 0x02_0x03_0x04_0x05_0x06_0x07_0x10_0x11_0x0a_0x0b_0x0c_0x0d_0x0e_0x0f_0x13\r\natk_tcp_syn6 0x02_0x03_0x04_0x05_0x06_0x07_0x10_0x11_0x0a_0x0b_0x0c_0x0d_0x0e_0x0f_0x13_0x06\r\natk_tcp_syn7 0x02_0x03_0x04_0x05_0x06_0x07_0x10_0x11_0x0a_0x0b_0x0c_0x0d_0x0e_0x0f_0x18\r\natk_tcp_syn8 0x02_0x03_0x04_0x05_0x06_0x07_0x11_0x12_0x0b_0x0c_0x0d_0x0e_0x0f_0x10\r\natk_tcp_syn9 0x02_0x03_0x04_0x05_0x06_0x07_0x11_0x12_0x0b_0x0c_0x0d_0x0e_0x0f_0x10_0x06\r\natk_udp1 0x02_0x03_0x04_0x05_0x06_0x07_0x00_0x01_0x19\r\natk_udp2 0x02_0x03_0x04_0x05_0x06_0x07_0x00_0x01_0x11\r\natk_udp3 0x02_0x03_0x04_0x05_0x06_0x07_0x00_0x01\r\natk_udp4 0x02_0x03_0x04_0x05_0x06_0x07_0x00_0x01_0x18\r\natk_udp5 0x02_0x03_0x04_0x05_0x06_0x07_0x00_0x01_0x19_0x11\r\natk_udp6 0x07_0x06_0x00_0x01_0x10\r\natk_udp_dns 0x02_0x03_0x04_0x05_0x06_0x07_0x09_0x00_0x08\r\natk_udp_or_gre1 0x02_0x03_0x04_0x05_0x06_0x07_0x00_0x01_0x12\r\natk_udp_or_gre2 0x02_0x03_0x04_0x05_0x06_0x07_0x00_0x01_0x13\r\natk_udp_vse1 0x02_0x03_0x04_0x05_0x06_0x07\r\nhttps://www.virusbulletin.com/virusbulletin/2018/12/vb2018-paper-tracking-mirai-variants/#h2-appendix-sample-sha256-hashes\r\nPage 23 of 25\n\natk_udp_vse2 0x02_0x03_0x04_0x05_0x06_0x07_0x11\r\nAppendix C: All recognized combinations of {attack_method_code, attack_type}\r\n{0-atk_app_proxy, 1-atk_app_proxy, 2-atk_app_proxy, 3-atk_app_proxy, 4-atk_app_proxy, 5-atk_app_proxy, 6-atk_a\r\n{0-atk_std_or_udp}\r\n{0-atk_tcp_syn1, 1-atk_tcp_ack1, 2-atk_std_or_udp}\r\n{0-atk_tcp_syn1, 1-atk_tcp_ack1, 2-atk_tcp_stomp_or_xmas1}\r\n{0-atk_udp1, 1-atk_std_or_udp, 2-atk_tcp_syn1, 3-atk_tcp_ack1, 4-atk_tcp_stomp_or_xmas1, 5-atk_gre1, 6-atk_udp\r\n{0-atk_udp1, 1-atk_tcp_syn1, 2-atk_tcp_ack1, 3-atk_gre1, 4-atk_gre1, 5-atk_std_or_udp, 6-atk_tcp_stomp_or_xmas\r\n{0-atk_udp1, 1-atk_udp6, 2-atk_tcp_syn1, 3-atk_tcp_ack1, 4-atk_tcp_stomp_or_xmas1, 5-atk_gre1, 6-atk_udp_dns,\r\n{0-atk_udp1, 1-atk_udp_vse1, 2-atk_std_or_udp, 3-atk_tcp_syn1, 4-atk_tcp_ack1, 5-atk_gre1, 6-atk_gre1, 7-atk_s\r\n{0-atk_udp1, 1-atk_udp_vse1, 2-atk_std_or_udp, 3-atk_tcp_syn1, 4-atk_tcp_ack1, 5-atk_gre1, 6-atk_gre1, 7-atk_s\r\n{0-atk_udp1, 1-atk_udp_vse1, 2-atk_tcp_syn1, 3-atk_tcp_ack1, 4-atk_gre1, 5-atk_gre1, 6-atk_std_or_udp, 7-atk_s\r\n{0-atk_udp1, 1-atk_udp_vse1, 2-atk_tcp_syn1, 3-atk_tcp_ack1, 4-atk_gre1, 5-atk_gre1, 6-atk_std_or_udp, 7-atk_s\r\n{0-atk_udp1, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn1, 4-atk_tcp_ack1, 5-atk_tcp_stomp_or_xmas1, 6-atk_gr\r\n{0-atk_udp1, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn1, 4-atk_tcp_ack1, 5-atk_tcp_stomp_or_xmas1, 6-atk_gr\r\n{0-atk_udp1, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn1, 4-atk_tcp_ack1, 5-atk_tcp_stomp_or_xmas1, 6-atk_gr\r\n{0-atk_udp1, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn1, 4-atk_tcp_ack1, 5-atk_tcp_stomp_or_xmas1, 6-atk_gr\r\n{0-atk_udp1, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn1, 4-atk_tcp_ack1, 5-atk_tcp_stomp_or_xmas1, 6-atk_gr\r\n{0-atk_udp1, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn1, 4-atk_tcp_ack1, 5-atk_tcp_stomp_or_xmas1, 6-atk_gr\r\n{0-atk_udp1, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn1, 4-atk_tcp_ack1, 5-atk_tcp_stomp_or_xmas1, 6-atk_gr\r\n{0-atk_udp1, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn1, 4-atk_tcp_ack1, 5-atk_tcp_stomp_or_xmas1, 6-atk_gr\r\n{0-atk_udp1, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn1, 4-atk_tcp_ack1, 5-atk_tcp_stomp_or_xmas1, 6-atk_gr\r\n{0-atk_udp1, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn1, 4-atk_tcp_ack1, 5-atk_tcp_stomp_or_xmas1, 6-atk_gr\r\n{0-atk_udp1, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn1, 4-atk_tcp_ack1, 5-atk_tcp_stomp_or_xmas1, 6-atk_gr\r\n{0-atk_udp1, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn1, 4-atk_tcp_ack1, 5-atk_tcp_stomp_or_xmas1, 6-atk_gr\r\n{0-atk_udp1, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn1, 4-atk_tcp_ack1, 5-atk_tcp_stomp_or_xmas1, 6-atk_gr\r\n{0-atk_udp1, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn1, 4-atk_tcp_ack1, 5-atk_tcp_stomp_or_xmas1, 6-atk_gr\r\n{0-atk_udp1, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn1, 4-atk_tcp_ack1, 5-atk_tcp_stomp_or_xmas1, 6-atk_st\r\n{0-atk_udp1, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn1, 4-atk_tcp_ack1, 5-atk_tcp_stomp_or_xmas1, 9-atk_st\r\n{0-atk_udp1, 1-atk_udp_vse1, 3-atk_tcp_syn1, 4-atk_tcp_ack1, 5-atk_tcp_stomp_or_xmas1, 6-atk_gre1, 7-atk_gre1\r\n{0-atk_udp1, 1-atk_udp_vse2, 2-atk_udp_dns, 3-atk_tcp_syn1, 4-atk_tcp_ack1, 5-atk_tcp_stomp_or_xmas1, 6-atk_gr\r\n{0-atk_udp1, 3-atk_tcp_syn1, 4-atk_tcp_ack1, 6-atk_gre1, 7-atk_gre1, 9-atk_std_or_udp}\r\n{0-atk_udp3, 1-atk_std_or_udp, 2-atk_tcp_syn8, 3-atk_tcp_ack5, 4-atk_tcp_stomp_or_xmas1, 5-atk_udp_or_gre2, 6-\r\n{0-atk_udp3, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn4, 4-atk_tcp_ack7}\r\n{0-atk_udp3, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn8, 4-atk_tcp_ack5, 5-atk_tcp_stomp_or_xmas1, 6-atk_ud\r\n{0-atk_udp3, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn8, 4-atk_tcp_ack5, 5-atk_tcp_stomp_or_xmas1, 6-atk_ud\r\n{0-atk_udp3, 1-atk_udp_vse2, 2-atk_udp_dns, 3-atk_tcp_syn9, 4-atk_tcp_ack6, 5-atk_tcp_stomp_or_xmas1, 6-atk_gr\r\n{0-atk_udp4, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn2, 4-atk_tcp_ack4, 5-atk_tcp_stomp_or_xmas2, 6-atk_gr\r\n{0-atk_udp4, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn2, 4-atk_tcp_ack4, 5-atk_tcp_stomp_or_xmas2, 6-atk_gr\r\n{0-atk_udp4, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn2, 4-atk_tcp_ack4, 5-atk_tcp_stomp_or_xmas2, 6-atk_gr\r\n{0-atk_udp4, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn2, 4-atk_tcp_ack4}\r\n{0-atk_udp4, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn7, 4-atk_tcp_ack4, 5-atk_tcp_stomp_or_xmas2, 6-atk_gr\r\n{0-atk_udp4, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn7, 4-atk_tcp_ack4, 5-atk_tcp_stomp_or_xmas2, 6-atk_gr\r\n{0-atk_udp4, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn7, 4-atk_tcp_ack4, 5-atk_tcp_stomp_or_xmas2, 6-atk_gr\r\n{0-atk_udp4, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn7, 4-atk_tcp_ack4}\r\n{0-atk_udp5, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn1, 4-atk_tcp_ack1, 5-atk_tcp_stomp_or_xmas1, 6-atk_gr\r\n{0-atk_udp_or_gre1, 1-atk_udp_vse1, 2-atk_tcp_syn3, 3-atk_tcp_ack_or_synack, 4-atk_tcp_ack_or_synack, 5-atk_tc\r\n{0-atk_udp_or_gre2, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn10, 4-atk_tcp_ack2, 5-atk_tcp_stomp_or_xmas2,\r\n{0-atk_udp_or_gre2, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn10, 4-atk_tcp_ack2}\r\n{0-atk_udp_or_gre2, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn10, 6-atk_gre2, 7-atk_gre2, 8-atk_std_or_udp,\r\n{0-atk_udp_or_gre2, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn10, 6-atk_gre2, 7-atk_gre2, 8-atk_std_or_udp}\r\n{0-atk_udp_or_gre2, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn5, 4-atk_tcp_ack2, 5-atk_tcp_stomp_or_xmas2, 6\r\n{0-atk_udp_or_gre2, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn5, 4-atk_tcp_ack2, 5-atk_tcp_stomp_or_xmas2, 6\r\n{0-atk_udp_or_gre2, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn5, 4-atk_tcp_ack2, 5-atk_tcp_stomp_or_xmas2, 6\r\nhttps://www.virusbulletin.com/virusbulletin/2018/12/vb2018-paper-tracking-mirai-variants/#h2-appendix-sample-sha256-hashes\r\nPage 24 of 25\n\n{0-atk_udp_or_gre2, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn5, 4-atk_tcp_ack2, 5-atk_tcp_stomp_or_xmas2, 8\r\n{0-atk_udp_or_gre2, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn5, 4-atk_tcp_ack2, 6-atk_gre2, 7-atk_gre2, 8-a\r\n{0-atk_udp_or_gre2, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn5, 4-atk_tcp_ack2, 6-atk_gre2, 7-atk_gre2, 8-a\r\n{0-atk_udp_or_gre2, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn5, 4-atk_tcp_ack2}\r\n{0-atk_udp_or_gre2, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn5, 6-atk_gre2, 7-atk_gre2, 8-atk_std_or_udp, 9\r\n{0-atk_udp_or_gre2, 1-atk_udp_vse1, 2-atk_udp_dns, 3-atk_tcp_syn5, 6-atk_gre2, 7-atk_gre2, 8-atk_std_or_udp}\r\n{1-atk_tcp_syn1, 3-atk_std_or_udp, 4-atk_std_or_udp, 5-atk_tcp_stomp_or_xmas1}\r\n{1-atk_tcp_syn10, 2-atk_tcp_ack2}\r\n{1-atk_tcp_syn5, 2-atk_tcp_ack2}\r\n{1-atk_udp_vse1, 2-atk_tcp_syn3, 3-atk_tcp_ack_or_synack, 4-atk_std_or_udp, 5-atk_std_or_udp, 6-atk_tcp_stomp_\r\n{1-atk_udp_vse1, 3-atk_tcp_syn1, 4-atk_tcp_ack1, 5-atk_tcp_stomp_or_xmas1, 6-atk_gre1, 7-atk_gre1, 9-atk_std_o\r\n{1-atk_udp_vse1, 3-atk_tcp_syn1, 4-atk_tcp_ack1, 6-atk_gre1, 7-atk_gre1, 9-atk_std_or_udp, 10-atk_tcp_stomp_or\r\n{3-atk_tcp_syn1, 4-atk_tcp_ack1, 5-atk_tcp_stomp_or_xmas1, 6-atk_gre1, 7-atk_gre1, 10-atk_http1}\r\n{3-atk_tcp_syn1, 4-atk_tcp_ack1, 6-atk_gre1, 7-atk_gre1, 10-atk_http1}\r\n{3-atk_tcp_syn1, 4-atk_tcp_ack1, 6-atk_gre1, 7-atk_gre1, 9-atk_std_or_udp}\r\n{3-atk_tcp_syn1, 6-atk_gre1, 7-atk_gre1, 10-atk_http1}\r\n{6-atk_gre1, 7-atk_gre1, 10-atk_http1}\r\n{9-atk_std_or_udp}\r\nSource: https://www.virusbulletin.com/virusbulletin/2018/12/vb2018-paper-tracking-mirai-variants/#h2-appendix-sample-sha256-hashes\r\nhttps://www.virusbulletin.com/virusbulletin/2018/12/vb2018-paper-tracking-mirai-variants/#h2-appendix-sample-sha256-hashes\r\nPage 25 of 25\n\nIn total, four keys Variant are found to be used in this branch. Their stats are Samples shown Table 7. C\u0026Cs\nMASUTA+0x45 351 53\nMASUTA+0x02 90 5\n Page 17 of 25", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://www.virusbulletin.com/virusbulletin/2018/12/vb2018-paper-tracking-mirai-variants/#h2-appendix-sample-sha256-hashes" ], "report_names": [ "#h2-appendix-sample-sha256-hashes" ], "threat_actors": [ { "id": "6f30fd35-b1c9-43c4-9137-2f61cd5f031e", "created_at": "2025-08-07T02:03:25.082908Z", "updated_at": "2026-04-10T02:00:03.744649Z", "deleted_at": null, "main_name": "NICKEL FOXCROFT", "aliases": [ "APT37 ", "ATK4 ", "Group 123 ", "InkySquid ", "Moldy Pisces ", "Operation Daybreak ", "Operaton Erebus ", "RICOCHET CHOLLIMA ", "Reaper ", "ScarCruft ", "TA-RedAnt ", "Venus 121 " ], "source_name": "Secureworks:NICKEL FOXCROFT", "tools": [ "Bluelight", "Chinotto", "GOLDBACKDOOR", "KevDroid", "KoSpy", "PoorWeb", "ROKRAT", "final1stpy" ], "source_id": "Secureworks", "reports": null }, { "id": "9b02c527-5077-489e-9a80-5d88947fddab", "created_at": "2022-10-25T16:07:24.103499Z", "updated_at": "2026-04-10T02:00:04.867181Z", "deleted_at": null, "main_name": "Reaper", "aliases": [ "APT 37", "ATK 4", "Cerium", "Crooked Pisces", "G0067", "Geumseong121", "Group 123", "ITG10", "InkySquid", "Moldy Pisces", "Opal Sleet", "Operation Are You Happy?", "Operation Battle Cruiser", "Operation Black Banner", "Operation Daybreak", "Operation Dragon messenger", "Operation Erebus", "Operation Evil New Year", "Operation Evil New Year 2018", "Operation Fractured Block", "Operation Fractured Statue", "Operation FreeMilk", "Operation Golden Bird", "Operation Golden Time", "Operation High Expert", "Operation Holiday Wiper", "Operation Korean Sword", "Operation North Korean Human Right", "Operation Onezero", "Operation Rocket Man", "Operation SHROUDED#SLEEP", "Operation STARK#MULE", "Operation STIFF#BIZON", "Operation Spy Cloud", "Operation Star Cruiser", "Operation ToyBox Story", "Osmium", "Red Eyes", "Ricochet Chollima", "Ruby Sleet", "ScarCruft", "TA-RedAnt", "TEMP.Reaper", "Venus 121" ], "source_name": "ETDA:Reaper", "tools": [ "Agentemis", "BLUELIGHT", "Backdoor.APT.POORAIM", "CARROTBALL", "CARROTBAT", "CORALDECK", "Cobalt Strike", "CobaltStrike", "DOGCALL", "Erebus", "Exploit.APT.RICECURRY", "Final1stSpy", "Freenki Loader", "GELCAPSULE", "GOLDBACKDOOR", "GreezeBackdoor", "HAPPYWORK", "JinhoSpy", "KARAE", "KevDroid", "Konni", "MILKDROP", "N1stAgent", "NavRAT", "Nokki", "Oceansalt", "POORAIM", "PoohMilk", "PoohMilk Loader", "RICECURRY", "RUHAPPY", "RokRAT", "SHUTTERSPEED", "SLOWDRIFT", "SOUNDWAVE", "SYSCON", "Sanny", "ScarCruft", "StarCruft", "Syscon", "VeilShell", "WINERACK", "ZUMKONG", "cobeacon" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434115, "ts_updated_at": 1775792286, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/ef694bc768601d892b1e613f6ab4cceff0ee933a.pdf", "text": "https://archive.orkl.eu/ef694bc768601d892b1e613f6ab4cceff0ee933a.txt", "img": "https://archive.orkl.eu/ef694bc768601d892b1e613f6ab4cceff0ee933a.jpg" } }