{ "id": "19581626-2aa5-4b2d-8e7f-ef11fe0562cf", "created_at": "2026-04-06T00:10:23.803641Z", "updated_at": "2026-04-10T03:32:20.753469Z", "deleted_at": null, "sha1_hash": "a3f0a811b6cb3ade7a584fd0101917e0b39c98cc", "title": "HiddenWasp Malware Stings Targeted Linux Systems", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 3490035, "plain_text": "HiddenWasp Malware Stings Targeted Linux Systems\r\nBy Ignacio Sanmillan\r\nPublished: 2019-05-29 · Archived: 2026-04-05 18:13:33 UTC\r\nOverview\r\n• Intezer has discovered a new, sophisticated malware that we have named “HiddenWasp”, targeting Linux\r\nsystems.\r\n• The malware is still active and has a zero-detection rate in all major anti-virus systems.\r\n• Unlike common Linux malware, HiddenWasp is not focused on crypto-mining or DDoS activity. It is a trojan\r\npurely used for targeted remote control.\r\n• Evidence shows in high probability that the malware is used in targeted attacks for victims who are already\r\nunder the attacker’s control, or have gone through a heavy reconnaissance.\r\n• HiddenWasp authors have adopted a large amount of code from various publicly available open-source malware,\r\nsuch as Mirai and the Azazel rootkit. In addition, there are some similarities between this malware and other\r\nChinese malware families, however the attribution is made with low confidence.\r\n• We have detailed our recommendations for preventing and responding to this threat.\r\n1. Introduction\r\nAlthough the Linux threat ecosystem is crowded with IoT DDoS botnets and crypto-mining malware, it is not very\r\ncommon to spot trojans or backdoors in the wild.\r\nUnlike Windows malware, Linux malware authors do not seem to invest too much effort writing their implants. In\r\nan open-source ecosystem there is a high ratio of publicly available code that can be copied and adapted by\r\nattackers.\r\nIn addition, Anti-Virus solutions for Linux tend to not be as resilient as in other platforms. Therefore, threat actors\r\ntargeting Linux systems are less concerned about implementing excessive evasion techniques since even when\r\nreusing extensive amounts of code, threats can relatively manage to stay under the radar.\r\nNevertheless, malware with strong evasion techniques do exist for the Linux platform. There is also a high ratio of\r\npublicly available open-source malware that utilize strong evasion techniques and can be easily adapted by\r\nattackers.\r\nWe believe this fact is alarming for the security community since many implants today have very low detection\r\nrates, making these threats difficult to detect and respond to.\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 1 of 30\n\nWe have discovered further undetected Linux malware that appear to be enforcing advanced evasion techniques\r\nwith the use of rootkits to leverage trojan-based implants.\r\nIn this blog we will present a technical analysis of each of the different components that this new malware,\r\nHiddenWasp, is composed of. We will also highlight interesting code-reuse connections that we have observed to\r\nseveral open-source malware.\r\nThe following images are screenshots from VirusTotal of the newer undetected malware samples discovered:\r\n2. Technical Analysis\r\nWhen we came across these samples we noticed that the majority of their code was unique:\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 2 of 30\n\nSimilar to the recent Winnti Linux variants reported by Chronicle, the infrastructure of this malware is composed\r\nof a user-mode rootkit, a trojan and an initial deployment script. We will cover each of the three components in\r\nthis post, analyzing them and their interactions with one another.\r\n2.1 Initial Deployment Script:\r\nWhen we spotted these undetected files in VirusTotal it seemed that among the uploaded artifacts there was a bash\r\nscript along with a trojan implant binary.\r\nWe observed that these files were uploaded to VirusTotal using a path containing the name of a Chinese-based\r\nforensics company known as Shen Zhou Wang Yun Information Technology Co., Ltd.\r\nFurthermore, the malware implants seem to be hosted in servers from a physical server hosting company known\r\nas ThinkDream located in Hong Kong.\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 3 of 30\n\nAmong the uploaded files, we observed that one of the files was a bash script meant to deploy the malware itself\r\ninto a given compromised system, although it appears to be for testing purposes:\r\nThanks to this file we were able to download further artifacts not present in VirusTotal related to this\r\ncampaign. This script will start by defining a set of variables that would be used throughout the script.\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 4 of 30\n\nAmong these variables we can spot the credentials of a user named ‘sftp’, including its hardcoded password. This\r\nuser seems to be created as a means to provide initial persistence to the compromised system:\r\nFurthermore, after the system’s user account has been created, the script proceeds to clean the system as a means\r\nto update older variants if the system was already compromised:\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 5 of 30\n\nThe script will then proceed to download a tar compressed archive from a download server according to the\r\narchitecture of the compromised system. This tarball will contain all of the components from the malware,\r\ncontaining the rootkit, the trojan and an initial deployment script:\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 6 of 30\n\nAfter malware components have been installed, the script will then proceed to execute the trojan:\r\nWe can see that the main trojan binary is executed, the rootkit is added to LD_PRELOAD path and another series\r\nof environment variables are set such as the ‘I_AM_HIDDEN’. We will cover throughout this post what the role\r\nof this environment variable is. To finalize, the script attempts to install reboot persistence for the trojan binary by\r\nadding it to /etc/rc.local.\r\nWithin this script we were able to observe that the main implants were downloaded in the form of tarballs. As\r\npreviously mentioned, each tarball contains the main trojan, the rootkit and a deployment script for x86 and\r\nx86_64 builds accordingly.\r\nThe deployment script has interesting insights of further features that the malware implements, such as the\r\nintroduction of a new environment variable ‘HIDE_THIS_SHELL’:\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 7 of 30\n\nWe found some of the environment variables used in a open-source rootkit known as Azazel.\r\nIt seems that this actor changed the default environment variable from Azazel, that one being\r\nHIDE_THIS_SHELL for I_AM_HIDDEN. We have based this conclusion on the fact that the environment\r\nvariable HIDE_THIS_SHELL was not used throughout the rest of the components of the malware and it seems to\r\nbe residual remains from Azazel original code.\r\nThe majority of the code from the rootkit implants involved in this malware infrastructure are noticeably different\r\nfrom the original Azazel project. Winnti Linux variants are also known to have reused code from this open-source\r\nproject.\r\n2.2 The Rootkit:\r\nThe rootkit is a user-space based rootkit enforced via LD_PRELOAD linux mechanism.\r\nIt is delivered in the form of an ET_DYN stripped ELF binary.\r\nThis shared object has an DT_INIT dynamic entry. The value held by this entry is an address that will be executed\r\nonce the shared object gets loaded by a given process:\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 8 of 30\n\nWithin this function we can see that eventually control flow falls into a function in charge to resolve a set of\r\ndynamic imports, which are the functions it will later hook, alongside with decoding a series of strings needed for\r\nthe rootkit operations.\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 9 of 30\n\nWe can see that for each string it allocates a new dynamic buffer, it copies the string to it to then decode it.\r\nIt seems that the implementation for dynamic import resolution slightly varies in comparison to the one used in\r\nAzazel rootkit.\r\nWhen we wrote the script to simulate the cipher that implements the string decoding function we observed the\r\nfollowing algorithm:\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 10 of 30\n\nWe recognized that a similar algorithm to the one above was used in the past by Mirai, implying that authors\r\nbehind this rootkit may have ported and modified some code from Mirai.\r\nAfter the rootkit main object has been loaded into the address space of a given process and has decrypted its\r\nstrings, it will export the functions that are intended to be hooked. We can see these exports to be the following:\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 11 of 30\n\nFor every given export, the rootkit will hook and implement a specific operation accordingly, although they all\r\nhave a similar layout. Before the original hooked function is called, it is checked whether the environment\r\nvariable ‘I_AM_HIDDEN’ is set:\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 12 of 30\n\nWe can see an example of how the rootkit hooks the function fopen in the following screenshot:\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 13 of 30\n\nWe have observed that after checking whether the ‘I_AM_HIDDEN’ environment variable is set, it then runs a\r\nfunction to hide all the rootkits’ and trojans’ artifacts. In addition, specifically to the fopen function it will also\r\ncheck whether the file to open is ‘/proc/net/tcp’ and if it is it will attempt to hide the malware’s connection to the\r\ncnc by scanning every entry for the destination or source ports used to communicate with the cnc, in this case\r\n61061. This is also the default port in Azazel rootkit.\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 14 of 30\n\nThe rootkit primarily implements artifact hiding mechanisms as well as tcp connection hiding as previously\r\nmentioned. Overall functionality of the rootkit can be illustrated in the following diagram:\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 15 of 30\n\n2.3 The Trojan:\r\nThe trojan comes in the form of a statically linked ELF binary linked with stdlibc++. We noticed that the trojan\r\nhas code connections with ChinaZ’s Elknot implant in regards to some common MD5 implementation in one of\r\nthe statically linked libraries it was linked with:\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 16 of 30\n\nIn addition, we also see a high rate of shared strings with other known ChinaZ malware, reinforcing the possibility\r\nthat actors behind HiddenWasp may have integrated and modified some MD5 implementation from Elknot that\r\ncould have been shared in Chinese hacking forums:\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 17 of 30\n\nWhen we analyze the main we noticed that the first action the trojan takes is to retrieve its configuration:\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 18 of 30\n\nThe malware configuration is appended at the end of the file and has the following structure:\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 19 of 30\n\nThe malware will try to load itself from the disk and parse this blob to then retrieve the static encrypted\r\nconfiguration.\r\nOnce encryption configuration has been successfully retrieved the configuration will be decoded and then parsed\r\nas json.\r\nThe cipher used to encode and decode the configuration is the following:\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 20 of 30\n\nThis cipher seems to be an RC4 alike algorithm with an already computed PRGA generated key-stream. It is\r\nimportant to note that this same cipher is used later on in the network communication protocol between trojan\r\nclients and their CNCs.\r\nAfter the configuration is decoded the following json will be retrieved:\r\nMoreover, if the file is running as root, the malware will attempt to change the default location of the dynamic\r\nlinker’s LD_PRELOAD path. This location is usually at /etc/ld.so.preload, however there is always a possibility to\r\npatch the dynamic linker binary to change this path:\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 21 of 30\n\nPatch_ld function will scan for any existent /lib paths. The scanned paths are the following:\r\nThe malware will attempt to find the dynamic linker binary within these paths. The dynamic linker filename is\r\nusually prefixed with ld-\u003cversion number\u003e.\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 22 of 30\n\nOnce the dynamic linker is located, the malware will find the offset where the /etc/ld.so.preload string is located\r\nwithin the binary and will overwrite it with the path of the new target preload path, that one being /sbin/.ifup-local.\r\nTo achieve this patching it will execute the following formatted string by using the xxd hex editor utility by\r\npreviously having encoded the path of the rootkit in hex:\r\nOnce it has changed the default LD_PRELOAD path from the dynamic linker it will deploy a thread to enforce\r\nthat the rootkit is successfully installed using the new LD_PRELOAD path. In addition, the trojan will\r\ncommunicate with the rootkit via the environment variable ‘I_AM_HIDDEN’ to serialize the trojan’s session for\r\nthe rootkit to apply evasion mechanisms on any other sessions.\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 23 of 30\n\nAfter seeing the rootkit’s functionality, we can understand that the rootkit and trojan work together in order to help\r\neach other to remain persistent in the system, having the rootkit attempting to hide the trojan and the trojan\r\nenforcing the rootkit to remain operational. The following diagram illustrates this relationship:\r\nContinuing with the execution flow of the trojan, a series of functions are executed to enforce evasion of some\r\nartifacts:\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 24 of 30\n\nThese artifacts are the following:\r\nBy performing some OSINT regarding these artifact names, we found that they belong to a Chinese open-source\r\nrootkit for Linux known as Adore-ng hosted in GitHub:\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 25 of 30\n\nThe fact that these artifacts are being searched for suggests that potentially targeted Linux systems by these\r\nimplants may have already been compromised with some variant of this open-source rootkit as an additional\r\nartifact in this malware’s infrastructure. Although those paths are being searched for in order to hide their presence\r\nin the system, it is important to note that none of the analyzed artifacts related to this malware are installed in such\r\npaths.\r\nThis finding may imply that the target systems this malware is aiming to intrude may be already known\r\ncompromised targets by the same group or a third party that may be collaborating with the same end goal of this\r\nparticular campaign.\r\nMoreover, the trojan communicated with a simple network protocol over TCP. We can see that when connection is\r\nestablished to the Master or Stand-By servers there is a handshake mechanism involved in order to identify the\r\nclient.\r\nWith the help of this function we where able to understand the structure of the communication protocol employed.\r\nWe can illustrate the structure of this communication protocol by looking at a pcap of the initial handshake\r\nbetween the server and client:\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 26 of 30\n\nWe noticed while analyzing this protocol that the Reserved and Method fields are always constant, those being 0\r\nand 1 accordingly. The cipher table offset represents the offset in the hardcoded key-stream that the encrypted\r\npayload was encoded with. The following is the fixed keystream this field makes reference to:\r\nAfter decrypting the traffic and analyzing some of the network related functions of the trojan, we noticed that the\r\ncommunication protocol is also implemented in json format. To show this, the following image is the decrypted\r\nhandshake packets between the CNC and the trojan:\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 27 of 30\n\nAfter the handshake is completed, the trojan will proceed to handle CNC requests:\r\nDepending on the given requests the malware will perform different operations accordingly. An overview of the\r\ntrojan’s functionalities performed by request handling are shown below:\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 28 of 30\n\n2.3. Prevention and Response\r\nPrevention: Block Command-and-Control IP addresses detailed in the IOCs section.\r\nResponse: We have provided a YARA rule intended to be run against in-memory artifacts in order to be able to\r\ndetect these implants.\r\nIn addition, in order to check if your system is infected, you can search for “ld.so” files — if any of the files do\r\nnot contain the string ‘/etc/ld.so.preload’, your system may be compromised. This is because the trojan implant\r\nwill attempt to patch instances of ld.so in order to enforce the LD_PRELOAD mechanism from arbitrary\r\nlocations.\r\n4. Summary\r\nWe analyzed every component of HiddenWasp explaining how the rootkit and trojan implants work in parallel\r\nwith each other in order to enforce persistence in the system.\r\nWe have also covered how the different components of HiddenWasp have adapted pieces of code from various\r\nopen-source projects. Nevertheless, these implants managed to remain undetected.\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 29 of 30\n\nLinux malware may introduce new challenges for the security community that we have not yet seen in other\r\nplatforms. The fact that this malware manages to stay under the radar should be a wake up call for the security\r\nindustry to allocate greater efforts or resources to detect these threats.\r\nLinux malware will continue to become more complex over time and currently even common threats do not have\r\nhigh detection rates, while more sophisticated threats have even lower visibility.        \r\nIOCs\r\n103.206.123[.]13\r\n103.206.122[.]245\r\nhttp://103.206.123[.]13:8080/system.tar.gz\r\nhttp://103.206.123[.]13:8080/configUpdate.tar.gz\r\nhttp://103.206.123[.]13:8080/configUpdate-32.tar.gz\r\ne9e2e84ed423bfc8e82eb434cede5c9568ab44e7af410a85e5d5eb24b1e622e3\r\nf321685342fa373c33eb9479176a086a1c56c90a1826a0aef3450809ffc01e5d\r\nd66bbbccd19587e67632585d0ac944e34e4d5fa2b9f3bb3f900f517c7bbf518b\r\n0fe1248ecab199bee383cef69f2de77d33b269ad1664127b366a4e745b1199c8\r\n2ea291aeb0905c31716fe5e39ff111724a3c461e3029830d2bfa77c1b3656fc0\r\nd596acc70426a16760a2b2cc78ca2cc65c5a23bb79316627c0b2e16489bf86c0\r\n609bbf4ccc2cb0fcbe0d5891eea7d97a05a0b29431c468bf3badd83fc4414578\r\n8e3b92e49447a67ed32b3afadbc24c51975ff22acbd0cf8090b078c0a4a7b53d\r\nf38ab11c28e944536e00ca14954df5f4d08c1222811fef49baded5009bbbc9a2\r\n8914fd1cfade5059e626be90f18972ec963bbed75101c7fbf4a88a6da2bc671b\r\nSource: https://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nhttps://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/\r\nPage 30 of 30\n\n https://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/ \nWithin this function we can see that eventually control flow falls into a function in charge to resolve a set of\ndynamic imports, which are the functions it will later hook, alongside with decoding a series of strings needed for\nthe rootkit operations. \n Page 9 of 30", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia", "MITRE" ], "references": [ "https://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/" ], "report_names": [ "blog-hiddenwasp-malware-targeting-linux-systems" ], "threat_actors": [ { "id": "4d5f939b-aea9-4a0e-8bff-003079a261ea", "created_at": "2023-01-06T13:46:39.04841Z", "updated_at": "2026-04-10T02:00:03.196806Z", "deleted_at": null, "main_name": "APT41", "aliases": [ "WICKED PANDA", "BRONZE EXPORT", "Brass Typhoon", "TG-2633", "Leopard Typhoon", "G0096", "Grayfly", "BARIUM", "BRONZE ATLAS", "Red Kelpie", "G0044", "Earth Baku", "TA415", "WICKED SPIDER", "HOODOO", "Winnti", "Double Dragon" ], "source_name": "MISPGALAXY:APT41", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "2a24d664-6a72-4b4c-9f54-1553b64c453c", "created_at": "2025-08-07T02:03:24.553048Z", "updated_at": "2026-04-10T02:00:03.787296Z", "deleted_at": null, "main_name": "BRONZE ATLAS", "aliases": [ "APT41 ", "BARIUM ", "Blackfly ", "Brass Typhoon", "CTG-2633", "Earth Baku ", "GREF", "Group 72 ", "Red Kelpie ", "TA415 ", "TG-2633 ", "Wicked Panda ", "Winnti" ], "source_name": "Secureworks:BRONZE ATLAS", "tools": [ "Acehash", "CCleaner v5.33 backdoor", "ChinaChopper", "Cobalt Strike", "DUSTPAN", "Dicey MSDN", "Dodgebox", "ForkPlayground", "HUC Proxy Malware (Htran)" ], "source_id": "Secureworks", "reports": null } ], "ts_created_at": 1775434223, "ts_updated_at": 1775791940, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/a3f0a811b6cb3ade7a584fd0101917e0b39c98cc.pdf", "text": "https://archive.orkl.eu/a3f0a811b6cb3ade7a584fd0101917e0b39c98cc.txt", "img": "https://archive.orkl.eu/a3f0a811b6cb3ade7a584fd0101917e0b39c98cc.jpg" } }