{
	"id": "906cc3c8-7eed-4188-8ed9-acbaeb45c172",
	"created_at": "2026-04-06T00:15:28.024795Z",
	"updated_at": "2026-04-10T13:12:54.211855Z",
	"deleted_at": null,
	"sha1_hash": "6200d6f9c60eb36c25bd7cfb6fe05df450edd2dd",
	"title": "Collecting and operationalizing threat data from the Mozi botnet",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1384586,
	"plain_text": "Collecting and operationalizing threat data from the Mozi botnet\r\nBy Andrew Pease, Seth Goodwin, Derek Ditch, Daniel Stepanic\r\nPublished: 2022-06-02 · Archived: 2026-04-05 20:14:51 UTC\r\nDetecting and preventing malicious activity such as botnet attacks is a critical area of focus for threat intel\r\nanalysts, security operators, and threat hunters. Taking up the Mozi botnet as a case study, this blog post\r\ndemonstrates how to use open source tools, analytical processes, and the Elastic Stack to perform analysis and\r\nenrichment of collected data irrespective of the campaign. This will allow you to take the lessons and processes\r\noutlined below to your organization and apply them to your specific use cases.\r\nThe Mozi botnet has been leveraging vulnerable Internet of Things (IoT) devices to launch campaigns that can\r\ntake advantage of the force multiplication provided by a botnet (Distributed Denial of Service (DDoS), email\r\nspam, brute-force, password spraying, etc.). Mozi was first reported by the research team at 360Netlab in\r\nDecember 2019 and has continued to make up a large portion of IoT network activity across the Internet-at-large.\r\nAs reported by 360Netlab, the botnet spreads via the use of weak and default remote access passwords for targeted\r\ndevices as well as through multiple public exploits. The Mozi botnet communicates using a Distributed Hash\r\nTable (DHT) which records the contact information for other nodes in the botnet. This is the same serverless\r\nmechanism used by file sharing peer-to-peer (P2P) clients. Once the malware has accessed a vulnerable device, it\r\nexecutes the payload and subsequently joins the Mozi P2P network. The newly infected device listens for\r\ncommands from controller nodes and also attempts to infect other vulnerable devices.\r\nMozi targets multiple IoT devices and systems, mainly focused on Small Office Home Office (SOHO) networking\r\ndevices, Internet-connected audio visual systems, and theoretically any 32-bit ARM device.\r\nCollection\r\nWhen performing data analysis, the more data that you have, the better. Analysis of malware campaigns are no\r\ndifferent. With a paid subscription to VirusTotal, you can collect huge amounts of data for analysis, but we wanted\r\nan approach for independent researchers or smaller organizations that may not have this premium service. To do\r\nthat, we decided to keep to our roots at Elastic and leverage open source datasets to avoid a paywall that could\r\nprevent others from using our processes.\r\nTo begin, we started with a handful of Mozi samples collected from ThreatFox. ThreatFox is an open source\r\nplatform from Abuse.ch with the goal of sharing malware indicators with the security research community.\r\nUsing cURL, we queried the ThreatFox API for the Mozi tag. This returned back JSON documents with\r\ninformation about the malware sample, based on the tagged information.\r\ncurl -X POST https://threatfox-api.abuse.ch/api/v1/ -d '{ \"query\": \"taginfo\", \"tag\": \"Mozi\", \"limit\": 1 }'\r\nhttps://www.elastic.co/blog/collecting-and-operationalizing-threat-data-from-the-mozi-botnet\r\nPage 1 of 15\n\nCode block 1 - cURL request to ThreatFox API\r\n-X POST - change the cURL HTTP method from GET (default) to POST as we’re going to be sending data\r\nto the ThreatFox API\r\nhttps://threatfox-api.abuse.ch/api/v1/ - this is the ThreatFox API endpoint\r\n-d - this is denoting that we’re going to be sending data\r\nquery: taginfo - the type of query that we’re making, taginfo in our example\r\ntag: Mozi - the tag that we’ll be searching for, “Mozi” in our example\r\nlimit: 1 - the number of results to return, 1 result in our example, but you can return up to 1000 results\r\nThis returned the following information:\r\n{\r\n \"query_status\": \"ok\",\r\n \"data\": [\r\n {\r\n \"id\": \"115772\",\r\n \"ioc\": \"nnn.nnn.nnn.nnn:53822\",\r\n \"threat_type\": \"botnet_cc\",\r\n \"threat_type_desc\": \"Indicator that identifies a botnet command\u0026control server (C\u0026C)\",\r\n \"ioc_type\": \"ip:port\",\r\n \"ioc_type_desc\": \"ip:port combination that is used for botnet Command\u0026control (C\u0026C)\",\r\n \"malware\": \"elf.mozi\",\r\n \"malware_printable\": \"Mozi\",\r\n \"malware_alias\": null,\r\n \"malware_malpedia\": \"https:\\/\\/malpedia.caad.fkie.fraunhofer.de\\/details\\/elf.mozi\",\r\n \"confidence_level\": 75,\r\n \"first_seen\": \"2021-06-15 08:22:52 UTC\",\r\n \"last_seen\": null,\r\n \"reference\": \"https:\\/\\/bazaar.abuse.ch\\/sample\\/832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94\r\n \"reporter\": \"abuse_ch\",\r\n \"tags\": [\r\n \"Mozi\"\r\n ]\r\n }\r\n ]\r\nCode block 2 - Response from ThreatFox API\r\nNow that we have the file hashes of several samples, we can download the samples using the Malware Bazaar\r\nAPI. Malware Bazaar is another open source platform provided by Abuse.ch. While ThreatFox is used to share\r\ncontextual information about indicators, Malware Bazaar allows for the actual collection of malware samples\r\n(among other capabilities).\r\nJust like with ThreatFox, we’ll use cURL to interact with the Malware Bazaar API, but this time to download the\r\nactual malware samples. Of note, the Malware Bazaar API can be used to search for samples using a tag (“Mozi”,\r\nhttps://www.elastic.co/blog/collecting-and-operationalizing-threat-data-from-the-mozi-botnet\r\nPage 2 of 15\n\nin our example), similar to how we used the ThreatFox API. The difference is that the ThreatFox API returns\r\nnetwork indicators that we’ll use later on for data enrichment.\r\ncurl -X POST https://mb-api.abuse.ch/api/v1 -d 'query=get_file\u0026sha256_hash=832fb4090879c1bebe75bea939a9c5724dbf\r\nCode block 3 - cURL request to Malware Bazaar API\r\n-X POST - change the cURL HTTP method from GET (default) to POST as we’re going to be sending data\r\nto the Malware Bazaar API\r\nhttps://mb-api.abuse.ch/api/v1 - this is the Malware Bazaar API endpoint\r\n-d - this is denoting that we’re going to be sending data\r\nquery: get_file - the type of query that we’re making, get_file in our example\r\nsha256_hash - the SHA256 hash we’re going to be collecting,\r\n“832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b” in our example\r\n-o - the file name we’re going to save the binary as\r\nThis will save a file locally named\r\n832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b.raw. We want to make a raw file that\r\nwe’ll not modify so that we always have an original sample for archival purposes. This downloads the file as a Zip\r\narchive. The passphrase to extract the archive is infected. This will create a local file named\r\n832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b.elf. Going forward, we’ll use a\r\nshorter name for this file, truncated-87d3b.elf, for readability.\r\nUnpacking\r\nNow that we have a few samples to work with we can look at ripping out strings for further analysis. Once in our\r\nanalysis VM we took a stab at running Sysinternals Strings over our sample:\r\n$ strings truncated-87d3b.elf\r\nELF\r\n*UPX!\r\nELF\r\n$Bw\r\n(GT\r\n...\r\nCode block 3 - Strings output from the packed Mozi sample\r\nRight away we see that we have a UPX packed ELF binary from the “ELF” and “UPX!” text. UPX is a\r\ncompression tool for executable files, commonly known as “packing”. So the next logical step is to decompress\r\nthe ELF file with the UPX program. To do that, we’ll run upx with the -d switch.\r\n$ upx -d truncated-87d3b.elf\r\n Ultimate Packer for eXecutables\r\nhttps://www.elastic.co/blog/collecting-and-operationalizing-threat-data-from-the-mozi-botnet\r\nPage 3 of 15\n\nCopyright (C) 1996 - 2020\r\nUPX 3.96w Markus Oberhumer, Laszlo Molnar \u0026 John Reiser Jan 23rd 2020\r\n File size Ratio Format Name\r\n -------------------- ------ ----------- -----------\r\nupx.exe : upx: truncated-87d3b.elf : CantUnpackException: p_info corrupted\r\nCode block 4 - UPX output from corrupted Mozi sample\r\nAnother road-block: the p_info section of the file appears to be corrupted. p_info is the sum of two sections from a\r\nfile, p_blocksize and p_filesize . After a quick search for the error message, we landed on a CUJOAI Anti-Unpacking blog explaining the header corruptions commonly used in IoT malware to disrupt automated analysis\r\ntools.\r\nUsing this information, we cracked open our binary in xxd, a HEX dumper, to see which corruption we were\r\ndealing with. As described in the CUJOAI blog, the p_info blocks represent the sum of the p_filesize blocks and\r\nthe p_blocksize blocks. This section begins with the 8 bytes after the UPX! text, and has been overwritten with\r\nzeros (the 8 bytes starting at 0x84 ).\r\n$ xxd truncated-87d3b.elf\r\n00000000: 7f45 4c46 0101 0161 0000 0000 0000 0000 .ELF...a........\r\n00000010: 0200 2800 0100 0000 1057 0200 3400 0000 ..(......W..4...\r\n00000020: 0000 0000 0202 0000 3400 2000 0200 2800 ........4. ...(.\r\n00000030: 0000 0000 0100 0000 0000 0000 0080 0000 ................\r\n00000040: 0080 0000 0de0 0100 0de0 0100 0500 0000 ................\r\n00000050: 0080 0000 0100 0000 b07a 0000 b0fa 0600 .........z......\r\n00000060: b0fa 0600 0000 0000 0000 0000 0600 0000 ................\r\n00000070: 0080 0000 10f1 8f52 5550 5821 1c09 0d17 .......RUPX!....\r\n00000080: 0000 0000 0000 0000 0000 0000 9400 0000 ................\r\n00000090: 5e00 0000 0300 0000 f97f 454c 4601 7261 ^.........ELF.ra\r\n000000a0: 000f 0200 28dd 0001 0790 b681 0334 ee07 ....(........4..\r\n000000b0: ec28 04db 1302 0bfb 2000 031b be0a 0009 .(...... .......\r\n...\r\nCode block 5 - HEX view of the corrupted Mozi sample\r\nThe CUJOAI blog states that if you manually update the values of the p_filesize blocks and the p_blocksize\r\nblocks with the value of the p_info, this will fix the corruption issue. Below we can see the p_info section in HEX,\r\nand we can use that to manually update the p_filesize and p_blocksize sections, which will allow us to unpack the\r\nbinary (the 4 bytes starting at 0x1e110).\r\n$ xxd truncated-87d3b.elf\r\n...\r\n0001e0c0: 1914 a614 c998 885d 39ec 4727 1eac 2805 .......]9.G'..(.\r\n0001e0d0: e603 19f6 04d2 0127 52c9 9b60 00be 273e .......'R..`..'\u003e\r\n0001e0e0: c00f 5831 6000 0000 0000 90ff 0000 0000 ..X1`...........\r\nhttps://www.elastic.co/blog/collecting-and-operationalizing-threat-data-from-the-mozi-botnet\r\nPage 4 of 15\n\n0001e0f0: 5550 5821 0000 0000 5550 5821 0d17 0308 UPX!....UPX!....\r\n0001e100: 5199 6237 591c 321c d001 0000 b800 0000 Q.b7Y.2.........\r\n0001e110: 7c2a 0400 5000 0011 8000 0000 |*..P.......\r\nCode block 6 - p_info HEX data from the corrupted Mozi sample\r\nFirst, let’s open the file with Vim. As we can see, it is just a UPX file as denoted by the UPX!.\r\n$ vim truncated-87d3b.elf\r\n^?ELF^A^A^Aa^@^@^@^@^@^@^@^@^B^@(^@^A^@^@^@^PW^B^@4^@^@^@^@^@^@^@^B^B^@^@4^@ ^@^B^@(^@^@^@^@^@^A^@^@^@^@^@^@^@^@\r\nCode block 7 - Corrupted Mozi sample in Vim\r\nUsing the xxd plugin for Vim, we can convert this to HEX so that we can make our modifications. This is\r\nachieved by typing :%!xxd, which will show us the HEX output for the file.\r\n00000000: 7f45 4c46 0101 0161 0000 0000 0000 0000 .ELF...a........\r\n00000010: 0200 2800 0100 0000 1057 0200 3400 0000 ..(......W..4...\r\n00000020: 0000 0000 0202 0000 3400 2000 0200 2800 ........4. ...(.\r\n00000030: 0000 0000 0100 0000 0000 0000 0080 0000 ................\r\n00000040: 0080 0000 0de0 0100 0de0 0100 0500 0000 ................\r\n00000050: 0080 0000 0100 0000 b07a 0000 b0fa 0600 .........z......\r\n00000060: b0fa 0600 0000 0000 0000 0000 0600 0000 ................\r\n00000070: 0080 0000 10f1 8f52 5550 5821 1c09 0d17 .......RUPX!....\r\n00000080: 0000 0000 0000 0000 0000 0000 9400 0000 ................\r\n00000090: 5e00 0000 0300 0000 f97f 454c 4601 7261 ^.........ELF.ra\r\n000000a0: 000f 0200 28dd 0001 0790 b681 0334 ee07 ....(........4..\r\n000000b0: ec28 04db 1302 0bfb 2000 031b be0a 0009 .(...... .......\r\nCode block 8 - Corrupted Mozi sample in Vim with XXD plugin\r\nNext, we can just update bytes 0x84 - 0x8b(that we identified as having the zero’d out p_filesize and p_blocksize)\r\nwith the HEX value for p_info (7c2a 0400).\r\n00000080: 0000 0000 7c2a 0400 7c2a 0400 9400 0000 ....|*..|*......\r\nCode block 9 - Updated p_filesize and p_blocksize HEX values\r\nLet’s reset the file back using :%!xxd -r, save the file and exit Vim (:wq).\r\nFinally, let’s try to unpack the file now that we’ve manually adjusted the HEX values.\r\n$ upx -d truncated-87d3b.elf\r\n Ultimate Packer for eXecutables\r\n Copyright (C) 1996 - 2020\r\nhttps://www.elastic.co/blog/collecting-and-operationalizing-threat-data-from-the-mozi-botnet\r\nPage 5 of 15\n\nUPX 3.96 Markus Oberhumer, Laszlo Molnar \u0026 John Reiser Jan 23rd 2020\r\n File size Ratio Format Name\r\n -------------------- ------ ----------- -----------\r\n 273020 \u003c- 123165 45.11% linux/arm truncated-87d3b.elf\r\nUnpacked 1 file.\r\nCode block 10 - Successfully unpacked Mozi sample\r\nWe now have successfully unpacked the file. Let’s check to see what kind of file this is now by using the file\r\ncommand.\r\n$ file truncated-87d3b.elf\r\ntruncated-87d3b.elf: ELF 32-bit LSB executable, ARM, version 1 (ARM), statically linked, stripped\r\nCode block 11 - File type identification of the Mozi sample\r\nNow, we can again use the strings command to see if there is any useful information that we can use (truncated for\r\nreadability).\r\n$ strings truncated-87d3b.elf\r\n...\r\niptables -I OUTPUT -p udp --source-port %d -j ACCEPT\r\niptables -I PREROUTING -t nat -p udp --destination-port %d -j ACCEPT\r\niptables -I POSTROUTING -t nat -p udp --source-port %d -j ACCEPT\r\niptables -I INPUT -p udp --dport %d -j ACCEPT\r\niptables -I OUTPUT -p udp --sport %d -j ACCEPT\r\niptables -I PREROUTING -t nat -p udp --dport %d -j ACCEPT\r\niptables -I POSTROUTING -t nat -p udp --sport %d -j ACCEPT\r\n0.0.0.0\r\n[idp]\r\nThis node doesn't accept announces\r\nv2s\r\ndht.transmissionbt.com:6881\r\nrouter.bittorrent.com:6881\r\nrouter.utorrent.com:6881\r\nbttracker.debian.org:6881\r\nnnn.nnn.nnn.nnn:6881\r\nabc.abc.abc.abc:6881\r\nxxx.xxx.xxx.xxx:6881\r\nyyy.yyy.yyy.yyy:6881\r\nNfZ\r\nOo~Mn\r\ng5=\r\nN]%\r\nRange: bytes=\r\nhttps://www.elastic.co/blog/collecting-and-operationalizing-threat-data-from-the-mozi-botnet\r\nPage 6 of 15\n\nUser-Agent:\r\n...\r\nCode block 12 - Strings output from the unpacked Mozi sample\r\nRunning Strings, we can see, among other things, network indicators and changes to the local firewall, iptables.\r\nThere is a lot of great information in this file that we can now review which can be used to search for infected\r\ndevices.\r\nNext, let’s enrich the ThreatFox data, store it in Elasticsearch, and visualize it with Kibana.\r\nStoring threat data in the Elastic Stack\r\nLooking at what we’ve collected so far, we have rich threat data provided by ThreatFox that includes both\r\nnetwork and file information. Additionally, we have actual malware samples collected from Malware Bazaar.\r\nFinally, we have performed static file analysis on the malware to identify additional indicators that could be of\r\nuse.\r\nFor the next steps, we’re going to parse the data from ThreatFox and store that in the Elastic Stack so that we can\r\nleverage Kibana to visualize data to identify clusters of activity.\r\nCreate the Ingest Node Pipeline\r\nWe're going to create an Ingest Node Pipeline to transform the data from ThreatFox into enriched Elasticsearch\r\ndata. When making a pipeline, it's useful to make a table to lay out what we're going to do.\r\nThreatFox field ECS-style field\r\nid event.id\r\nioc threat.indicator.ip and threat.indicator.port\r\nthreat_type threat.software.type\r\nthreat_type_desc threat.indicator.description\r\nioc_type threat.indicator.type. Set threat.indicator.type to \"ipv4-addr\"\r\nmalware threat.software.name\r\nmalware_printable threat.threatfox.malware_printable\r\nmalware_alias threat.software.alias (if non-null)\r\nmalware_malpedia threat.software.reference\r\nconfidence_level threat.indicator.confidence\r\nhttps://www.elastic.co/blog/collecting-and-operationalizing-threat-data-from-the-mozi-botnet\r\nPage 7 of 15\n\nfirst_seen threat.indicator.first_seen\r\nlast_seen threat.indicator.last_seen\r\nreference event.reference\r\nreporter event.provider\r\ntags tags\r\n\u003cenrichment\u003e threat.indicator.geo. Enriched by our geoip processor.\r\n\u003cparsed-sha256\u003e file.hash.sha256 and related.hash\r\n\u003ccopy threat.indicator.ip\u003e related.ip\r\nTable 1 - Elasticsearch Ingest Node Pipeline for ThreatFox data\r\nTo create the pipeline, go to Kibana Stack Management -\u003e Ingest Node Pipelines , then click Create pipeline.\r\nFigure 1 - Creating Ingest Node Pipeline for ThreatFox data\r\nNext, we’ll give our pipeline a name, optionally a version, and a description.\r\nFrom this view you can manually add processors and configure them to your liking. To give you a head start,\r\nwe've provided the ThreatFox pipeline definition here you can paste in.\r\nClick Import processors and paste the contents of this pipeline definition: pipeline.json.\r\nWhen you click Load and overwrite , you'll have each processor listed there as we've configured it. From here\r\nyou can tweak it to your needs, or just scroll down and click Create pipeline.\r\nhttps://www.elastic.co/blog/collecting-and-operationalizing-threat-data-from-the-mozi-botnet\r\nPage 8 of 15\n\nFigure 2 - Ingest Node Processors for ThreatFox data\r\nAlternatively, if you’d like to use a turnkey approach, the collection.sh script will allow you to collect the\r\nThreatFox Mozi data, create the Elasticsearch ingest pipeline, the indicators Index, the Index Pattern, and send the\r\ndata from ThreatFox directly into Elasticsearch.\r\n$ git clone https://github.com/elastic/examples\r\n$ cd examples/blog/mozin-about\r\n$ sh collection.sh\r\nCode block 13 - Using the Mozi sample collection script\r\nUsing the provided collection script, we can see the Threat Fox data is converted into the Elastic Common\r\nSchema (ECS) and sent to Elasticsearch for analysis.\r\nFigure 3 - ThreatFox data in Kibana\r\nAnalysis\r\nNow that we’ve collected our samples, enriched them, and stored them in Elasticsearch, we can use Kibana to\r\nvisualize this data to identify clusters of activity, make different observations, and set up different pivots for new\r\nresearch.\r\nAs a few quick examples, we can identify some ports that are used and countries that are included in the dataset.\r\nLet’s start with identifying high-density network ports. Make a Lens visualization in Kibana by clicking on\r\nVisualization Library → Create visualization → Lens. We can make a simple donut chart to highlight that the\r\nhttps://www.elastic.co/blog/collecting-and-operationalizing-threat-data-from-the-mozi-botnet\r\nPage 9 of 15\n\nthreat.indicator.port of 6000 makes up over 10% of the network ports observed. This could lead us to explore\r\nother network traffic that is using port 6000 to identify other potentially malicious activity.\r\nFigure 4 - Port layout for Mozi network traffic\r\nOf note, port 0 and 4000 are also observed and are interesting. Ports 6000, 4000, nor 0 are overly common on the\r\nInternet-at-large and could be used to identify other compromised hosts. It should be noted that while transient\r\nnetwork indicators like IP and port are useful, they should not be used as the sole source to identify malicious\r\nactivity irrespective of the intrusion set being investigated.\r\nNext, we can use a Kibana Maps visualization to identify geographic clusters of activities, and include associated\r\ncontext such as indicator confidence, provider, and type.\r\nhttps://www.elastic.co/blog/collecting-and-operationalizing-threat-data-from-the-mozi-botnet\r\nPage 10 of 15\n\nFigure 5 - Geographic data from Mozi command \u0026 control infrastructure\r\nSimilar to the commentary above on IP and ports, geographic observations should not be the sole source used to\r\ntake action. These are simply indicators for observed samples and require organizational-centric analysis to\r\nascertain their meaning as it relates to the specific network.\r\nThis is useful information we can make the following analytical assertions based on our sampling:\r\nMozi botnet is currently active and maintaining steady infection rates\r\nPort 6000 is a dominant port used for command \u0026 control\r\nAt least 24 countries impacted suggests global threat with no specific targeting\r\nClusters of specific ASNs in Bulgaria and India stand out with highest volumes\r\nAs the analysis process starts to flow, it ends up providing additional avenues for research. One example an\r\nanalyst may pursue is a propagation mechanism through the use of HTTP fingerprinting.\r\nExploring the propagation mechanism\r\nIn the same manner as criminal fingerprints are tracked and logged in a database, a similar technique can be\r\napplied to publicly facing network infrastructure. An HTTP request can be sent to a webserver and the HTTP\r\nresponse that is returned can be used to identify possible web applications hosted on the server; even the ordering\r\nof the fields in the HTTP response can be used as an identifier.\r\nhttps://www.elastic.co/blog/collecting-and-operationalizing-threat-data-from-the-mozi-botnet\r\nPage 11 of 15\n\nOne thing we learned about Mozi and how it contributes to its spreading power is that each compromised device\r\ncontributes to the infection of future victims. The compromised device starts an HTTP server that hosts a Mozi\r\npayload on a random TCP port. Knowing this information, we can collect content from an infected system to\r\ngenerate a fingerprint using cURL.\r\ncurl -I nnn.nnn.nnn.nnn:53822\r\nHTTP/1.1 200 OK\r\nServer: nginx\r\nContent-Length: 132876\r\nConnection: close\r\nContent-Type: application/zip\r\nCode block 14 - HTTP response from a compromised device\r\nBased on the observed response back, we can pull back some interesting information such as:\r\nThe use of an NGINX web server\r\nNo HTTP Date Header provided\r\nThe size of the file returned is close to 133 kilobytes\r\nWith this small amount of data, we can pivot to different search engines that store response data from these kinds\r\nof devices all over the world. By leveraging tools like Shodan, we can perform a search using the information\r\nobtained in the HTTP response. We’ll wildcard the Content-Length but use the same order for all of the HTTP\r\nresponse elements:\r\nHTTP/1.1 200 OK Server: nginx Content-Length: * Connection: close Content-Type: application/zip\r\nCode block 15 - HTTP header for Mozi propagation\r\nWe can see a number of hits where this same response was captured on other devices and start to pinpoint\r\nadditional machines. Below are a few examples from a Shodan search:\r\nhttps://www.elastic.co/blog/collecting-and-operationalizing-threat-data-from-the-mozi-botnet\r\nPage 12 of 15\n\nFigure 6 - Additional impacted devices\r\nOther search examples over response data could be used as well such as the actual bytes of the malicious Mozi file\r\nthat was returned in the response.\r\nMitigation\r\nThe Mozi botnet propagates through the abuse of default or weak remote access passwords, exploits and outdated\r\nsoftware versions. To defend devices from exploitation, we recommend:\r\nChanging the device default remote access passphrases\r\nhttps://www.elastic.co/blog/collecting-and-operationalizing-threat-data-from-the-mozi-botnet\r\nPage 13 of 15\n\nUpdating devices to the latest firmware and software version supported by the vendor\r\nSegmenting IoT devices from the rest of your internal network\r\nNot making IoT devices accessible from the public Internet\r\nDetection logic\r\nUsing YARA, we can write a signature for the corrupted UPX header. Similar to rules that look for specific types\r\nof PowerShell obfuscation, the obfuscation mechanism itself can occasionally be a better indicator of\r\nmaliciousness than attempting to signature the underlying activity. It is extremely important to note that zeroing\r\nout part of the header sections was the technique that we observed with our samples. There are a litany of other\r\nobfuscation and anti-analysis techniques that could be used with other samples. MITRE ATT\u0026CK® describes\r\nadditional subtechniques for the Obfuscated Files or Information technique from the Defense Evasion tactic.As\r\nnoted above, the observed anti-analysis technique used by the analyzed Mozi samples consists solely of zeroing\r\nout the 8 bytes after the “UPX!” magic bytes, and the 4 bytes before that are always zero, so let's use a YARA\r\nsignature derived from the work by Lars Wallenborn (expanded for readability).\r\nrule Mozi_Obfuscation_Technique\r\n{\r\n meta:\r\n author = \"Elastic Security, Lars Wallenborn (@larsborn)\"\r\n description = \"Detects obfuscation technique used by Mozi botnet.\"\r\n strings:\r\n $a = { 55 50 58 21\r\n [4]\r\n 00 00 00 00\r\n 00 00 00 00\r\n 00 00 00 00 }\r\n condition:\r\n all of them\r\n}\r\nCode block 16 - YARA signature detecting Mozi obfuscation\r\n55 50 58 21 - identifies the UPX magic bytes\r\n[4] - offset by 4 bytes, the l_lsize, l_version \u0026 l_format\r\n00 00 00 00 - identifies the program header ID\r\n00 00 00 00 - identifies the zero’d out p_filesize\r\n00 00 00 00 - identifies the zero’d out p_blocksize\r\ncondition - requires that all of the above strings exist for a positive YARA signature match\r\nThe above YARA signature can be used to identify ELF files that are packed with UPX and have the header ID,\r\np_filesize, and p_blocksize elements zero’d out. This can go a long way in identifying obfuscation techniques in\r\naddition to Mozi samples. In our testing, we used this YARA signature with a 94.6% efficiency for detecting Mozi\r\nsamples.\r\nhttps://www.elastic.co/blog/collecting-and-operationalizing-threat-data-from-the-mozi-botnet\r\nPage 14 of 15\n\nSummary\r\nThe Mozi botnet has been observed targeting vulnerable Internet of Things (IoT) devices to launch seemingly\r\nnon-targeted campaigns that can take advantage of the force multiplication provided by a botnet. Mozi has been in\r\noperation since at least December 2019.\r\nWe covered techniques to collect, ingest, and analyze samples from the Mozi botnet. These methodologies can\r\nalso be leveraged to enhance and enable analytical processes for other data samples.\r\nAdditional resources\r\nBlog artifacts and scripts, Elastic: https://github.com/elastic/examples/tree/master/blog/mozin-about\r\nThreatFox Indicator of Compromise Database, Abuse.ch: https://threatfox.abuse.ch/browse\r\nUPX Anti-Unpacking Techniques in IoT Malware, CUJOAI: https://cujo.com/upx-anti-unpacking-techniques-in-iot-malware\r\nCorrupted UPX Packed ELF Repair, vcodispot.com: https://vcodispot.com/corrupted-upx-packed-elf-repair\r\nUPX PACKED ELF BINARIES OF THE PEER-TO-PEER BOTNET FAMILY MOZI, Lars Wallenborn:\r\nhttps://blag.nullteilerfrei.de/2019/12/26/upx-packed-elf-binaries-of-the-peer-to-peer-botnet-family-mozi\r\nMozi, Another Botnet Using DHT, 360 Netlab: https://blog.netlab.360.com/mozi-another-botnet-using-dht\r\nMozi Botnet Accounts for Majority of IoT Traffic, Tara Seals: https://threatpost.com/mozi-botnet-majority-iot-traffic/159337\r\nNew Mozi P2P Botnet Takes Over Netgear, D-Link, Huawei Routers, Sergiu Gatlan:\r\nhttps://www.bleepingcomputer.com/news/security/new-mozi-p2p-botnet-takes-over-netgear-d-link-huawei-routers\r\nKibana Maps, Elastic: https://www.elastic.co/guide/en/kibana/current/maps.html\r\nKibana Lens, Elastic: https://www.elastic.co/guide/en/kibana/current/lens.html\r\nSource: https://www.elastic.co/blog/collecting-and-operationalizing-threat-data-from-the-mozi-botnet\r\nhttps://www.elastic.co/blog/collecting-and-operationalizing-threat-data-from-the-mozi-botnet\r\nPage 15 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.elastic.co/blog/collecting-and-operationalizing-threat-data-from-the-mozi-botnet"
	],
	"report_names": [
		"collecting-and-operationalizing-threat-data-from-the-mozi-botnet"
	],
	"threat_actors": [
		{
			"id": "2864e40a-f233-4618-ac61-b03760a41cbb",
			"created_at": "2023-12-01T02:02:34.272108Z",
			"updated_at": "2026-04-10T02:00:04.97558Z",
			"deleted_at": null,
			"main_name": "WildCard",
			"aliases": [],
			"source_name": "ETDA:WildCard",
			"tools": [
				"RustDown",
				"SysJoker"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "256a6a2d-e8a2-4497-b399-628a7fad4b3e",
			"created_at": "2023-11-30T02:00:07.299845Z",
			"updated_at": "2026-04-10T02:00:03.484788Z",
			"deleted_at": null,
			"main_name": "WildCard",
			"aliases": [],
			"source_name": "MISPGALAXY:WildCard",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434528,
	"ts_updated_at": 1775826774,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/6200d6f9c60eb36c25bd7cfb6fe05df450edd2dd.pdf",
		"text": "https://archive.orkl.eu/6200d6f9c60eb36c25bd7cfb6fe05df450edd2dd.txt",
		"img": "https://archive.orkl.eu/6200d6f9c60eb36c25bd7cfb6fe05df450edd2dd.jpg"
	}
}