{
	"id": "b6fb4d6b-01dc-454c-9841-c924cfe2dd49",
	"created_at": "2026-04-06T00:15:38.967396Z",
	"updated_at": "2026-04-10T03:21:17.626197Z",
	"deleted_at": null,
	"sha1_hash": "5a27f71fd5fac010be600c54680a46ac9336d113",
	"title": "AI-Automated Threat Hunting Brings GhostPenguin Out of the Shadows",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3671499,
	"plain_text": "AI-Automated Threat Hunting Brings GhostPenguin Out of the Shadows\r\nBy Aliakbar Zahravi ( words)\r\nPublished: 2025-12-08 · Archived: 2026-04-05 20:55:51 UTC\r\nKey takeaways\r\nGhostPenguin is a multi-threaded Linux backdoor written in C++ that provides remote shell access and\r\ncomprehensive file system operations over an RC5-encrypted UDP channel. It establishes communication through a\r\nstructured session handshake mechanism and synchronizes multiple threads to handle registration, heartbeat\r\nsignaling, and reliable command delivery.\r\nGhostPenguin was discovered using Trend™ Research’s AI-driven, automated threat hunting pipeline that collected\r\nand analyzed zero-detection Linux samples from VirusTotal. The investigation involved building a structured\r\ndatabase of extracted artifacts, using AI to automate profiling, and employing VirusTotal hunting queries to surface\r\nzero-detection samples for deeper analysis.\r\nThis approach allowed artifacts to be extracted from thousands of malware samples, generated structured profiles,\r\nand used custom YARA rules and VirusTotal queries to surface undetected threats like GhostPenguin.\r\nOur analysis showed GhostPenguin is still in development, with debug artifacts and unused functions, highlighting\r\nthe importance of advanced AI and automation in uncovering sophisticated, evasive threats.\r\nTrend Vision One™ detects and blocks the specific indicators of compromise (IoCs) mentioned in this blog entry,\r\nand offers customers access to hunting queries, threat insights, and intelligence reports related to the GhostPenguin\r\nbackdoor.\r\nHunting high-impact, advanced malware is a difficult task. It becomes even harder and more time-consuming when\r\ndefenders focus on low-detection or zero-detection samples. Every day, a huge number of files are sent to platforms like\r\nVirusTotal, and the relevant ones often get lost in all that noise. Identifying malware with low or no detections is a\r\nparticularly challenging process, especially when the malware is new, undocumented, and built largely from scratch. When\r\nthreat actors avoid publicly available libraries, known GitHub code, or code borrowed from other malware families, they\r\ncreate previously unseen samples that can evade detection and make hunting them significantly harder.\r\nIn these cases, the threat actors carefully craft both the code and the network communication to minimize noise and keep the\r\nmalware as inconspicuous as possible. They often use multi-stage architectures and secure communication channels that do\r\nnot reveal subsequent stages unless the communication sequence unfolds exactly as expected. As a result, only a very small\r\namount of data is transferred between the infected host and the command-and-control (C\u0026C) server, further complicating\r\ndetection and analysis.\r\nPreviously, Trend™ Research reported on the effects of offensive GitHub projects and open-source red-teaming tools on\r\nmodern malware development ecosystem, and how defenders can use this as a chance to improve detection patterns and\r\ntheir overall approach for threat hunting. Our analysis also showed how artificial intelligence (AI) and automation can speed\r\nup and improve the accuracy of detection when a new malware family is created and shares code from those open-source\r\nrepositories.\r\nIn this blog entry, we demonstrate how AI can be utilized to find low-detection samples from VirusTotal and how this was\r\nused to analyze the GhostPenguin Linux backdoor.\r\nThreat hunting approach\r\nOur approach focused on collecting, processing, and analyzing a large number of malware samples from known and\r\nreported attacks. The goal was to extract useful artifacts that help hunt for new, undetected threats.\r\nhttps://www.trendmicro.com/en_us/research/25/l/ghostpenguin.html\r\nPage 1 of 23\n\nHunting workflow\r\n1. Collect and extract artifacts\r\nWe gather many malware samples from known and reported attacks and extract key information from them such as strings,\r\nAPI calls, behaviors, function names, variable names, and constants. All collected data is stored in a structured database.\r\nAfterwards, we tag and categorize the samples so they are easier to search and compare.\r\n2. Build VirusTotal hunting queries\r\nUsing the extracted artifacts, we create VirusTotal hunting rules and run them against samples with zero detections. When\r\nwe find potential candidates, pass the samples to the profiling stage.\r\n3. Profiling and analysis\r\nBinary files are sent to IDA Pro (Hex-Rays) for decompilation and further artifact extraction. CAPA also utilized to identify\r\nspecific capabilities (A custom rule has been generated based on the artifacts collected during Stage 1). Non-binary files like\r\nscripts or code are passed directly to the profiler for feature extraction. The profiler subsequently generates a unified profile\r\nin JSON format for each file, which is then forwarded to the next stage of analysis.\r\nThe AI agent Quick Inspect reviews the JSON profile created during the profiling stage. It analyzes the artifact, scores it,\r\nand determines if the file is malicious or not. Files below the threshold go into a monitoring list for later review, while files\r\nabove the threshold tagged as malicious and move to the next stage.\r\nThe Deep Inspector agent performs a deeper analysis on files that pass the threshold and are tagged as malicious. It\r\ngenerates a detailed analysis report for the file based on the decompiled code and the metadata created during the profiling\r\nstage. The agent reviews the file profile and produces a code-analysis report that includes:\r\nA short summary\r\nIdentified capabilities\r\nCode execution flow\r\nTechnical analysis\r\nMITRE ATT\u0026CK framework mapping\r\nWe used this pipeline to hunt for a VirusTotal zero-detection sample that we named GhostPenguin. The sample was\r\nsubmitted on July 7, 2025, and remained undetected in VirusTotal for more than four months.\r\nIf a file is packed or obfuscated, the YARA scanner and AI model usually detect this and tags it. If you have automated\r\nscripts for unpacking, you can set up an MCP server that can route these files to your unpacking pipeline for dynamic, static,\r\nor manual unpacking. Simple obfuscation and unpacking process can often be handled directly by AI (by a AI resolver or AI\r\ngenerating script for deobfuscation/unpacking), but heavy or complex obfuscation should be processed by external\r\nautomation, custom scripts or manual efforts.\r\nPhase 1\r\nIn this phase, in which we first need to gather as much intelligence as possible before we can hunt new and unknown threats,\r\nwe built a structured database and populated it with detailed information about each sample. The database stores file\r\nmetadata, category, tags, capabilities, MITRE techniques, strings, and Malware Behavior Catalog (MBC) behaviors of\r\ncollected malware samples. This database is extremely valuable, as it can be used for AI model fine-tuning, context-based AI\r\nsearch, RAG workflows, building a knowledge base, malware similarity matching, APT attribution, and more.\r\nWe began by defining the main categories for our hunting workflow, using Google Magika to help classify files\r\nautomatically:\r\nPlatform categories\r\nWindows\r\nhttps://www.trendmicro.com/en_us/research/25/l/ghostpenguin.html\r\nPage 2 of 23\n\nLinux\r\nMacOS\r\nFile types\r\nBinary\r\nScript\r\nBinary files are passed to IDA Pro for fingerprinting and to generate the decompiled code. The decompiled output is then\r\nsent to the AI model for processing. At this stage, the AI performs function renaming, adds function and code comments,\r\ngenerates summaries, identifies capabilities, assigns tags, analyzes network communication patterns, and more.\r\nAlongside the AI analysis, we also ran CAPA, FLOSS, and YARA on the same samples. All results were stored in a\r\nstructured JSON format and sent to the JSON parser. The parser extracted the relevant fields and mapped them into the\r\ndatabase. We also stored the raw JSON files separately so they can be used later for research or processed by other tools.\r\nThis threat intelligence collection system is illustrated in Figure 1, though it’s important to note that this chart is highly\r\nsimplified, and many modules and components have been removed for clarity and readability.\r\nPhase 2\r\nFor this research, our primary goal was to hunt for potential zero-detection Linux backdoors. To achieve this, we filtered out\r\nall Linux binaries and began identifying the most common API calls, strings, and behaviors. These findings guided our\r\nVirusTotal hunting queries and allowed us to build more accurate searches for unknown or undetected malware. These\r\nqueries could be used as YARA rules for VirusTotal RetroHunt or Live Hunt, or they can be run as manual VirusTotal search\r\nqueries (Figure 2). GhostPenguin was among the search results, as shown in Figure 3.\r\nhttps://www.trendmicro.com/en_us/research/25/l/ghostpenguin.html\r\nPage 3 of 23\n\nhttps://www.trendmicro.com/en_us/research/25/l/ghostpenguin.html\r\nPage 4 of 23\n\nPhase 3\r\nAfter collecting the potential candidates, the next step was to process and rank them. Since we focused on ELF binaries in\r\nthis research, we passed these files directly into the decompilation pipeline. In the third phase, the automated script sent each\r\nfile to IDA Pro to generate the decompiled output. Once the decompilation was complete, the script forwarded the result to\r\nthe AI model for analysis. For this task, we used gemini-3-pro to process the code (Figure 4).\r\nOnce the high-confidence malicious files were identified, they were passed to the next Deep Inspector. This stage generated\r\na more comprehensive report that included detailed behavior, capabilities, and technical insights (Figure 5).\r\nhttps://www.trendmicro.com/en_us/research/25/l/ghostpenguin.html\r\nPage 5 of 23\n\nGhostPenguin analysis\r\nName systemd\r\nMD5 7d3bd0d04d3625322459dd9f11cc2ea3\r\nSHA1 145da15a33b54e0602e0bbe810ef6c25f2701d50\r\nSHA256 7b75ce1d60d3c38d7eb63627e4d3a8c7e6a0f8f65c70d0b0cc4756aab98e9ab7\r\nMagic ELF 64-bit LSB executable, x86-64\r\nFile size 91.32 KB (93515 bytes)\r\nTable 1. GhostPenguin backdoor\r\nGhostPenguin is a multi-thread backdoor written in C++ that targets the Linux platform. The malware collects system\r\ninformation including IP address, gateway, OS version, hostname, and username, and sends it to a C\u0026C server during a\r\nregistration phase. It then receives and executes commands from the C\u0026C server. Supported commands allow the malware\r\nhttps://www.trendmicro.com/en_us/research/25/l/ghostpenguin.html\r\nPage 6 of 23\n\nto provide a remote shell via “/bin/sh”, and perform various file and directory operations including creating, deleting,\r\nrenaming, reading, and writing files, modifying file timestamps, and searching for files by extension. All C\u0026C\r\ncommunication occurs over UDP port 53. The malware first requests a 16-byte session ID from the server, which is\r\nsubsequently used as the key for an RC5 encryption algorithm to encrypt all traffic. The malware sends periodic heartbeats\r\nto maintain its connection. To prevent multiple instances from running, it creates a file named “.temp” in the user's home\r\ndirectory containing its process ID.\r\nGhostPenguin’s internal architecture\r\nTechnical analysis\r\nUpon execution, the malware first resolves its execution context by obtaining both the current user’s home directory and the\r\nfull path of the running process. It uses getpwuid() to retrieve the user’s home directory and readlink(\"/proc/self/exe\") to\r\ncapture its own executable path. With this information, it constructs the path for its temporary PID file inside the user’s\r\nhome directory (for example, \u003chome\u003e/.temp). Once the PID file location is prepared, the malware checks whether another\r\nrunning instance already exists. It does this by loading a PID value from its designated temporary lock file and verifying that\r\nthe file contains at least four bytes enough to represent a valid 32-bit PID. After extracting the PID, it invokes kill(pid, 0) to\r\ntest whether that process is currently active (Figure 7). If the call confirms the PID corresponds to a live process, the\r\nmalware concludes that an active instance is already running and aborts initialization; otherwise, the stale entry is ignored\r\nand execution proceeds.\r\nhttps://www.trendmicro.com/en_us/research/25/l/ghostpenguin.html\r\nPage 7 of 23\n\nThe malware then enters its main operational loop, which continues until a global exit flag g_bIsClientExit is set. Inside this\r\nloop, it iterates through a list of C\u0026C server addresses defined in a global configuration structure g_lpLinuxClientHostCfg.\r\nFor each server, it attempts to establish a full communication session. The malware’s C\u0026C configuration structure is shown\r\nbelow in Figure 8.\r\nNotably, a leftover debug configuration, g_szConfigDebug, was identified in the binary. This global variable contains a\r\nseparate, unused domain and IP address, which appears to be an artifact from the developer's testing (Figure 9).\r\nThis artifact strongly suggests the malware is still in active development. This theory is further supported by the discovery\r\nof two fully implemented persistence functions (ImpPresistence and ImpUnPresistence), but they are never used by the\r\nmalware.\r\nThe malware contains several spelling errors:\r\nImpPresistence - Misspelling of \"Persistence\"\r\nUserame - Misspelling of \"Username\" in the string \"Userame:%s\"\r\nIsPorecessExistByPID - Misspelling of \"Process\"\r\nThe code snippet in Figure 10 demonstrates the malware's main operation loop. The code iterates through a configured list\r\nof C\u0026C servers, launching separate threads for asynchronous communication (heartbeating, data receiving, and sending)\r\nonce a connection is established. This main thread then enters an idle state, waiting for a disconnect or an exit command.\r\nhttps://www.trendmicro.com/en_us/research/25/l/ghostpenguin.html\r\nPage 8 of 23\n\nMalware network communication \r\nhttps://www.trendmicro.com/en_us/research/25/l/ghostpenguin.html\r\nPage 9 of 23\n\nThe first step in C\u0026C communication is to acquire a session ID (Figure 12). The malware calls GetSessionUDFromServer,\r\nwhich spawns a worker thread (ThreadProcGetSessionIDFromServer) and waits for five seconds at most for it to complete\r\n(Figure 13). The worker thread constructs and sends a 34-byte UDP packet with command 0x04 to the C\u0026C server. This\r\ninitial request packet is not encrypted and contains the placeholder session ID “FFFFFFFFFFFFFFFF”. To demonstrate the\r\nmalware's capabilities and inspect the network traffic, we set up a C\u0026C server in a lab environment and redirected the\r\ninfected VM's traffic to our designated server where the C\u0026C server is hosted.\r\nhttps://www.trendmicro.com/en_us/research/25/l/ghostpenguin.html\r\nPage 10 of 23\n\nThe malware network packet has the following structure:\r\nstruct C2Packet {\r\n    unsigned short totalLength;        //    Total packet size\r\n    unsigned char  sessionID[16];      //    RC5 encryption key\r\n    unsigned char  commandType;        //    Command type\r\n    unsigned char  subCommand;         //    Direction and Acknowledgment packet flag\r\n    unsigned short taskID;             //    Task identifier\r\n    unsigned int   taskInstanceID;     //    Instance ID\r\n    unsigned int   taskSequenceNum;    //    Sequence number\r\n    unsigned char  paddingLen;         //    Padding count\r\n    unsigned char  payload[];          //    payload + padding\r\n};\r\nhttps://www.trendmicro.com/en_us/research/25/l/ghostpenguin.html\r\nPage 11 of 23\n\nThe malware then waits for a 34-byte response (Figure 14). If a valid response with command 0x04 is received, it extracts\r\nthe new 16-byte session ID from the packet and stores it in the global variable g_szSessionID. This session ID serves as the\r\nRC5 encryption key for all subsequent communications.\r\nhttps://www.trendmicro.com/en_us/research/25/l/ghostpenguin.html\r\nPage 12 of 23\n\nIf a session ID is successfully obtained, the malware starts the main data receiver thread, ThreadProcDataReceiver. This\r\nthread enters an infinite loop, waiting to receive UDP packets from the C\u0026C server. Upon receiving a packet, it performs\r\nseveral validation checks: the received size must match the packet's internal length field, the session ID must match the one\r\nobtained earlier, and the encrypted payload length must be a multiple of eight.\r\nIf the packet is valid, its payload (from offset 18 onwards) is decrypted in-place using a custom RC5 implementation\r\n(CMyRC5::EncDecRC5). The 16-byte session ID serves as the RC5 key. The decrypted packet is then passed to\r\nOnReceivedPacket for processing. The RC5 encryption algorithm works in eight-byte blocks, which is why the encrypted\r\nportion of the packet (a total length of 18) must be a multiple of eight (Figure 15). \r\nhttps://www.trendmicro.com/en_us/research/25/l/ghostpenguin.html\r\nPage 13 of 23\n\nAfter starting the receiver, the malware attempts to register itself with the C\u0026C server by calling RegisterSelfToServer. This\r\nfunction spawns another worker thread, ThreadProcRegisterSelfToServer, and waits up to 10 seconds for it to complete. The\r\nregistration thread gathers system information by creating an instance of the CBasicInfoGather class. This information\r\nincludes:\r\nLAN IP address\r\nDefault gateway (obtained via Netlink sockets)\r\nOS distribution Information (from /etc/redhat-release or /etc/os-release)\r\nHost name\r\nCurrent username (via whoami command)\r\nOS architecture (\"X64\" or \"X86\")\r\nProcess ID (PID)\r\nProcess bitness (hardcoded to 64-bit)\r\nClient architecture ID (32 for Linux x86, 33 for Linux x64)\r\nhttps://www.trendmicro.com/en_us/research/25/l/ghostpenguin.html\r\nPage 14 of 23\n\nThis collected data is serialized into a buffer. The thread then enters a loop, sending this data to the C\u0026C server inside a\r\n\"New Task\" packet. It sends Task ID 1 (Set Status Initializing) while the client status is initializing, and Task ID 3 (Set\r\nStatus Active) when the status is registering (Figure 16). These registration packets are sent every second until the C\u0026C\r\nserver responds with a command that changes the client's status to active.\r\nOnce the malware receives the Session ID, it utilizes it as a key to encrypt and decrypt all packet content starting from offset\r\n0x12 (18). To complete the initialization, the C\u0026C server sends a 'Set Status Active' packet, transitioning the implant into its\r\nfully operational state for command execution (Figure 17).\r\nhttps://www.trendmicro.com/en_us/research/25/l/ghostpenguin.html\r\nPage 15 of 23\n\nSince UDP is a \"connectionless\" protocol (fire-and-forget), it does not guarantee that data arrives. The malware implements\r\nits own reliability layer to ensure commands and results are not lost. To achieve this, it saves a copy of every outgoing\r\npacket such as command output or file data into a global linked list named g_ListPacketToSend. A dedicated background\r\nthread continuously loops through this list and re-sends the packets until the C\u0026C server confirms they were received. This\r\nconfirmation arrives as a specific \"Acknowledgment\" (ACK) packet (Command Type 3). When the malware receives an\r\nACK, the AckPacket function verifies the IDs (Task, Instance, and Sequence) and deletes the packet from the waiting queue.\r\nThis system guarantees that the C\u0026C server receives all data, even if the network drops packets.\r\nOnce registration is successful, two more threads are started: ThreadProcHeartBeat and ThreadProcDataSender (Figure 18).\r\nThe ThreadProcHeartBeat thread periodically sends a 34-byte encrypted heartbeat packet (command 0x00) to the C\u0026C\r\nserver to signal that it is still online. The interval is configurable, with a default of 500 milliseconds.\r\nhttps://www.trendmicro.com/en_us/research/25/l/ghostpenguin.html\r\nPage 16 of 23\n\nThe ThreadProcDataSender thread processes a global queue of outgoing packets (g_ListPacketToSend). It retrieves packets,\r\nencrypts their payload using the session ID as the key, and sends them to the C\u0026C server. This queue has a built-in retry\r\nmechanism; packets are re-queued for transmission until they exceed a defined retry limit. The thread also cleans up stale\r\npackets from expired sessions.\r\nhttps://www.trendmicro.com/en_us/research/25/l/ghostpenguin.html\r\nPage 17 of 23\n\nWith all threads running, the main thread enters a waiting state, sleeping for one-second intervals as long as the client status\r\nremains active.\r\nCommand handling\r\nThe OnReceivedPacket function is the central dispatcher. It first sends an acknowledgment (ACK) packet (command 0x03)\r\nback to the C\u0026C server for any incoming task that requires it. It then dispatches the packet based on its command type. New\r\ntasks (command type 1) are handled by OnReceivedPacketNewTask, which uses a large switch statement on the task ID to\r\ncall the appropriate function.\r\nThe malware supports a wide range of commands, which can be categorized as shown in Table 2:\r\nTask ID Command Name Category Description\r\n1 Set Status Initializing Status\r\nResets client to \"Status 0\". Forces the client to (re)send its OS\r\ninfo and registration packet.\r\n2 Set Status Connecting Status Sets client to \"Status 1\". Client is connecting to C\u0026C server\r\n3 Set Status Active Status\r\nSets client to \"Status 2\". Confirms the connection is successful.\r\nClient begins heartbeating and accepting tasks.\r\n9 Client Offline Control Uninstall and xit\r\n15 RShell Start\r\nRemote\r\nShell\r\nStart remote shell session (fork /bin/sh)\r\n16 RShell Send Data\r\nRemote\r\nShell\r\nSend command to remote shell stdin\r\n17 RShell Stop\r\nRemote\r\nShell\r\nStop remote shell and cleanup\r\nhttps://www.trendmicro.com/en_us/research/25/l/ghostpenguin.html\r\nPage 18 of 23\n\n18 RShell Data Result\r\nRemote\r\nShell\r\nClient sends shell output back to C\u0026C server\r\n19 Get Drives File System List drives/root directory\r\n20 List Directory File System List directory contents with metadata\r\n21 Write File Data File System Write data to existing file at offset\r\n22 Create File File System Create empty file with specified size\r\n23 Create File Success File System ACK: File creation succeeded\r\n24 Create File Failed File System ACK: File creation failed\r\n25 Read File Data File System Read file data from offset\r\n26,27 Delete File File System Delete a file\r\n28 Rename File File System Rename file\r\n29,30,31 Modify File Time File System Modify file timestamp attributes\r\n32 Get File Size File System Get file size in bytes\r\n33\r\nSearch Files by\r\nExtension\r\nFile System Search for files with specific extension\r\n34 Create Directory\r\nDirectory\r\nOps\r\nCreate a new directory\r\n35 Delete Directory\r\nDirectory\r\nOps\r\nDelete Directory (Recursive)\r\n36\r\nModify Directory\r\nTime (Create)\r\nDirectory\r\nOps\r\nModify directory creation time\r\n37\r\nModify Directory\r\nTime (Modify)\r\nDirectory\r\nOps\r\nModify directory modification time\r\n38 Get Directory Data\r\nDirectory\r\nOps\r\nGet detailed directory tree data\r\n39\r\nGet Directory File\r\nSize\r\nDirectory\r\nOps\r\nGet size of file in directory\r\n40\r\nGet Directory File\r\nData\r\nDirectory\r\nOps\r\nGet file data from directory\r\nTable 2. The malware’s commands\r\nFile and directory operations are comprehensive, allowing for full filesystem manipulation, including listing, reading,\r\nwriting, creating, deleting, renaming, and searching for files, as well as creating and deleting directories. Large data\r\ntransfers, such as directory listings and file reads, are fragmented into multiple packets to fit within the UDP payload limits.\r\nThe following code snippets demonstrates the command execution for “List Directory” command (Figure 20) and the\r\nmalware’s response (Figure 21):\r\nhttps://www.trendmicro.com/en_us/research/25/l/ghostpenguin.html\r\nPage 19 of 23\n\nhttps://www.trendmicro.com/en_us/research/25/l/ghostpenguin.html\r\nPage 20 of 23\n\nIf the malware receives the CLIENT_OFFLINE command (Task 9), it sends a confirmation response to the C\u0026C three times,\r\nsets the g_bIsClientExit flag to 1, and changes its status to CLIENT_STATUS_OFFLINE. This signals the main loop to\r\nhttps://www.trendmicro.com/en_us/research/25/l/ghostpenguin.html\r\nPage 21 of 23\n\nbreak, leading to a full teardown. During this teardown, all threads are canceled, resources are uninitialized, and a call to\r\nSelfDel() is made to try to delete the malware's executable from the disk. Finally, the PID file is removed before the process\r\nterminates.\r\nConclusion\r\nHunting low-detection malware like GhostPenguin demands an adaptive approach, as traditional detection methods may not\r\nmeasure up against novel threats. By integrating AI-driven automation, structured intelligence databases, and advanced\r\nprofiling techniques, defenders can systematically sift through vast volumes of data to identify and analyze even the most\r\ninconspicuous malware. Through our investigation into this backdoor, we demonstrate how multi-stage workflows\r\ncombining automated artifact extraction, in-depth decompilation, and layered AI analysis can reveal the architecture and\r\ncommunication methods of threats that would otherwise remain hidden. This case study exemplifies the increasing\r\ncomplexity of modern malware and the critical need for security researchers to continuously evolve their threat hunting\r\nstrategies, combining human expertise with new technologies to outpace more complex adversaries. As attackers continue to\r\nrefine their methods, proactive and intelligence-led defenses can ensure organizations stay resilient against threats like\r\nGhostPenguin.\r\nProactive security with Trend Vision One™\r\nTrend Vision One™ is the only AI-powered enterprise cybersecurity platform that centralizes cyber risk exposure\r\nmanagement and security operations, delivering robust layered protection across on-premises, hybrid, and multi-cloud\r\nenvironments.\r\nTrend Vision One™ Network Security\r\n46704: UDP: Backdoor.Linux.GhostPenguin.A Runtime Detection\r\nHunting Queries  \r\nTrend Vision One Search App \r\nTrend Vision One customers can use the Search App to match or hunt the malicious indicators mentioned in this blog post\r\nwith data in their environment.\r\nLinux Hunting query for GhostPenguin C2.\r\neventSubId:204 AND ((dst:\"65.20.72.101\" AND dpt:53) OR (dst:\"124.221.109.147\"))\r\nIndicators of Compromise (IOCs)\r\nPrimary modules\r\nSHA-256 Description Detection\r\n7b75ce1d60d3c38d7eb63627e4d3a8c7e6a0f8f65c70d0b0cc4756aab98e9ab7 systemd    Backdoor.Linux.GHOSTPENGUIN\r\nC\u0026C servers\r\n65[.]20[.]72[.]101:53\r\nwww[.]iytest[.]com:5679\r\n124[.]221[.]109[.]147:5679\r\nhttps://www.trendmicro.com/en_us/research/25/l/ghostpenguin.html\r\nPage 22 of 23\n\nSource: https://www.trendmicro.com/en_us/research/25/l/ghostpenguin.html\r\nhttps://www.trendmicro.com/en_us/research/25/l/ghostpenguin.html\r\nPage 23 of 23\n\nProcess ID Process bitness (PID) (hardcoded to 64-bit) \nClient architecture ID (32 for Linux x86, 33 for Linux x64)\n   Page 14 of 23",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.trendmicro.com/en_us/research/25/l/ghostpenguin.html"
	],
	"report_names": [
		"ghostpenguin.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434538,
	"ts_updated_at": 1775791277,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/5a27f71fd5fac010be600c54680a46ac9336d113.pdf",
		"text": "https://archive.orkl.eu/5a27f71fd5fac010be600c54680a46ac9336d113.txt",
		"img": "https://archive.orkl.eu/5a27f71fd5fac010be600c54680a46ac9336d113.jpg"
	}
}