{
	"id": "dd176a1a-3582-4c06-9a6a-6acc460d1aca",
	"created_at": "2026-04-06T02:13:10.395106Z",
	"updated_at": "2026-04-10T13:13:00.366188Z",
	"deleted_at": null,
	"sha1_hash": "ef560d6a22e2273a69105d2f3d6f50ba91013025",
	"title": "Torii botnet - Not another Mirai variant",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 704874,
	"plain_text": "Torii botnet - Not another Mirai variant\r\nBy Threat Intelligence Team 27 Sep 2018\r\nArchived: 2026-04-06 01:32:53 UTC\r\nNew, more sophisticated IoT botnet targets a wide range of devices\r\nwritten by Jakub Kroustek, Vladislav Iliushin, Anna Shirokova, Jan Neduchal and Martin Hron\r\nDisclaimer: Analysis of the server content and samples was done on Thursday, September 20th. Follow the Avast Blog for\r\nfurther updates. \r\nIntroduction\r\n2018 has been a year where the Mirai and QBot variants just keep coming. Any script kiddie now can use the Mirai source\r\ncode, make a few changes, give it a new Japanese-sounding name, and then release it as a new botnet.\r\nOver the past week, we have been observing a new malware strain, which we call Torii, that differs from Mirai and other\r\nbotnets we know of, particularly in the advanced techniques it uses.\r\nUnlike the aforementioned IoT botnets, this one tries to be more stealthy and persistent once the device is compromised, and\r\nit does not (yet) do the usual stuff a botnet does like DDOS, attacking all the devices connected to the internet, or, of course,\r\nmining cryptocurrencies.\r\nInstead, it comes with a quite rich set of features for exfiltration of (sensitive) information, modular architecture capable of\r\nfetching and executing other commands and executables and all of it via multiple layers of encrypted communication.\r\nFurthermore, Torii can infect a wide range of devices and it provides support for a wide range of target architectures,\r\nincluding MIPS, ARM, x86, x64, PowerPC, SuperH, and others. Definitely, one of the largest sets we’ve seen so far.\r\nAs we’ve been digging into this strain, we’ve found indications that this operation has been running since December 2017,\r\nmaybe even longer.\r\nWe would like to give credit to @VessOnSecurity, who actually tweeted about a sample of this strain hitting his telnet\r\nhoneypot last week.\r\nhttps://blog.avast.com/new-torii-botnet-threat-research\r\nPage 1 of 14\n\nAccording to this security researcher, telnet attacks have been coming to his honeypot from Tor exit nodes, so we decided to\r\nname this botnet strain “Torii”.\r\nIn this post, we will describe what we know about this strain so far, how it is spreading, what are its stages, and we will\r\ndepict some of its features.\r\nThe analysis is still ongoing and further findings will be included in blog post updates.\r\nNow, let’s start with the infection vector.\r\nAnalysis of the initial shell script\r\nThe infection chain starts with a telnet attack on the weak credentials of targeted devices followed by execution of an initial\r\nshell script. This script looks quite different from typical scripts that IoT malware uses in that it is far more sophisticated.\r\nThe script initially tries to discover the architecture of the targeted device and then attempts to download the appropriate\r\npayload for that device.The list of architectures that Torii supports is quite impressive: including devices based on x86_64,\r\nx86, ARM, MIPS, Motorola 68k, SuperH, PPC - with various bit-width and endianness. This allows Torii to infect a wide\r\nrange of devices running on these very common architectures.\r\nhttps://blog.avast.com/new-torii-botnet-threat-research\r\nPage 2 of 14\n\nThe malware uses several commands to download binary payloads by executing the following commands: \"wget\", \"ftpget\",\r\n\"ftp\", \"busybox wget\", or \"busybox ftpget\". It uses multiple commands to maximize the likelihood that it can deliver the\r\npayload.\r\nhttps://blog.avast.com/new-torii-botnet-threat-research\r\nPage 3 of 14\n\nIf  the binaries cannot be downloaded via the HTTP protocol with “wget”  or “busybox wget” commands, it will use FTP.\r\n When the FTP protocol is being used, it requires authentication. Credentials are nicely provided in the script:\r\nUsername:     u=\"\u003credacted\u003e\"\r\nPassword:      p=\"\u003credacted\u003e\"\r\nPort for FTP:  po=404\r\nIP of the FTP/HTTP server: 104.237.218.85 (This IP is still alive at the time of writing this post.)\r\nhttps://blog.avast.com/new-torii-botnet-threat-research\r\nPage 4 of 14\n\nBy connecting to the FTP server, there is quite a lot going on:\r\nClick to view full file\r\nAmong other things, the server contains logs from the NGINX and FTP servers, payload samples, a bash script that directs\r\nthe infected devices to this very machine where the malware is hosted, and more. We’ll discuss what we found in these logs\r\nat the end of this post, but first let’s take a look at all the samples that are hosted there.\r\nAnalysis of the 1st stage payload (dropper)\r\nOnce the script determines which architecture the target device it is running on, it downloads and executes the appropriate\r\nbinary from the server. All of these binary files are in the ELF file format. While analyzing these payloads, we found that\r\nthey are all very similar and are “just” droppers of the second stage payload. What is notable is that they use several methods\r\nto make the second stage persistent on the target device. Let’s look deeper into the details below.\r\nhttps://blog.avast.com/new-torii-botnet-threat-research\r\nPage 5 of 14\n\nFor our description, we’ll focus on the x86 sample with the SHA256 hash:\r\n0ff70de135cee727eca5780621ba05a6ce215ad4c759b3a096dd5ece1ac3d378.\r\nString Obfuscation\r\nFirst we tried to de-obfuscate the sample, so we delved into some of the text strings to look for clues on how the malware\r\nworks. The vast majority of text strings in the 1st and 2nd stage are encrypted by a simple XOR-based encryption and they\r\nare decrypted during runtime when a particular string is needed. You can use the following IDA Python script for\r\ndecryption:\r\nsea = ScreenEA()\r\nmax_size = 0xFF\r\nfor i in range(0x00, max_size):\r\n   b = Byte(sea+i)\r\n   decoded_byte = (b ^ (0xFEBCEADE \u003e\u003e 8 * (i % 4))) \u0026 0xFF;\r\n   PatchByte(sea+i,decoded_byte)\r\n   if b == 0x00 or decoded_byte == 0x00:\r\n       break\r\ne.g. F1 9A CE 91  BD C5 CF 9B B2 8C 93 9B A6 8F BC 00 → ‘/proc/self/exe’\r\nInstall 2nd Stage ELF File\r\nThe core functionality of the first stage is to install another ELF file, the second stage executable, which is contained within\r\nthe first ELF file.\r\nThe file is installed into a pseudo-random location that is generated by combining a predefined location from a fixed list:\r\n\"/usr/bin\"\r\n\"/usr/lib\"\r\n$HOME_PATH\r\n\"/system/xbin\"\r\n\"/dev\"\r\n$LOCATION_OF_1ST_STAGE\r\n\"/var/tmp\"\r\n\"/tmp\"\r\nand a filename from another list:\r\n“setenvi“\r\n“bridged“\r\n“swapper“\r\n“natd“\r\n“lftpd“\r\n“initenv“\r\n“unix_upstart“\r\n“mntctrd“\r\netc.\r\nPutting these two items together creates the destination file path.\r\nMake the 2nd Stage Persistent\r\nhttps://blog.avast.com/new-torii-botnet-threat-research\r\nPage 6 of 14\n\nAfterwards, the dropper makes sure that the second stage payload is executed and that it will remain persistent. It is unique\r\nin that it is remarkably thorough in how it achieves persistence. It uses at least six methods to make sure the file remains on\r\nthe device and always runs. And, not just one method is executed – it runs all of them.\r\n1. Automatic execution via injected code into ~\\.bashrc\r\n2. Automatic execution via “@reboot” clause in crontab\r\n3. Automatic execution as a “System Daemon” service via systemd\r\n4. Automatic execution via /etc/init and PATH. Once again, it calls itself \"System Daemon\"\r\n5. Automatic execution via modification of the SELinux Policy Management\r\n6. Automatic execution via /etc/inittab\r\nAnd, finally, it executes the dropped inner ELF –  the second stage payload.\r\nAnalysis of the 2nd stage payload (bot)\r\nThe second stage payload is a full-fledged bot capable of executing commands from its master (CnC).  It also contains other\r\nfeatures such as simple anti-debugging techniques, data exfiltration, multi-level encryption of communication, etc.\r\nFurthermore, many functions found in the second stage are the same as in the first, making it  highly likely they are both\r\ncreated by the same author(s).\r\nThe code inside of the first stage payload is almost identical in all the versions. This is however not true in the case of the\r\nsecond stage where we find differences among the binaries for various hardware architectures. To describe the core\r\nfunctionality that can be found in most of the versions, we will once again take a look on x86 code found in the sample with\r\nSHA256 hash:  5c74bd2e20ef97e39e3c027f130c62f0cfdd6f6e008250b3c5c35ff9647f2abe.\r\nAnti-Analysis Methods\r\nThe anti-analysis methods in this malware are not as advanced as we are accustomed to seeing in Windows or mobile\r\nmalware, but they are improving.\r\nIt uses the simple anti-analysis method of a 60 seconds sleep() after execution, which probably tries to circumvent\r\nsimple sandboxes.\r\nFurthermore, it tries to randomize the process name via prctl(PR_SET_NAME) call to something like “\\[[a-z]\r\n{12,17}\\]” (regular expression) in order to avoid detection of blacklisted process names.\r\nFinally, the authors are trying to make the analysis harder by stripping the symbols from executables. When we first\r\ndownloaded the samples from the aforementioned server 104.237.218.85, they all contained symbols, which made\r\ntheir analysis easier. It is interesting to note that a few days later these files were replaced by their stripped versions.\r\nNo other differences were found between these two versions, leading us to believe that the authors are taking\r\ncontinual action to further protect their executables against analysis.\r\nCnC Servers\r\nAs we already said, this component is a bot that communicates with a master CnC server. The addresses of the CnCs are\r\nonce again encrypted by the aforementioned XOR-based cipher. It seems that each Torii version contains 3 CnC addresses.\r\nThe campaign that is currently running tries to get commands from CnC servers running at:\r\ntop.haletteompson.com\r\ncloud.tillywirtz.com\r\ntrade.andrewabendroth.com\r\nIt tries to communicate with the first domain from the list and moves to the next one if it fails. In the case of failure, it also\r\ntries to resolve the domain name via Google DNS 8.8.8.8.\r\nResolving CnC domain name\r\nhttps://blog.avast.com/new-torii-botnet-threat-research\r\nPage 7 of 14\n\nThese three domain names have resolved to IP 66.85.157.90 since September 15, 2018. Some other domains hosted on the\r\nsame IP are also quite suspicious:\r\ncloud.tillywirtz.com\r\ndushe.cc\r\neditor.akotae.com\r\npress.eonhep.com\r\nweb.reeglais.com\r\npsoriasiafreelife.win\r\nq3x1u.psoriasiafreelife.win\r\nserver.blurayburnersoftware.com\r\ntop.haletteompson.com\r\ntrade.andrewabendroth.com\r\nwww.bubo.ccwww.dushe.cc\r\nThat so many strange looking domains are hosted at one IP address raises concern. Furthermore, the CnC domain names\r\nresolved to a different IP address (184.95.48.12) before that.\r\n(History of resolving DNS names hardcoded in the sample)\r\nSome more digging turned up another set of ELF samples belonging to Torii with three different CnC addresses:\r\npress.eonhep.com\r\neditor.akotae.com\r\nweb.reeglais.com\r\nThey all resolved to the same IP (184.95.48.12) in the past and, for example “press.eonhep.com” was using this IP since\r\nDecember 8, 2017. Therefore, we think that this strain has been in existence since at least December 2017 and quite\r\npossibly longer.\r\nCnC Communication\r\nThe second stage communicates with these CnC servers via TCP port 443 as well as further encryption layers. It is\r\ninteresting to note that it uses port 443 as a deception, as it doesn’t communicate using TLS but takes advantage of common\r\nuse of this port for HTTPS traffic. Each message (including replies) forms a structure we call a “message envelope” and\r\neach envelope is AES-128 encrypted and there is a MD5 checksum of the content to ensure it hasn’t been modified or\r\ncorrupted. Furthermore, each envelope contains a stream of messages where each message is encrypted by a simple XOR-based encryption, which is different than the one used to obfuscate the strings. It isn’t as strong as it looks as the decryption\r\nkeys are included in the communication.\r\nAlgorithm used for encryption of CnC messages\r\nhttps://blog.avast.com/new-torii-botnet-threat-research\r\nPage 8 of 14\n\nTorii also exfiltrates the following information while connecting to a CnC server:\r\nHostname\r\nProcess ID\r\nPath to second stage executable\r\nAll MAC addresses found in /sys/class/net/%interface_name%/address + its MD5 hash - this forms some kind of\r\nunique victim ID, allowing the bad actor to fingerprint and catalog devices more easily. It is also stored in local files\r\nwith strange names such as\r\nGfmVZfJKWnCheFxEVAzvAMiZZGjfFoumtiJtntFkiJTmoSsLtSIvEtufBgkgugUOogJebQojzhYNaqyVKJqRcnWDtJlNPIdeOMKP\r\nVFgKRiHQQcLhUZfvuRUqPKCtcrjmhtKcYQorAWhqAuZuWfQqymGnWiiZAsljnyNlocePAOHaKHvGoNXMZfByomZqEMbtkO\r\nXAgHrWKSKyJktzLCMcEqYqfoeUBtgodeOjLgfvArTLeOkPSyRxqrpvFWRhRYvVcLeNtMKTdgFhwrypsRoIiDeObVxTTuOVfS\r\netc.\r\nDetails found by uname() call, including sysname, version, release, and machine.\r\nOutputs of the following commands designed to gain yet more information on the target device:\r\nid 2\u003e/dev/null\r\nuname -a 2\u003e/dev/null\r\nwhoami 2\u003e/dev/null\r\ncat /proc/cpuinfo 2\u003e/dev/null\r\ncat /proc/meminfo 2\u003e/dev/null\r\ncat /proc/version 2\u003e/dev/null\r\ncat /proc/partitions 2\u003e/dev/null\r\ncat /etc/*release /etc/issue  2\u003e/dev/null\r\nCnC Commands\r\nWhile analyzing the code, we’ve found that the bot component is communicating with the CnC with active polling in an\r\nendless loop, always asking its CnC whether there are any commands to execute. After receiving a command, it replies with\r\nthe results of the command execution. Each message envelope has a value specifying which type of command it brings. The\r\nsame value is used for reply. We have uncovered the following command types:\r\n0xBB32 - Store a file from CnC to a local drive:\r\nReceive:\r\n1. Filepath where to store content from CnC\r\n2. Content\r\n3. MD5 checksum of content\r\nReply:\r\n1. File path where the file was stored\r\n2. Error code\r\n0xA16D - Receive value of timeout to be used for CnC polling:\r\nReceive:\r\n1. DWORD with number of minutes to sleep between CnC contacts\r\nReply:\r\n1. Message with code 66\r\n0xAE35 - Execute a given command in a desired shell interpreter and send outputs back to CnC:\r\nReceive:\r\n1. Command to execute in shell (sh -c \"exec COMMAND\")\r\n2. WORD with execution timeout in seconds (max 60 seconds)\r\n3. String with a path to shell interpreter (optional)\r\nReply:\r\n1. String with outputs (stdout + stderr) of command execution\r\nhttps://blog.avast.com/new-torii-botnet-threat-research\r\nPage 9 of 14\n\n0xA863 - Store a file from CnC to a given path, change its flags to “rwxr-xr-x” to make it executable and then\r\nexecute it:\r\nReceive:\r\n1. File path where to store content from CnC\r\n2. Content\r\n3. MD5 checksum of content\r\nReply:\r\n1. File path where the file was stored\r\n2. Return code from execution of that file\r\n0xE04B - Check that the given file exists on a local system and return its size:\r\nReceive:\r\n1. Filepath to check\r\nReply:\r\n1. File path\r\n2. File size\r\n0xF28C - Read N bytes from offset O of selected file F and send them to CnC:\r\nReceive:\r\n1. File path to file (F) to read from\r\n2. QWORD offset (O) where to start reading\r\n3. DWORD number (N) of bytes to read\r\nReply:\r\n1. File content\r\n2. Offset\r\n3. Size of bytes read\r\n4. MD5 checksum of read content\r\n0xDEB7 - Delete a specified file\r\nReceive:\r\n1. Name of a file to delete\r\nReply:\r\n1. Error code\r\n0xC221 - Download a file from the given URL\r\nReceive:\r\n1. Path where to a store file\r\n2. URL\r\nReply:\r\n1. File path\r\n2. URL\r\n0xF76F - Get address of a new CnC server and start communication with it.\r\nReceive:\r\n1. ?\r\n2. New domain name\r\n3. New port\r\n4. ?\r\nReply:\r\n1. Repeat the received information\r\n0x5B77, 0x73BF, 0xEBF0, and probably other codes - Some kind of communication to ping or get a heartbeat\r\non the target device to ensure the communication partner that the communication channel is working):\r\nReceive:\r\n1. Everything received is ignored\r\nReply:\r\n1. Repeat the received information\r\nAnalysis of the sm_packed_agent\r\nhttps://blog.avast.com/new-torii-botnet-threat-research\r\nPage 10 of 14\n\nWhile we were investigating the server, we found another interesting binary we managed to get from the FTP server that is\r\ncalled “sm_packed_agent”. We don’t have any evidence that is has been used on the server, but its versatility suggests that it\r\ncould be used to send any remote command desired to the target device. It contains a GO-written application packed using\r\nUPX when unpacked, it has a few interesting strings that suggests it has server-like capabilities:\r\nUnderneath, it uses the following 3rd party libraries:Code Reuse\r\nhttps://github.com/shirou/gopsutil/host \r\nhttps://github.com/shirou/gopsutil/cpu\r\nhttps://github.com/shirou/gopsutil/mem\r\nhttps://github.com/shirou/gopsutil/net\r\nPossible name of source code:\r\n/go/src/Monitor_GO/agent/agent.go\r\n/go/src/Monitor_GO/sm_agent.go\r\nSome of these libraries are abusing a BSD licence, which requires redistribution of copyright notice. Apparently Torii’s\r\nauthors don’t care about copyright infringement.\r\nFunctionality\r\nThe functionality of the sm_agent is as follows:\r\nTakes one parameter on cmdline -p with port number\r\nInitializes crypto, loads TLS and keys + cert\r\nCreates server and listening for TLS connection\r\nAwaits commands encoded in BSON format\r\nCommand handler inside knows these commands:\r\n1: Monitor_GO_agent__Agent_GetSystemInfo\r\n2: Monitor_GO_agent__Agent_GetPerformanceMetrics\r\n7: Monitor_GO_agent__Agent_ExecCmdWithTimeout\r\nthis command seems to be able to run any arbitrary OS command read from BSON payload.\r\nTLS encryption, certificates and keys:\r\nAgent uses ChaCha20-Poly1305 stream cipher for TLS\r\nKeys and certs in the same directory\r\nSelf signed certificate of authority ca.crt with name Mayola Mednick\r\nclient.crt issued by ca.crt for Dorothea Gladding\r\nhttps://blog.avast.com/new-torii-botnet-threat-research\r\nPage 11 of 14\n\nserver.crt + server.key issued by ca.crt for Graham Tudisco\r\nCertificates are self-signed and obviously using fake names.\r\nStart-agent.sh\r\nThis  script is to kill any previous instances of start sm_packed_agent and run it on TCP port 45709 and re-run it again in\r\ncase it fails.\r\nA script which runs and keeps\r\nrunning sm_packed_agent\r\nIt is not yet known how Torii authors are using this service, but it is incredibly versatile and could be used to run any\r\ncommand on the device. And because this application is written in GO, it can be easily recompiled to run on virtually any\r\narchitecture. Taking into account that this file is running on a  malware distribution machine, it is quite possible that it is a\r\nbackdoor or even a service to orchestrate multiple machines.\r\nAnalysis of Logs From the Server 104.237.218.85\r\nFinally, we took a look at the logs we found for both the Nginx server and the FTP server. Such access log can help us\r\nunderstand how many clients actually were infected by Torii or tried to download it.\r\nAs we write this blog, Torii authors have already disabled FTP and Nginx logging (more on that below), but looking at the\r\nlogs that are available, we can generate some simple statistics.\r\nA total of 206 unique IPs connected to the server on September 7th, 8th, 19th, and 20th according to the logs on the server.\r\nAccess-2018-09-07.log - 54 unique IPs\r\nAccess-2018-09-08.log - 20\r\nAccess-2018-09-19.log - 189\r\nAccess-2018-09-20.log - 10\r\nIt looks like one IP 38.124.61.111 connected to the server 1 056 393 times!\r\nBy looking into the logs, it seems that someone actually ran DirBuster-1.0-RC1, trying to figure out what is going on. Brute\r\nforce DirBuster is used to guess directories/filenames on the web server and generates a large number of requests. It is quite\r\nunfortunate if this scan originated from a researcher as there are more elegant approaches in the case of a sophisticated\r\nmalware like Torii.\r\nBy scanning the ports of IP 38.124.61.111, we can see that there are a few ports open:\r\nhttps://blog.avast.com/new-torii-botnet-threat-research\r\nPage 12 of 14\n\nOn port 27655, there is an SSH banner which states:\r\n“SSH-2.0-OpenSSH_7.4p1 Raspbian-10+deb9u3” It looks like this box is running Raspbian.  If you are behind this, write\r\nus.\r\nOther logs that are available to us are FTP server logs.\r\nThere are a few clients that connected and downloaded some files that are not on the FTP server anymore:\r\nSat Sep  8 08:31:24 2018 1 128.199.109.115 6 /media/veracrypt1/nginx/md/zing.txt b _ o r md ftp 0 * c\r\nAccording to logs we were able to analyze, a total of 592 unique clients were downloading files from this server over a\r\nperiod of a few days. It’s important to remember that once the target device receives the payload, it stops connecting to the\r\ndownload server and connects to the CnC server. Therefore, we are likely seeing a snapshot of new devices that were\r\nrecruited into this botnet over the period of time for which we have log files.\r\nAdditionally, there are 8 clients that were using both the HTTP server and the FTP server, which could be the case if\r\ndownloading using HTTP failed for some reason, or if Torii authors were testing functionality of the bash script or a server\r\nset up\r\nWe cannot speculate about what we do not have evidence for, but this server could be just one of a number of servers\r\ninfecting new target devices, and only further investigation will reveal the true scope of this botnet. Given the level of\r\nsophistication of the malware we researched, it would seem likely that it is designed to map and control a large number of\r\ndiverse devices.\r\nConclusion\r\nEven though our investigation is continuing, it is clear that Torii is an example of the evolution of IoT malware, and that its\r\nsophistication is a level above anything we have seen before. Once it infects a device, not only does it send quite a lot of\r\ninformation about the machine it resides on to the CnC, but  by communicating with the CnC, it allows Torii authors to\r\nexecute any code or deliver any payload to the infected device. This suggests that Torii could become a modular platform for\r\nfuture use. Also, because the payload itself is not scanning for other potential targets, it is quite stealthy on the network layer.\r\nStay tuned for the follow ups.\r\nIoC\r\nCnC\r\ntop.haletteompson.com\r\nсloud.tillywirtz.com\r\ntrade.andrewabendroth.com\r\npress.eonhep.com\r\neditor.akotae.com\r\nweb.reeglais.com\r\nhttps://blog.avast.com/new-torii-botnet-threat-research\r\nPage 13 of 14\n\nIP\r\n184.95.48.12\r\n104.237.218.82\r\n104.237.218.85\r\n66.85.157.90\r\nSHA256\r\n[click here to view SHA256 hashes]\r\nAvast is a global leader in cybersecurity, protecting hundreds of millions of users around the world. Protect all of your\r\ndevices with award-winning virus protection. Safeguard your privacy and encrypt your online connection with SecureLine\r\nVPN. \r\nLearn more about products that protect your digital life at avast.com. And get all the latest news on today's cyberthreats and\r\nhow to beat them at blog.avast.com.\r\nSource: https://blog.avast.com/new-torii-botnet-threat-research\r\nhttps://blog.avast.com/new-torii-botnet-threat-research\r\nPage 14 of 14\n\n  https://blog.avast.com/new-torii-botnet-threat-research   \nThe malware uses several commands to download binary payloads by executing the following commands: \"wget\", \"ftpget\",\n\"ftp\", \"busybox wget\", or \"busybox ftpget\". It uses multiple commands to maximize the likelihood that it can deliver the\npayload.     \n   Page 3 of 14",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://blog.avast.com/new-torii-botnet-threat-research"
	],
	"report_names": [
		"new-torii-botnet-threat-research"
	],
	"threat_actors": [],
	"ts_created_at": 1775441590,
	"ts_updated_at": 1775826780,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ef560d6a22e2273a69105d2f3d6f50ba91013025.pdf",
		"text": "https://archive.orkl.eu/ef560d6a22e2273a69105d2f3d6f50ba91013025.txt",
		"img": "https://archive.orkl.eu/ef560d6a22e2273a69105d2f3d6f50ba91013025.jpg"
	}
}