Collecting and operationalizing threat data from the Mozi botnet

Detecting and preventing malicious activity such as botnet attacks is a critical area of focus for threat intel analysts, security operators, and threat hunters. Taking up the Mozi botnet as a case study, this blog post demonstrates how to use open source tools, analytical processes, and the Elastic Stack to perform analysis and enrichment of collected data irrespective of the campaign. This will allow you to take the lessons and processes outlined below to your organization and apply them to your specific use cases. The Mozi botnet has been leveraging vulnerable Internet of Things (IoT) devices to launch campaigns that can take advantage of the force multiplication provided by a botnet (Distributed Denial of Service (DDoS), email spam, brute-force, password spraying, etc.). Mozi was first reported by the research team at 360Netlab in December 2019 and has continued to make up a large portion of IoT network activity across the Internet-at-large.  As reported by 360Netlab, the botnet spreads via the use of weak and default remote access passwords for targeted devices as well as through multiple public exploits. The Mozi botnet communicates using a Distributed Hash Table (DHT) which records the contact information for other nodes in the botnet. This is the same serverless mechanism used by file sharing peer-to-peer (P2P) clients. Once the malware has accessed a vulnerable device, it executes the payload and subsequently joins the Mozi P2P network. The newly infected device listens for commands from controller nodes and also attempts to infect other vulnerable devices. Mozi targets multiple IoT devices and systems, mainly focused on Small Office Home Office (SOHO) networking devices, Internet-connected audio visual systems, and theoretically any 32-bit ARM device. CollectionWhen performing data analysis, the more data that you have, the better. Analysis of malware campaigns are no different. With a paid subscription to VirusTotal, you can collect huge amounts of data for analysis, but we wanted an approach for independent researchers or smaller organizations that may not have this premium service. To do that, we decided to keep to our roots at Elastic and leverage open source datasets to avoid a paywall that could prevent others from using our processes. To begin, we started with a handful of Mozi samples collected from ThreatFox. ThreatFox is an open source platform from Abuse.ch with the goal of sharing malware indicators with the security research community. Using cURL, we queried the ThreatFox API for the Mozi tag. This returned back JSON documents with information about the malware sample, based on the tagged information. curl -X POST https://threatfox-api.abuse.ch/api/v1/ -d '{ "query": "taginfo", "tag": "Mozi", "limit": 1 }' Code block 1 - cURL request to ThreatFox API -X POST - change the cURL HTTP method from GET (default) to POST as we’re going to be sending data to the ThreatFox API https://threatfox-api.abuse.ch/api/v1/ - this is the ThreatFox API endpoint -d - this is denoting that we’re going to be sending data query: taginfo - the type of query that we’re making, taginfo in our example tag: Mozi - the tag that we’ll be searching for, “Mozi” in our example limit: 1 - the number of results to return, 1 result in our example, but you can return up to 1000 results This returned the following information: { "query_status": "ok", "data": [ { "id": "115772", "ioc": "nnn.nnn.nnn.nnn:53822", "threat_type": "botnet_cc", "threat_type_desc": "Indicator that identifies a botnet command&control server (C&C)", "ioc_type": "ip:port", "ioc_type_desc": "ip:port combination that is used for botnet Command&control (C&C)", "malware": "elf.mozi", "malware_printable": "Mozi", "malware_alias": null, "malware_malpedia": "https:\/\/malpedia.caad.fkie.fraunhofer.de\/details\/elf.mozi", "confidence_level": 75, "first_seen": "2021-06-15 08:22:52 UTC", "last_seen": null, "reference": "https:\/\/bazaar.abuse.ch\/sample\/832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b\/", "reporter": "abuse_ch", "tags": [ "Mozi" ] } ] Code block 2 - Response from ThreatFox APINow that we have the file hashes of several samples, we can download the samples using the Malware Bazaar API. Malware Bazaar is another open source platform provided by Abuse.ch. While ThreatFox is used to share contextual information about indicators, Malware Bazaar allows for the actual collection of malware samples (among other capabilities).  Just like with ThreatFox, we’ll use cURL to interact with the Malware Bazaar API, but this time to download the actual malware samples. Of note, the Malware Bazaar API can be used to search for samples using a tag (“Mozi”, in our example), similar to how we used the ThreatFox API. The difference is that the ThreatFox API returns network indicators that we’ll use later on for data enrichment. curl -X POST https://mb-api.abuse.ch/api/v1 -d 'query=get_file&sha256_hash=832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b' -o 832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b.raw Code block 3 - cURL request to Malware Bazaar API

-X POST - change the cURL HTTP method from GET (default) to POST as we’re going to be sending data to the Malware Bazaar API
https://mb-api.abuse.ch/api/v1 - this is the Malware Bazaar API endpoint
-d - this is denoting that we’re going to be sending data
query: get_file - the type of query that we’re making, get_file in our example
sha256_hash - the SHA256 hash we’re going to be collecting, “832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b” in our example
-o - the file name we’re going to save the binary as

This will save a file locally named 832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b.raw. We want to make a raw file that we’ll not modify so that we always have an original sample for archival purposes. This downloads the file as a Zip archive. The passphrase to extract the archive is infected. This will create a local file named 832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b.elf. Going forward, we’ll use a shorter name for this file, truncated-87d3b.elf, for readability. UnpackingNow that we have a few samples to work with we can look at ripping out strings for further analysis. Once in our analysis VM we took a stab at running Sysinternals Strings over our sample: $ strings truncated-87d3b.elf ELF *UPX! ELF $Bw (GT ... Code block 3 - Strings output from the packed Mozi sampleRight away we see that we have a UPX packed ELF binary from the “ELF” and “UPX!” text. UPX is a compression tool for executable files, commonly known as “packing”.  So the next logical step is to decompress the ELF file with the UPX program. To do that, we’ll run upx with the -d switch. $ upx -d truncated-87d3b.elf
Ultimate Packer for eXecutables Copyright (C) 1996 - 2020 UPX 3.96w Markus Oberhumer, Laszlo Molnar & John Reiser Jan 23rd 2020 File size Ratio Format Name

273020  Ingest Node Pipelines, then click Create pipeline.

Figure 1 - Creating Ingest Node Pipeline for ThreatFox dataNext, we’ll give our pipeline a name, optionally a version, and a description.  From this view you can manually add processors and configure them to your liking. To give you a head start, we've provided the ThreatFox pipeline definition here you can paste in.  Click Import processors and paste the contents of this pipeline definition: pipeline.json.  When you click Load and overwrite, you'll have each processor listed there as we've configured it. From here you can tweak it to your needs, or just scroll down and click Create pipeline.

https://www.elastic.co/blog/collecting-and-operationalizing-threat-data-from-the-mozi-botnet