{
	"id": "a7267367-ccd9-473f-943f-a464858321b7",
	"created_at": "2026-04-06T00:16:36.663949Z",
	"updated_at": "2026-04-10T03:31:00.977751Z",
	"deleted_at": null,
	"sha1_hash": "304f608225c4f1864ca0dda222f1e749761bec48",
	"title": "Malware Spotlight: Linodas aka DinodasRAT for Linux - Check Point Research",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 122173,
	"plain_text": "Malware Spotlight: Linodas aka DinodasRAT for Linux - Check Point\r\nResearch\r\nBy etal\r\nPublished: 2024-03-31 · Archived: 2026-04-05 14:09:55 UTC\r\nIntroduction\r\nIn recent months, Check Point Research (CPR) has been closely monitoring the activity of a Chinese-nexus cyber espionage\r\nthreat actor who is focusing on Southeast Asia, Africa, and South America. This activity significantly aligns with the insights\r\nthe Trend Micro researchers publicly shared in their comprehensive analysis of a threat actor called Earth Krahang. This\r\nactor’s toolset notably includes a cross-platform backdoor named DinodasRAT, also known as XDealer, which was\r\nalso observed previously in attacks by the Chinese threat actor LuoYu.\r\nThe Windows version of this malware was thoroughly analyzed by ESET, but its Linux counterpart has not garnered much\r\npublic interest. In this blog post, we share our full technical analysis of the latest Linux version (v11) of DinodasRAT, which\r\nwe track as Linodas. It appears to be more mature than the Windows version, with a set of capabilities tailored specifically\r\nfor Linux servers. In addition, the latest version introduces a separate evasion module to hide any traces of malware in the\r\nsystem by proxying and modifying the system binaries’ execution.\r\nWhile we finalized this blog spot, a technical analysis of an older V10 version of the Linux RAT was published by\r\nresearchers from Kaspersky. Although it overlaps with our findings to some extent, our report provides additional\r\ninformation on the advancements in the latest version (v11) of the Linux RAT.\r\nDinodas Origins\r\nSeveral hints indicate that DinodasRAT was initially based on the open-source project called SimpleRemoter, a remote\r\naccess tool based in turn on the Gh0st RAT, but with several additional upgrades. Similarities between SimpleRemoter and\r\nan older version of Dinodas RAT  include the usage of the same zlib library version 1.2.11, and overlaps in the code, such as\r\nthe OS version detection function which is nearly identical:\r\nFigure 1 – Similarities in the OS version detection function between the Dinodas sample (left) and the open-source code.\r\nhttps://research.checkpoint.com/2024/29676/\r\nPage 1 of 10\n\nWhile we can’t say definitively that DinodasRAT developers reused the entire source code, it is clear that they were inspired\r\nby it at least regarding the C2 command functionality which shows significant similarities between the two RATs.\r\nWe also observed additional open-source code usage in the DinodasRAT code from another repository created by the same\r\ndeveloper. In this case, the DinodasRAT authors used functionality related to handling the INI files.\r\nThe final example of reusing open-source code is the developers’ choice for encryption. Instead of implementing their own\r\nmethod, they decided to go with the encryption used in QQ.\r\nLinodas as a Separate Code Base\r\nEach sample of the cross-platform DinodasRAT embeds a string containing the backdoor’s internal version. Inside the Linux\r\nsamples (that we track as Linodas), we observed the following strings that reflect the backdoor evolution:\r\nMark\r\nFirst\r\nseen\r\nHashes\r\nLinux_%s_%s_%u_V7\r\nJuly\r\n2021\r\n3d93b8954ed1441516302681674f4989bd0f20232ac2b211f4b601af0fcfc13b\r\nbf830191215e0c8db207ea320d8e795990cf6b3e6698932e6e0c9c0588fc9eff\r\nLinux_%s_%s_%u_V10\r\nJan\r\n2023\r\n15412d1a6b7f79fad45bcd32cf82f9d651d9ccca082f98a0cca3ad5335284e45\r\nLinux_%s_%s_%u_V11\r\nNov\r\n2023\r\n6302acdfce30cec5e9167ff7905800a6220c7dda495c0aae1f4594c7263a29b2\r\nebdf3d3e0867b29e66d8b7570be4e6619c64fae7e1fbd052be387f736c980c8e\r\n(embedded module)\r\nThe earliest Linux version we retrieved was first seen in the wild in July 2021. However, this version is numbered internally\r\nas v7, which indicates that the development of the malware started earlier. In comparison, at the same time the Windows\r\nbranches of the backdoor included  Rin_%s_%s_%u_V6  and  Win_%s_%s_%u_V6  versions.\r\nWhile Linodas shares logic with the Windows variant, it also adds its own set of behaviors designed specifically for Linux\r\nservers. The authors appear to be proficient in Linux, as their choice to support the OS was not just a simple #ifdef variant of\r\na Windows RAT but a different project with a separate code base and possibly a different development team. Looking at the\r\nlatest Linodas version (v11), we can also observe a Windows sample communicating with the same C2\r\nserver  update.microsoft-setting[.]com :\r\nVersion\r\nOperating\r\nSystem\r\nHash\r\nLinux_%s_%s_%u_V11 Linux 6302acdfce30cec5e9167ff7905800a6220c7dda495c0aae1f4594c7263a29b2\r\nWin_%s_%s_%u_V10 Windows 57f64f170dfeaa1150493ed3f63ea6f1df3ca71ad1722e12ac0f77744fb1a829\r\nTwo samples that have different internal versions may indicate that there are two different development teams, or at least\r\ntwo backdoors in different development stages communicating with the same C2 server. The Linux and Windows versions\r\nhave overlapping command IDs, seamlessly supporting the same malware functionality for different operating systems.\r\nThe implant is installed on Linux servers as a way for the threat actors to gain an additional foothold in the network. Most of\r\nthe samples we found have the name ntfsys, apparently attempting to masquerade as a system or driver file related to NTFS.\r\nhttps://research.checkpoint.com/2024/29676/\r\nPage 2 of 10\n\nIn our technical analysis, we split the logic of the RAT into several parts for easier comprehension.\r\nInitial Startup\r\nLinux is different from Windows; persistence is different than it is in Windows, execution permissions need to be ensured,\r\nand so on. The Linux backdoor handles those functions quite well. Once the backdoor is executed, it verifies if it’s the first\r\nrun by checking if it received two arguments: the letter  d , and the calling daemon process ID. If those arguments are\r\nabsent, the backdoor calls the daemon function and establishes persistence on the system. It then re-runs itself again\r\nproperly: it gets the process ID and the self-execution path, and executes the command  [SELF_PATH] d [SELF_PID]  through\r\nthe  system  function.\r\nPersistence methods\r\nThe persistence process is quite extensive and covers multiple Ubuntu versions and RedHat distributions. It first checks for\r\nthe current OS version by reading the files  /proc/version  and  etc/lsb-release  and parsing the output. Then, based on\r\nthe gathered data, it achieves persistence by one of the following methods:\r\nMethod 1 (Ubuntu) – rc.local enabled via systemd\r\nThe malware first checks if the file  /lib/systemd/system/rc.local.service  doesn’t exist and then proceeds to write the\r\nfollowing string into it:\r\nDescription=/etc/rc.local Compatibility\r\nConditionFileIsExecutable=/etc/rc.local\r\nExecStart=/etc/rc.local start\r\n[Unit] Description=/etc/rc.local Compatibility ConditionFileIsExecutable=/etc/rc.local After=network.target [Service]\r\nType=forking ExecStart=/etc/rc.local start TimeoutSec=0 RemainAfterExit=yes\r\n [Unit]\r\n Description=/etc/rc.local Compatibility\r\n ConditionFileIsExecutable=/etc/rc.local\r\n After=network.target\r\n \r\n [Service]\r\n Type=forking\r\n ExecStart=/etc/rc.local start\r\n TimeoutSec=0\r\n RemainAfterExit=yes\r\nIt then creates the following symlink  /lib/systemd/system/rc.local.service  →  /etc/systemd/system/ . Next, it checks\r\nif the file  /etc/rc.local  exists, and if it does, it adds the following string to it:\r\n#!/bin/bash [SELF_FILE_PATH] exit 0\r\n#!/bin/bash\r\n[SELF_FILE_PATH]\r\nexit 0\r\nhttps://research.checkpoint.com/2024/29676/\r\nPage 3 of 10\n\nIt then makes the  /etc/rc.local  file executable by calling the command  chmod 777  on it, and then validates that the\r\npersistence was written correctly into it, ensuring the self path is the actual self file path. Then, it changes the following INI\r\nfields in the  /lib/systemd/system/rc.local.service  file:\r\nWantedBy=multi-user.target\r\n[Service] RemainAfterExit=no [Install] WantedBy=multi-user.target Alias=rc-local.service\r\n[Service]\r\nRemainAfterExit=no\r\n[Install]\r\nWantedBy=multi-user.target\r\nAlias=rc-local.service\r\nMethod 2 (Red Hat) – init.d script \r\nThe backdoor first runs the command  where chkconfig  parses the output and tries to execute  chkconfig . If the command\r\nis found and runs correctly, it adds it to the  PATH  environment variable and proceeds to do the actual persistence. It checks\r\nif the file  /etc/init.d/[SELF_FILE_NAME]  doesn’t exist, then proceeds to write the following string into it:\r\n# Provides: [SELF_FILE_NAME]\r\n# Required-Start: $local_fs $network\r\n# Required-Stop: $local_fs\r\n# Short-Description: [SELF_FILE_NAME] service\r\n# Description: [SELF_FILE_NAME] service daemon\r\n#!/bin/sh ### BEGIN INIT INFO # Provides: [SELF_FILE_NAME] # Required-Start: $local_fs $network # Required-Stop:\r\n$local_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: [SELF_FILE_NAME] service # Description:\r\n[SELF_FILE_NAME] service daemon ### END INIT INFO [SELF_FULL_ATH] restart\r\n#!/bin/sh\r\n### BEGIN INIT INFO\r\n# Provides: [SELF_FILE_NAME]\r\n# Required-Start: $local_fs $network\r\n# Required-Stop: $local_fs\r\n# Default-Start: 2 3 4 5\r\n# Default-Stop: 0 1 6\r\n# Short-Description: [SELF_FILE_NAME] service\r\n# Description: [SELF_FILE_NAME] service daemon\r\n### END INIT INFO\r\n[SELF_FULL_ATH] restart\r\nIf the file wasn’t created, it writes the same data to the file  /etc/ch.sh  and executes the command  mv /etc/ch.sh\r\n/etc/init.d/[SELF_FILE_NAME]  then runs the command  chmod 777  on the created file and executes it. Then, it begins\r\nvalidating the persistence by running the command  chkconfig --list | grep [SELF_FILE_NAME] . If the result doesn’t\r\ncontain  6: , it runs the following two commands:\r\nhttps://research.checkpoint.com/2024/29676/\r\nPage 4 of 10\n\nchkconfig --add [SELF_FLE_NAME]\r\nchkconfig zentao [SELF_FLE_NAME]\r\nchkconfig --add [SELF_FLE_NAME] chkconfig zentao [SELF_FLE_NAME]\r\nchkconfig --add [SELF_FLE_NAME]\r\nchkconfig zentao [SELF_FLE_NAME]\r\nMethod 3 (Red Hat) – rc.local \r\nPersistence is done through the  /etc/rc.d/rc.local  file. file. If the file exists, the backdoor checks if the self-path is\r\ninside the contents, and if not, adds itself to the file with the string  \\n[SELF_PATH]\\n .\r\nCore Logic\r\nAfter the backdoor is run properly with 2 arguments, it proceeds to the main logic. First, it performs a set of checks such as\r\nthe root privilege, its path/folder, and the calling daemon process ID, and saves them all in global variables. It then changes\r\nits file timestamp using the following command:  touch -d \\\"2010-09-08 12:23:02\\\" [SELF_FILE_PATH] . This timestamp\r\nis also set to other backdoor-related files such as the config files when accessing them. This enables the files to “blend in”\r\nwith the other files in the filesystem.\r\nNext, it reads a config file based on the hardcoded string  /etc/.netsc.conf . The config files for all the samples are usually\r\nhidden files. From the config, it attempts to read a field called  imei  under the  para  section. This field represents the bot\r\nID generated for the infected machine. If this field doesn’t exist in the config, a unique machine ID is generated based on\r\nmachine parameters in the following way:\r\n1. Get the machine’s MAC address by running an  ifconfig  or  ip  command and extract the MAC address from the\r\noutput. This is OS distribution-dependent.\r\n2. Run the command  dmidecode , which dumps the system’s SMIBIOS.\r\n3. Combine the MAC address and the output from  dmidecode  and perform md5sum.\r\n4. Generate a random number.\r\n5. Generate a timestamp based on the current time.\r\nAll of those fields are combined in the following string:  Linux_[TIMESTAMP]_[MD5SUM]_[RANDOM NUMBER]_V11 . For\r\nexample:  Linux_20240310_11cb06d0bf454c3708a3658c2601ea16_40459_V11 .\r\nAfter generation, the bot ID is saved to the config file, and the config file timestamp is also changed in a way similar to how\r\nit’s done for the executable.\r\nNext, the backdoor does basic system enumeration to get the distribution, exact OS version, and system architecture. All\r\nthose values are saved in global variables and are used later when the backdoor contacts the C2 for the first time. The\r\nhardcoded C2 address (in the latest version,  update.microsoft-setting[.]com:443  ) is parsed and saved in a global struct,\r\nand the malware reads two more config fields,  mode , and  checkroot , from the  para  section. The  mode  field serves as\r\nthe type of C2 communication to use, TCP or UDP. The  checkroot  indicates if the backdoor should be monitoring logged-in users. After the initial configuration, the backdoor proceeds to create several threads which are used for monitoring and\r\ncleanup, and initiates the connection to the C2 server.\r\nMonitoring/Cleanup Threads\r\nhttps://research.checkpoint.com/2024/29676/\r\nPage 5 of 10\n\nThe backdoor creates five threads tasked with system monitoring, helper module download, and cleanup of old reverse shell\r\nconnections..\r\nThread #1: Logged-in user monitor. If the  mode  field in the config or the global variable for  mode  is set to 1, meaning\r\nthe connection type is TCP, this thread monitors logged-in users using the who command. It parses its output and closes the\r\nC2 connection if the logged-in IP is not a local IP or the C2 IP.\r\nThread #2: C2 connection status monitoring. Each time a valid request is made to the C2, the time field in the global C2\r\nconnection struct is updated. If half an hour passed since the last request to the C2, the thread closes the connection to the\r\nC2.\r\nThread #3: Filter module download and setup. The thread first verifies that the module wasn’t already downloaded\r\n(through the use of a global variable). If it wasn’t, the thread performs the following steps:\r\n1. Check if the file  [SELF_PATH].so6  exists and calculate an md5 hash of its content.\r\n2. Send an encrypted request to the C2, requesting the md5 hash of a module available on the C2 server, and compare\r\nthe received md5 hash with the existing one.\r\n3. If the hash is different, make another request to the C2 and save a newly received file with the same name.\r\n4. Read data from the file  /usr/lib/libsysattr.so , likely dropped at an earlier stage of infection. This file should\r\ncontain a set of values separated by the character  |  and represents a set of instructions for executables to be\r\nreplaced.\r\n5. Locate in the system each file specified in the instructions file and backup it with a name in the following\r\nformat:  [FILE_NAME].a . Then replace the original file with the newly received so6 filter module and make it\r\nexecutable.\r\nAll these steps allow the threat actors to wrap certain system executables to control their output, which is detailed later in the\r\ndedicated “Filter module” section.\r\nThread #4: Logged-in users monitor and logging. If a user is logged in to the Linux machine and its IPv4 is not a local\r\nIPV4 or one of the C2s, its details are logged and sent to the C2 server.\r\nThread #5: Reverse shell old sessions cleanup. This thread monitors reverse shell sessions. If there is a reverse shell\r\nsession that was not active for the last 3599 seconds (almost one hour), the session is removed.\r\nC2 Communication\r\nBefore the C2 communication starts, two global structs are checked: one contains the config value indicating whether to use\r\nTCP or UDP when connecting to the C2, and the other one indicates whether the C2 communication should cease if there\r\nare logged-in users. If any of those checks fail, communication with the C2 is not initiated. If the checks pass, the backdoor\r\nparses the C2 address (host and port) and resolves a C2 domain to IPv4 if needed.\r\nNext, the malware sets up a socket in TCP or UDP mode, based on the configuration, and attempts to connect to the C2. If\r\nthe connection is successful, a thread to parse C2 commands is spawned. The C2 commands supported in the latest version\r\nof the backdoor are detailed in the next section.\r\nAfter this initial connection to the C2 server is set and the C2 command thread is created, an endless loop is executed which\r\nis responsible for sending a heartbeat to the C2 server. The heartbeat contains the following values combined and separated\r\nby  \\t :\r\nDistribution info\r\nSystem architecture\r\nhttps://research.checkpoint.com/2024/29676/\r\nPage 6 of 10\n\nThe string “root”\r\nConstant value 0xC\r\nUDP packet length 800\r\nSelf path\r\nIf the request to the C2 failed, the connection to the C2 is reestablished, and the heartbeat string is generated and sent again.\r\nSupported C2 Commands\r\nSimilar to the Windows backdoor, the Linux backdoor supports a wide range of capabilities. In the following table, we\r\noutline all of them and indicate whether they exist in the Windows version of the backdoor.\r\nId Description Arguments\r\nExists in\r\nWindows\r\nVersion\r\n0x02\r\nList files and directories under a specified\r\nfolder\r\nFolder name ✔️\r\n0x03 Delete files or directories\r\nList of files or directories\r\nseparated by \u0026\u0026 ✔️\r\n0x05 Send files to the C2\r\nRequest ID, file list separated\r\nby \u0026\u0026 ✔️\r\n0x06 Stop the “send files” command – ✔️\r\n0x08\r\nDownload a file from the C2 and execute\r\nit (if a flag is enabled)\r\nExecute flag, Filename, File\r\ndata, all separated by \\t ✔️\r\n0x09 Stop the “download file” command – ✔️\r\n0x0E Update C2 URL\r\nList of C2 URLs separated by\r\n\\t ✔️\r\n0x0F Enumerate logged-in users –\r\n0x11 Enumerate running processes – ✔️\r\n0x12 Kill process Process ID to kill ✔️\r\n0x13 Enumerate running services – ✔️\r\n0x14 Start/Stop service\r\nService name, action type,\r\nseparated by \\t.\r\nAction type can be one of the\r\nfollowing:\r\n1 – start service\r\n0 – stop service\r\n2 – stop and delete service\r\n✔️\r\nhttps://research.checkpoint.com/2024/29676/\r\nPage 7 of 10\n\nId Description Arguments\r\nExists in\r\nWindows\r\nVersion\r\n0x18\r\nExecute a process and send the response\r\nback\r\nProcess path to execute ✔️\r\n0x19 Make a file executable and execute it\r\nReceive maybe multiple files\r\nto execute separated by \\t ✔️\r\n0x1A Start/Stop/Get State for HTTP proxy Integer value\r\n0x1B Reverse shell start – ✔️\r\n0x1C Reverse shell restart –\r\n0x1D Reverse shell close –\r\n0x1E Write to reverse shell\r\nBinary values split by\r\n\\0x01\\0x02\r\n0x27 Rename/copy/move file\r\nAction type, file path, new\r\npath ✔️\r\n0x28 Send “ok” to the C2 – ✔️\r\n0x2B Change proxy connection type Integer value ✔️\r\n0x2C Set proxy type Integer value ✔️\r\n0x2D Change file transfer mode Integer, Integer value ✔️\r\n0x2E\r\nSelf-fully uninstall, remove persistence,\r\nkill the parent daemon, and exit\r\n– ✔️\r\n0x31\r\nUpdate a global integer value used as the\r\nUDP packet length\r\nInteger value ✔️\r\n0x32 Read a file and return its contents file path, max bytes to read\r\n0x33 Write data to a file\r\nfile path, bytes to write in hex\r\nstring\r\n0x34\r\nCollect user activity through various files\r\nsuch as:\r\n/var/run/utmp\r\n/var/log/wtmp\r\n/var/log/lastlog\r\n–\r\n0x35 Parse and send the /usr/lib/libsysattr.a file –\r\n0x36\r\nParse data and write to /usr/lib/libsysattr.a\r\nfile\r\nFields separated by \\t\r\nhttps://research.checkpoint.com/2024/29676/\r\nPage 8 of 10\n\nThe Filter Module\r\nAs mentioned previously, in Linodas v11, Thread #3 is responsible for downloading an additional module which replaces\r\nany specified binaries in the system. None of the previous versions support this functionality.\r\nThe filter module we received from the actor-controlled C\u0026C server by running  ntfsys  (v11) is saved\r\nas  ntfsys.so6  (sha256:  ebdf3d3e0867b29e66d8b7570be4e6619c64fae7e1fbd052be387f736c980c8e ).\r\nFigure 2 – File detections for the Filter module when first seen in the wild in November 2023.\r\nAs described earlier, the installation thread substituted certain binaries in the system with the filter module. The module\r\npurpose is to proxy the execution of these binaries and control their output. This is how it’s done step by step:\r\nFigure 3 – A diagram of the execution of a system binary “wrapped” by the filter module modifying its output\r\nin real time.\r\n1. The module starts every time the system tries to use the replaced binary, with or without arguments.\r\n2. When executed, the module checks if the config file in  /usr/lib/libsysattr.a  exists. This separate configuration\r\nfile is not downloaded together with the module and is likely placed by the threat actors into the server using the\r\nLinodas reverse shell. From  para  section of the configuration file, the module loads two fields,  ip  and  name .\r\n3. The module combines all of the arguments it received, separates them with spaces, and checks if the original binary\r\nwith the name  [SELF_PATH].a  If it doesn’t, it outputs the  bash shell  and exits. If the file exists, it executes it with\r\nthe arguments received and appends string  2\u003e\u00261  which merges the error output with the standard output, so both\r\ncan be manipulated or viewed together.\r\nhttps://research.checkpoint.com/2024/29676/\r\nPage 9 of 10\n\n4. While the module executes the subprogram, it reads chunks of the output and splits them by line. Each line goes\r\nthrough a filtering process, where the line containing any of the values for  ip  or  name  from the config is ignored.\r\nIf the line passes the filtering, it is printed.\r\nThe threat actors are likely using this module as a poor man’s “rootkit”, allowing them to filter any values, such as IP,\r\nusername, process name, or other artifacts, from various information-gathering binaries such as  who ,  netstat ,  ps , etc.\r\nThis enables them to hide the presence of Linodas and its artifacts from any monitoring efforts by vigilant victims.\r\nConclusion\r\nIn this blog post, we analyzed the Linux version of DinadasRAT, used by Chinese-nexus APT threat actors and observed\r\nsince at least 2021. While there are multiple similarities with the Windows version, the Linux malware indicates a separate\r\nand independent development branch that introduces auxiliary modules with separate configuration files, and additional C2\r\ncommands focused on establishing and controlling reverse shells, collecting user activity from the logs, and manipulating\r\nlocal file content.\r\nThe complexity and capabilities of Linodas highlight the continued emphasis by threat actors on targeting Linux servers\r\nboth as a method for maintaining presence and as a pivot point within compromised networks. This approach likely exploits\r\nthe typically lower level of security protocols and solutions usually installed on Linux boxes, allowing the attackers to\r\nextend their foothold and remain undetected for longer periods.\r\nProtections\r\nCheck Point Customers remain protected against attacks detailed in this report while using Check Point Harmony\r\nEndpoint and Threat Emulation:\r\nBackdoor.Win.OperationJacana.A\r\nTrojan.Wins.Jacana.ta.*\r\nBackdoor_Linux_DinodasRAT_*\r\nIOCs\r\nType Value\r\nSHA256 3d93b8954ed1441516302681674f4989bd0f20232ac2b211f4b601af0fcfc13b\r\nSHA256 bf830191215e0c8db207ea320d8e795990cf6b3e6698932e6e0c9c0588fc9eff\r\nSHA256 15412d1a6b7f79fad45bcd32cf82f9d651d9ccca082f98a0cca3ad5335284e45\r\nSHA256 98b5b4f96d4e1a9a6e170a4b2740ce1a1dfc411ada238e42a5954e66559a5541\r\nSHA256 a2c3073fa5587f8a70d7def7fd8355e1f6d20eb906c3cd4df8c744826cb81d91\r\nSHA256 ebdf3d3e0867b29e66d8b7570be4e6619c64fae7e1fbd052be387f736c980c8e\r\nSHA256 6302acdfce30cec5e9167ff7905800a6220c7dda495c0aae1f4594c7263a29b2\r\nSource: https://research.checkpoint.com/2024/29676/\r\nhttps://research.checkpoint.com/2024/29676/\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://research.checkpoint.com/2024/29676/"
	],
	"report_names": [
		"29676"
	],
	"threat_actors": [
		{
			"id": "b72c2616-cc7c-4c47-a83d-6b7866b94746",
			"created_at": "2023-01-06T13:46:39.425297Z",
			"updated_at": "2026-04-10T02:00:03.323082Z",
			"deleted_at": null,
			"main_name": "Red Nue",
			"aliases": [
				"LuoYu"
			],
			"source_name": "MISPGALAXY:Red Nue",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434596,
	"ts_updated_at": 1775791860,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/304f608225c4f1864ca0dda222f1e749761bec48.pdf",
		"text": "https://archive.orkl.eu/304f608225c4f1864ca0dda222f1e749761bec48.txt",
		"img": "https://archive.orkl.eu/304f608225c4f1864ca0dda222f1e749761bec48.jpg"
	}
}