{
	"id": "599f09a4-b179-495c-ba46-cd15b21aee81",
	"created_at": "2026-04-06T00:18:35.267259Z",
	"updated_at": "2026-04-10T13:13:04.495754Z",
	"deleted_at": null,
	"sha1_hash": "d106b11e320d098a4a2bedef1b1b21dcb9a3deda",
	"title": "Versatile DDoS Trojan for Linux",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1250316,
	"plain_text": "Versatile DDoS Trojan for Linux\r\nBy Mikhail Kuzin\r\nPublished: 2014-07-10 · Archived: 2026-04-05 15:47:15 UTC\r\nIn February 2014, an article was published on a popular Russian IT website under a curious title – Studying the\r\nBillGates Linux Botnet. It described a Trojan with sufficiently versatile DDoS functionality. The capability that\r\nwe found the most interesting was the Trojan’s ability to conduct DNS Amplification-type attacks. In addition, it\r\nfollowed from the article that the Trojan had a sophisticated modular structure, something we had not seen in the\r\nworld of Linux malware before.\r\nThe article also provided a link for downloading all of the Trojan’s files (taken directly from an infected machine)\r\n– which is what we did.\r\nThe archive that we downloaded contained the following files, which, according to the author of the article, were\r\nall modules of the same Trojan:\r\natddd;\r\ncupsdd;\r\ncupsddh;\r\nksapdd;\r\nkysapdd;\r\nskysapdd;\r\nxfsdxd.\r\nThe files cupsdd and cupsddh are detected by Kaspersky Lab products as Backdoor.Linux.Ganiw.a; atddd and the\r\nremaining files are detected as Backdoor.Linux.Mayday.f.\r\nThe archive with the files also contained a configuration file for cron – the Linux task scheduler. In this case, the\r\nutility is used by the Trojan as a means of getting a foothold in the system. The Trojan uses cron to perform the\r\nfollowing tasks:\r\n1. 1 Once a minute – terminate the processes of all applications that can interfere with its operation:\r\n.IptabLes, nfsd4, profild.key, nfsd, DDosl, lengchao32, b26, codelove, node24\r\n2. 2 Approximately once in ninety minutes – terminate all of its processes: kysapd, atdd, skysapd, xfsdx,\r\nksapd\r\n3. 3 Approximately once in two hours – download all of its components to the /etc folder from\r\nhttp://www.dgnfd564sdf.com:8080/[module_name] (module_name = name of the Trojan’s module, e.g.,\r\ncupsdd), after deleting these files from the /etc folder\r\n4. 4 Once in ninety minutes – relaunch all of its modules\r\n5. 5 Every minute – purge system logs and bash command history and execute chmod 7777 [module_name]\r\nhttps://securelist.com/versatile-ddos-trojan-for-linux/64361/\r\nPage 1 of 14\n\nDuring subsequent analysis of the files, we did not find any code responsible for saving the config file for cron.\r\nMost likely, the file was manually downloaded to the victim machine by a cybercriminal after gaining remote\r\naccess to the system.\r\nBackdoor.Linux.Mayday.f (atddd)\r\nThe file atddd is a backdoor designed to conduct various types of DDoS attacks against the servers specified. As\r\nmentioned above, Kaspersky Lab products detect it as Backdoor.Linux.Mayday.f. The files kysapdd, skysapdd,\r\nxfsdxd, ksapdd are almost exact copies of atddd – with one exception, which is discussed later in the text.\r\nThe backdoor starts its operation by calling the function daemon(1, 0), continuing to run in the background and\r\nredirecting standard input, output and errors to /dev/null\r\nNext, atddd collects relevant information about the system, including:\r\n1. 1 system version (by calling uname())\r\n2. 2 number of CPU cores and their clock rates (taken from /proc/cpuinfo)\r\n3. 3 CPU load (taken from /proc/stat)\r\n4. 4 network load (data for interfaces with the “eth” prefix taken from /proc/net/dev)\r\nThe information listed above is stored in the g_statBase structure.\r\nAfter this, the backdoor decrypts strings defining the C\u0026C server’s IP address and port number. The encryption\r\nalgorithm used is very simple: an encrypted string is taken character-by-character, with 1 added to the ASCII code\r\nof a character if its number is odd and subtracted from it if the character’s number is even. As a result, the string\r\n“3/3-2/4-269-85” yields the IP-адрес “202.103.178.76”, while “2/:82” stands for port number “10991”.\r\nAfter this, atddd reads configuration file fwke.cfg, which is located in the same folder with the malicious program.\r\nInformation from the config file is saved in the g_fakeCfg structure. If the file does not exist, the backdoor\r\nattempts to create it and store the following information in it:\r\n1st line: 0        //flag, if 1 then begin attack, if 0 then terminate attack\r\n2nd line: 127.0.0.1:127.0.0.1        //range of outgoing IP addresses\r\n3rd line: 10000:60000        //outgoing port range for an attack\r\n4th line: an empty line        //domain name in the case of DNS flood (see below)\r\nThis information is subsequently sent to the C\u0026C server and can be updated with a command from the C\u0026C.\r\nhttps://securelist.com/versatile-ddos-trojan-for-linux/64361/\r\nPage 2 of 14\n\nNext, the backdoor creates a new thread, CThreadTaskManager::ProcessMain(), in which commands to begin an\r\nattack and terminate an attack are put into the execution queue. After this, a new thread is created –\r\nCThreadHostStatus::ProcessMain(). In this thread, data on CPU and network load is updated every second and\r\ncan subsequently be sent to the C\u0026C server if requested.\r\nAfter this, 20 threads are created, which read information from the task queue and, depending on the information\r\nread, launch an attack or terminate it. However, some of the threads may not be used in an attack if the relevant\r\nC\u0026C command has a parameter (the number of threads to be used).\r\nThen the malware enters an endless loop of processing messages from the C\u0026C. After a connection with the C\u0026C\r\nis established, information about system version and CPU clock rate, as well as data from the g_fakeCfg structure,\r\nis sent to the C\u0026C every 30 seconds.\r\nIn response, the server should send 4 bytes, the first of which is the serial number of a command – from 1 to 4.\r\nNext, if the command has parameters, the C\u0026C sends another 4 bytes defining the amount of data that will be sent\r\n(i.e., the parameters). Then the parameters themselves are sent; their size should match the number from the\r\nprevious C\u0026C response.\r\nAbout each command in greater detail:\r\n0x01. Command to launch an attack. Parameters define the attack’s type and the number of threads to be\r\nused. The attack type is defined by a byte which can take values from 0x80 to 0x84. This means that 5\r\nattack types are possible:\r\nhttps://securelist.com/versatile-ddos-trojan-for-linux/64361/\r\nPage 3 of 14\n\n0x80 – TCP flood. The destination port number is sent by the C\u0026C in its response as a parameter.\r\nThe source port range is defined in fwke.cfg. Each new request is sent from a new port within the\r\nrange defined, in the ascending order of port numbers. The destination IP address is also defined in\r\nparameters.\r\n0x81 – UDP flood. The same as 0x80, but UDP is used as the transport layer protocol.\r\n0x82 – ICMP flood. Same as above, but via ICMP.\r\n0x83, 0x84 – two DNS flood attacks. The only difference is the domain name sent in the DNS\r\nrequest. In the former case, the name is generated randomly, in the second, it is defined in a\r\nparameter (the fourth line in fwke.cfg). Essentially, both attacks are similar to 0x81, except that port\r\n53 (the default port for the DNS service) is used as destination port.\r\n0x02. Command to terminate an attack. The value in the first line of fwke.cfg is changed to 0 and the attack\r\nis terminated.\r\n0x03. Command to update the file fwke.cfg. The response also includes a structure similar to g_fakeCfg,\r\ndata from which is used to create the new fwke.cfg file.\r\n0x04. Command to send the current command’s execution status to the C\u0026C server.\r\nIn addition to the above, the backdoor includes several empty methods (without any code), which have curious\r\nnames: CThreadAttack::EmptyConnectionAtk, CThreadAttack::FakeUserAtk, CThreadAttack::HttpAtk.\r\nApparently, the malware writer had plans to extend the malicious program’s functionality, and this is a test version\r\nrather than a final version. The file cupsdd, which is discussed below, provides a confirmation of this.\r\nThe files kysapdd, skysapdd, xfsdxd, ksapdd are almost identical copies of atddd, with the exception that they\r\ncontain different C\u0026C server addresses: 112.90.252.76:10991, 112.90.22.197:10991, 116.10.189.246:10991 and\r\n121.12.110.96:10991, respectively. The names of their configuration files are also different: fsfe.cfg, btgw.cfg,\r\nfake.cfg, xcke.cfg, respectively.\r\nThis means that, contrary to our expectations, the files atddd, kysapdd, skysapdd, xfsdxd, ksapdd are not modules\r\nof a single piece of malware but rather different copies of the same Trojan, each connecting to its own C\u0026C\r\nserver. However, this is not the most curious part of it by far.\r\nBackdoor.Linux.Ganiw.a (cupsdd)\r\nLike the files described above, this file is a backdoor designed to carry out various types of DDoS attacks.\r\nHowever, cupsdd is significantly more feature-rich and sophisticated than its ‘colleagues’, although in places its\r\ncode is very similar to that found in atddd.\r\nThe backdoor starts its operation by initializing the variables it needs from the string\r\n“116.10.189.246:30000:1:1:h:578856:579372:579888” (separator – “:”), which it first decrypts using the RSA\r\nalgorithm. The string contains the following variables:\r\ng_strConnTgt=116.10.189.246 – C\u0026C server’s IP address\r\ng_iGatsPort=30000 – C\u0026C server’s port\r\ng_iGatsIsFx=1 and g_iIsService=1 – flags used later\r\nhttps://securelist.com/versatile-ddos-trojan-for-linux/64361/\r\nPage 4 of 14\n\ng_strBillTail=h – postfix for the name of the file that will be dropped (see below)\r\ng_strCryptStart=578856, g_strDStart=579372, g_strNStart=579888 – pointers to RSA data (encrypted string and\r\nkey)\r\nNext, the malware drops and executes a file, which is located at offset 0xb1728 from the beginning of the original\r\nfile and is 335872 bytes in size, provided that the file is not already running. The malware checks whether the file\r\nis running by trying to bind a socket to 127.0.0.1:10808. If the attempt is successful, it means that the file is not\r\nrunning, and it needs to be dropped and executed.\r\nIf the file is already running, its process, whose PID can be found in the file /tmp/bill.lock, is terminated (kill(pid,\r\n9)). Then the file is dropped anyway, replacing the existing copy.\r\nThe name of the file that is dropped is generated from the name of the current file that is running + postfix from\r\nthe variable g_strBillTail. In our case, the file was named cupsddh and was located in the same folder with the\r\ndropper.\r\nAfter this, the current process forks and the child process calls the function system(“/path/to/cupsddh”), which\r\nexecutes the file dropped.\r\nNext, the function daemon(1, 0) is called, for the same purpose as in the case of the sample described above\r\n(atddd).\r\nAfter this, the malware handles the situation if cupsdd was executed earlier and is currently active. For this\r\npurpose, it checks whether the file /tmp/gates.lock exists. If it does exist, the current process is terminated\r\n(exit(0)). If not, the file (/tmp/gates.lock) is created and the PID of the current process is written to it.\r\nThen, if flag g_iIsService == 1, the backdoor sets itself to run at system startup by creating the following script\r\nnamed DbSecuritySpt in /etc/init.d/:\r\n#!/bin/bash\r\n/path/to/cupsdd\r\nThe malware also creates symbolic links to the script in /etc/rc[1-5].1/S97DbSecuritySpt\r\nhttps://securelist.com/versatile-ddos-trojan-for-linux/64361/\r\nPage 5 of 14\n\nNext, the malware reads the configuration file conf.n (if it exists) from the same folder as the one in which cupsdd\r\nis located. The first 4 bytes of the file define the size of the data which follows. All the data is stored in the\r\nstructure g_cnfgDoing.\r\nThen the malware reads the file containing commands – cmd.n. The format is the same as in conf.n. The data is\r\nstored in the structure g_cmdDoing.\r\nAfter this, the malware obtains all the necessary information about the system, including:\r\nThe operating system’s name and kernel version (e.g., Linux 3.11.0-15-generic), by calling uname()\r\nCPU clock rate, taken from /proc/cpuinfo\r\nNumber of CPU cores, taken from /proc/cpuinfo, and CPU load, taken from /proc/stat\r\nNetwork load, taken from /proc/net/dev\r\nHard drive size in megabytes, taken from /proc/meminfo\r\nInformation about network interfaces, taken from /proc/net/dev\r\nAll the data is stored in the structure g_statBase.\r\nNext, a new stream, CThreadTaskGates::ProcessMain, is created, in which the following commands are\r\nprocessed:\r\nhttps://securelist.com/versatile-ddos-trojan-for-linux/64361/\r\nPage 6 of 14\n\n0x03. DoConfigCommand(). Update the configuration file conf.n.\r\n0x05. DoUpdateCommand(). Start a new thread, CThreadUpdate::ProcessMain, in which update one of its\r\ncomponents. The command accepts a number from 1 to 3 as a parameter. Each of the numbers is associated\r\nwith one of the following strings:\r\n1 – “Alib” – the file /usr/lib/libamplify.so\r\n2 – “Bill” – the dropped module (cupsddh)\r\n3 – “Gates” – the dropper (cupsdd)\r\nDepending on the parameter, one of the malicious program’s components is updated. An update is launched by\r\nsending 6 bytes containing the string “EF76#^” to the C\u0026C server, followed by one of the strings described above\r\n(depending on the parameter).\r\nThe C\u0026C responds by sending 4 bytes containing the length (in bytes) of the file that will be transferred next.\r\nThen the C\u0026C transfers the file itself in 1024-byte packets.\r\nFirst, the file is saved in the /tmp folder under a random name consisting of digits. Then, depending on the file that\r\nwas received, the existing file cupsdd (or cupsddh) is replaced or the file is copied to /usr/lib/libamplify.so\r\nNext, the temporary file is deleted from /tmp, and the chmod command is used to set 755 permissions for the\r\nresulting file. After this, in the case of updating cupsddh, the active process is terminated and the new file is\r\nhttps://securelist.com/versatile-ddos-trojan-for-linux/64361/\r\nPage 7 of 14\n\nlaunched. In the case of updating cupsdd, the final stage (starting from copying a file from /tmp) is carried out by\r\ncupsddh, to which the relevant command is sent.\r\n0x07. DoCommandCommand(). Write a new command to cmd.n.\r\n0x02. StopUpdate(). Close the current connection, which was established in order to update modules.\r\nNext, the backdoor starts several threads, in which it simultaneously performs several additional operations:\r\nCThreadClientStatus updates the data on CPU and network load in the g_statBase structure every second.\r\nCThreadRecycle removes completed tasks from the queue.\r\nCThreadConnSender reads commands from the queue and passes them to the cupsddh module via a TCP\r\nconnection with 127.0.0.1 on port 10808. In response it receives the status of their execution.\r\nCThreadMonBill checks whether the module cupsddh is running once every minute. If not, it drops and\r\nexecutes it again.\r\nCThreadLoopCmd reads commands from g_cmdDoing (the file cmd.n) and executes them using the call\r\nsystem(cmd).\r\nNext, the main thread enters the loop of receiving and processing commands from the C\u0026C server. There are two\r\npossibilities in this case, depending on the g_iGatsIsFx flag:\r\n1. 1 If the flag is set (==1), the malware simply uses the new thread to send information about the system and\r\nthe current configuration from g_cnfgDoing to the C\u0026C and waits to receive commands in response, like\r\nthe sample (atddd) described above;\r\n2. 2 If the flag is not set, then the communication session is initiated by the C\u0026C. In other words, the\r\nmalware waits for the C\u0026C to connect and begins to transfer the data mentioned above only when a\r\nconnection has been established.\r\nhttps://securelist.com/versatile-ddos-trojan-for-linux/64361/\r\nPage 8 of 14\n\nCommands received from the C\u0026C are divided into two queues: either for execution in the current module (in the\r\nthread CThreadTaskGates described above) or for passing to the cupsddh module (thread CThreadConnSender).\r\nBackdoor.Linux.Ganiw.a (cupsddh)\r\nThe file is packed with UPX. After being unpacked, it calls daemon(1,0). It creates the file /tmp/bill.lock, in which\r\nit stores the PID of the current process. cupsddh stores system data in the structure g_statBase, which is identical\r\nto that used by cupsdd.\r\nNext, it populates the structure g_provinceDns with the IP addresses of DNS servers converted to binary data in\r\nnetwork byte order using the function inet_addr(), taking data from the string array g_sProvinceDns (offset in\r\nunpacked file: 0x8f44с, size 4608 bytes).\r\ncupsddh executes command “insmod /usr/lib/xpacket.ko” in an attempt to load the kernel module into the kernel.\r\nHowever, the file is not present on ‘clean’ systems, and the malware does not make any attempt to download it or\r\nobtain it in any other way.\r\nNext, data from the file /usr/libamplify.so (as it turns out, this is not a library but one more config file) is loaded\r\ninto the structure g_AmpResource. The file has the following format: 1st dword is the number of dwords that\r\nfollow. Apparently, it contains the list of IP addresses for DNS servers that are currently relevant, i.e., those\r\nsuitable for DNS Amplification type DDoS attacks.\r\nAfter this, the module creates two threads: CThreadTask and CThreadRecycle. The former executes commands\r\nfrom a queue comprising commands which came from the cupsdd module. The latter removes commands that\r\nhave been executed. Next, the main thread binds a socket to 127.0.0.1:10808 and enters an endless loop, receiving\r\ncommands from the cupsdd module and putting the commands received into the above queue.\r\nThe following commands are possible:\r\n0x01. Start an attack according to the parameters received. See a more detailed description below.\r\n0x02. Terminate the current attack, setting the relevant flag.\r\n0x03. Update the current configuration in the g_cnfgDoing structure, which is used during an attack. Also,\r\nupdate the current local MAC address, as well as the MAC and IP address of the current gateway in the\r\nstructure g_statBase.\r\nhttps://securelist.com/versatile-ddos-trojan-for-linux/64361/\r\nPage 9 of 14\n\n0x05. The final stage of updating the cupsdd module (described above).\r\nTwo main attack modes are possible: normal mode and kernel mode.\r\nKernel mode\r\nThis mode uses pktgen, a kernel-level packet generator built into Linux. Its advantage to the attacker is that traffic\r\nis generated with the greatest speed possible for the given network interface. In addition, the packets generated in\r\nthis way cannot be detected using ordinary sniffers, e.g., the standard tcpdump, since packets are generated at\r\nkernel level.\r\nThe packet generator is controlled using a set of scripts/configs in the /proc/net/pktgen folder, but the module\r\npktgen must first be loaded into the kernel by calling the command “modprobe pktgen”. However, I did not find\r\nany such calls. Apparently, the call “insmod /usr/lib/xpacket.ko” is used instead, although, as mentioned above,\r\nthe file is absent from the system by default. As a result, kernel mode is not operational in this version of the\r\nmalware.\r\nNevertheless, the malware attempts to write several files to the /proc/net/pktgen folder, namely:\r\nhttps://securelist.com/versatile-ddos-trojan-for-linux/64361/\r\nPage 10 of 14\n\n1. 1 the file /proc/net/pktgen/kpktgend_%d for each CPU core, where %d is the core number, beginning from\r\n0. The file’s contents is as follows:\r\nrem_device_all\r\nadd_device eth%d\r\nmax_before_softirq 10000\r\n2. 2 the file /proc/net/pktgen/eth%d for each CPU core, where %d is the core number, beginning from 0. The\r\nfile’s contents is as follows:\r\ncount 0\r\nclone_skb 0\r\ndelay 0\r\nTXSIZE_RND\r\nmin_pkt_size %d\r\nmax_pkt_size %d\r\nIPSRC_RND\r\nsrc_min %s\r\nsrc_max %s\r\nUDPSRC_RND\r\nudp_src_min %d\r\nudp_src_max %d\r\ndst %s\r\nudp_dst_min %d\r\nudp_dst_max %d\r\ndst_mac %02x:%02x:%02x:%02x:%02x:%02x        //MAC address of the gateway from g_statBase\r\nis_multi %d\r\nmulti_dst %s        //if there are several addresses to be used in an attack (i.e., if the value in the previous\r\nline is not equal to 0), they are set in these lines, the number of which matches the previous parameter\r\npkt_type %d\r\ndns_domain %s\r\nhttps://securelist.com/versatile-ddos-trojan-for-linux/64361/\r\nPage 11 of 14\n\nsyn_flag %d\r\nis_dns_random %d\r\ndns_type %d\r\nis_edns %d\r\nedns_len %d\r\nis_edns_sec %d\r\nThe values of most pktgen parameters are passed from cupsdd via command parameters.\r\n3. 3 the file /proc/net/pktgen/pgctrl, which contains the string “start”.\r\nNormal attack mode\r\nAs in the case of atddd, normal attack mode uses raw sockets.\r\nThe following attack types are possible in this mode:\r\nCAttackSyn – TCP-SYN flood.\r\nCAttackUdp – UDP flood (as in the case of atddd)\r\nCAttackDns – DNS flood (as in the case of atddd)\r\nCAttackIcmp – ICMP flood (as in the case of atddd)\r\nCAttackCc – HTTP flood.\r\nCAttackAmp – DNS Amplification.\r\nThe last attack type on the list above is different in that packets are sent to vulnerable DNS servers, with the attack\r\ntarget specified as the sender’s IP address. As a result, the cybercriminal sends a small packet with a DNS request\r\nand the DNS server responds to the attack target with a significantly larger packet. The list of vulnerable DNS\r\nservers is stored in the file libamplify.so, which is written to disk following the relevant command from the C\u0026C.\r\nPost Scriptum. BillGates v1.5\r\nThis version of the Trojan appeared a little later and is probably currently the latest. Essentially, this is the same\r\ncupsdd, only a little ‘shaped up’. Overall, there is more logic in the code, plus there are a couple of new functions.\r\nThe most significant changes were made to the Gates module, i.e., the file cupsdd. Now it has three operating\r\nmodes. The choice of mode is based on the folder from which the file is launched. Specifically, if it is launched\r\nhttps://securelist.com/versatile-ddos-trojan-for-linux/64361/\r\nPage 12 of 14\n\nfrom /usr/bin/pojie, then monitoring mode is enabled, otherwise the module operates in installation and updating\r\nmode, which is later superseded by the mode in which it controls the Bill module.\r\n1. 1 Installation and updating mode.\r\nFirst, the module terminates its process working in monitoring mode, if it exists. Its PID is kept in the file\r\n/tmp/moni.lock.\r\nNext, it reinstalls and re-launches the Bill module.\r\nNext, if a process working in the ‘controlling the Bill module’ mode exists, that process is terminated. Its\r\nPID is kept in the file /tmp/gates.lock.\r\nIf the flag g_iIsService is set (it is defined in the same way as in the previous version), the module sets\r\nitself to run at system startup in the same way as before (in the previous version).\r\nNext, the module writes its path to the file /tmp/notify.file and then copies itself to the file /usr/bin/pojie.\r\nAfter this, it launches its copy, which is, obviously, set to run in monitoring mode, and then changes its\r\nown operating mode to controlling the Bill module.\r\n2. 2 Monitoring mode.\r\nWrites the PID of the current process to the file /tmp/moni.lock. Next, it starts two threads – one to monitor\r\nthe Bill module and the other to monitor the Gates module operating in controlling Bill mode. If one of\r\nthese processes is currently not running, the relevant file is created and launched again.\r\n3. 3 Controlling the Bill module mode.\r\nThe actions of the Gates module are exactly the same as they were in the previous version of the Trojan\r\n(after installing the Bill module and initializing the relevant variables and structures of the Trojan).\r\nTo summarize, in the new version of the Trojan its authors have added a little ‘robustness’ without making any\r\nsignificant functionality changes.\r\nhttps://securelist.com/versatile-ddos-trojan-for-linux/64361/\r\nPage 13 of 14\n\nIt is also worth noting that the hard-coded IP address of the C\u0026C server has remained the same (116.10.189.246)\r\nin this version, but the port number has changed – it is now 36008 instead of 30000 in the previous version.\r\nSource: https://securelist.com/versatile-ddos-trojan-for-linux/64361/\r\nhttps://securelist.com/versatile-ddos-trojan-for-linux/64361/\r\nPage 14 of 14\n\n  https://securelist.com/versatile-ddos-trojan-for-linux/64361/     \nIt is also worth noting that the hard-coded IP address of the C\u0026C server has remained the same (116.10.189.246)\nin this version, but the port number has changed -it is now 36008 instead of 30000 in the previous version.\nSource: https://securelist.com/versatile-ddos-trojan-for-linux/64361/       \n   Page 14 of 14",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://securelist.com/versatile-ddos-trojan-for-linux/64361/"
	],
	"report_names": [
		"64361"
	],
	"threat_actors": [
		{
			"id": "eb3f4e4d-2573-494d-9739-1be5141cf7b2",
			"created_at": "2022-10-25T16:07:24.471018Z",
			"updated_at": "2026-04-10T02:00:05.002374Z",
			"deleted_at": null,
			"main_name": "Cron",
			"aliases": [],
			"source_name": "ETDA:Cron",
			"tools": [
				"Catelites",
				"Catelites Bot",
				"CronBot",
				"TinyZBot"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434715,
	"ts_updated_at": 1775826784,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d106b11e320d098a4a2bedef1b1b21dcb9a3deda.pdf",
		"text": "https://archive.orkl.eu/d106b11e320d098a4a2bedef1b1b21dcb9a3deda.txt",
		"img": "https://archive.orkl.eu/d106b11e320d098a4a2bedef1b1b21dcb9a3deda.jpg"
	}
}