{
	"id": "fae08f3d-fb27-4968-9be6-f3c0a223775c",
	"created_at": "2026-04-06T00:06:32.017317Z",
	"updated_at": "2026-04-10T03:34:59.738881Z",
	"deleted_at": null,
	"sha1_hash": "4194845fcc857621588d96cd2edc0b8246923d5e",
	"title": "Connecting Kinsing malware to Citrix and SaltStack campaigns",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 124221,
	"plain_text": "Connecting Kinsing malware to Citrix and SaltStack campaigns\r\nBy susannah.matt@redcanary.com\r\nPublished: 2020-07-22 · Archived: 2026-04-05 22:20:58 UTC\r\nKinsing, a malware family distributed by the H2Miner botnet, is known for targeting Linux-based infrastructure\r\nsystems including Docker container hosts, Redis instances, and (in recent weeks) Salt servers.\r\nUp to this point, the security firm Intezer and an individual known as “Blackorbird” on Twitter have published\r\nevidence linking Kinsing to a Salt exploitation campaign from early May 2020.\r\nRed Canary has uncovered additional evidence linking the Kinsing malware family to Salt server attack\r\ncampaigns, and, in turn, how these attacks seem to relate to the Citrix ADC/Netscaler exploits from earlier in the\r\nyear. This post includes a comparison of publicly available research from various sources, some manual analysis\r\nof binaries collected from VirusTotal, and additional research based on observations across the environments that\r\nRed Canary monitors.\r\nIf you give a monkey a typewriter and infinite time, he’ll eventually\r\nproduce some groundbreaking threat intelligence.\r\nEstablishing Kinsing\r\nDocker \u0026 Redis host exploitation\r\nOne of the better-documented H2Miner/Kinsing campaigns occurred from December 2019 to March 2020 and\r\nwas documented by Aqua Security. In this campaign, the H2Miner botnet exploited misconfigured Docker Engine\r\nAPI ports to deploy a compromised Docker container. The entry point for the compromised container would\r\ndownload and execute a script, d.sh .\r\nConsistent with other opportunistic miner threats documented here and elsewhere, the d.sh script attempted to\r\nstop and remove other potential cryptocurrency miners from victim systems in addition to some security tools.\r\nFinally, the script downloaded a Golang-based remote administration tool (RAT) and established persistence via a\r\ncron job. This cron persistence would repeat the infection process and keep the RAT running.\r\nEventually, the malware would attempt to execute a script for lateral movement. To achieve this, a script would\r\nenumerate all SSH known hosts and potential keys from known-hosts , authorized-keys , .bash-history , and\r\nother files. Once a list of hosts and keys are gathered, the script issues ssh commands to move laterally around\r\nthe environment and deploy itself.\r\nGolang RAT\r\nThe primary malware deployed during Docker host exploitation was a Golang-based RAT named kinsing . In\r\nthe deployment scripts, the RAT was even named kinsing during downloads for execution. It bears mentioning\r\nhttps://redcanary.com/blog/kinsing-malware-citrix-saltstack/\r\nPage 1 of 10\n\nthat while kinsing is a tool used by the H2Miner cryptocurrency miner botnet, the RAT itself is separate from\r\nthe mining component. The RAT uses the go-resty, gopsutil, osext, and diskv Go libraries for multiple tasks\r\nrelated to command and control (C2), process monitoring, and execution.\r\nResearchers from Alibaba Cloud analyzed Kinsing in January 2020 as part of an investigation into the H2Miner\r\nbotnet and tied it to the exploitation of vulnerable Redis servers. In their analysis, they identified multiple function\r\nsymbols, including some with the the following names:\r\nbackconnect\r\ncheckHealth\r\nconnectForSocks\r\ndownloadAndExecute\r\ngetMinerPid\r\nisMinerRunning\r\nrunTask\r\nmasscan\r\nAnalysis by Lacework revealed an additional point of interest: the Kinsing malware often contains the complete\r\nplay of Hamlet by William Shakespeare as a measure to slow analysis.\r\nTrend Micro’s analysis indicated that Kinsing supported several commands from C2 with data reported back in the\r\nC2 URL with special formatting. In these cases, it appeared that these C2 URL fields included:\r\n/get\r\n/h\r\n/getT\r\n/l\r\n/o\r\n/r\r\n/s\r\n/mg\r\n/ms\r\nIn each campaign where Kinsing is used, the RAT binary contains a hardcoded filename where it will deploy a\r\nXMRIG Monero miner binary.\r\nIn our analysis at Red Canary, we noticed an additional point of interest: Kinsing’s masscan functionality is\r\nimplemented by unpacking a firewire.sh shell script containing code to install libpcap dependencies and\r\nexecute masscan as the process name firewire . The command line for this execution followed this pattern:\r\nfirewire -iL \u003cinput list\u003e --rate \u003crate\u003e -p\u003cports\u003e -oL \u003coutput list\u003e 2\u003e/dev/null\r\nDeployed XMRIG\r\nhttps://redcanary.com/blog/kinsing-malware-citrix-saltstack/\r\nPage 2 of 10\n\nIn both the Redis and Docker host exploitation campaigns the Kinsing RAT went on to deploy and execute an\r\nXMRIG Monero miner process. In the case of the Docker host campaign, it was named kdevtmpfsi .\r\nDuring our analysis, the binary contained all the properties we’d expect of an unprotected XMRIG executable.\r\nMultiple binary strings matched XMRIG usage options in plaintext as well as expected version numbers.\r\n-o, --url=URL URL of mining server\r\n-a, --algo=ALGO mining algorithm https://xmrig.com/docs/algorithms\r\n--coin=COIN specify coin instead of algorithm\r\n-u, --user=USERNAME username for mining server\r\n-p, --pass=PASSWORD password for mining server\r\n-O, --userpass=U:P username:password pair for mining server\r\n-k, --keepalive send keepalived packet for prevent timeout (needs pool support)\r\n--nicehash enable nicehash.com support\r\n--rig-id=ID rig identifier for pool-side statistics (needs pool support)\r\n-r, --retries=N number of times to retry before switch to backup server (default: 5)\r\n-R, --retry-pause=N time to pause between retries (default: 5)\r\n--user-agent set custom user-agent string for pool\r\n--donate-level=N donate level, default 5%% (5 minutes in 100 minutes)\r\n--donate-over-proxy=N control donate over xmrig-proxy feature\r\n--no-cpu disable CPU mining backend\r\n-t, --threads=N number of CPU threads\r\n-v, --av=N algorithm variation, 0 auto select\r\n--cpu-affinity set process affinity to CPU core(s), mask 0x3 for cores 0 and 1\r\n--cpu-priority set process priority (0 idle, 2 normal to 5 highest)\r\n--cpu-max-threads-hint=N maximum CPU threads count (in percentage) hint for autoconfig\r\n--cpu-memory-pool=N number of 2 MB pages for persistent memory pool, -1 (auto), 0 (disable)\r\n--cpu-no-yield prefer maximum hashrate rather than system response/stability\r\n--no-huge-pages disable huge pages support\r\n--asm=ASM ASM optimizations, possible values: auto, none, intel, ryzen, bulldozer\r\n--randomx-init=N threads count to initialize RandomX dataset\r\n--randomx-no-numa disable NUMA support for RandomX\r\n--randomx-mode=MODE RandomX mode: auto, fast, light\r\n--randomx-1gb-pages use 1GB hugepages for dataset (Linux only)\r\n--randomx-wrmsr=N write value (0-15) to Intel MSR register 0x1a4 or do nothing (-1) (Linux only)\r\n-S, --syslog use system log for output messages\r\n-l, --log-file=FILE log all output to a file\r\n--print-time=N print hashrate report every N seconds\r\n--no-color disable colored output\r\n--verbose verbose output\r\n-c, --config=FILE load a JSON-format configuration file\r\n-B, --background run the miner in the background\r\n-V, --version output version information and exit\r\n-h, --help display this help and exit\r\n--dry-run test configuration and exit\r\n--export-topology export hwloc topology to a XML file and exit\r\nXMRig 5.4.0\r\nhttps://redcanary.com/blog/kinsing-malware-citrix-saltstack/\r\nPage 3 of 10\n\nbuilt on Dec 22 2019 with GCC\r\nfailed to export hwloc topology.\r\nhwloc topology successfully exported to \"%s\"\r\nUsage: xmrig [OPTIONS]\r\nIn addition to this confirmation of XMRIG’s presence, the adversary included plaintext configuration data\r\nembedded into the binary. Often when the official XMRIG releases are used, an operator supplies a config.json\r\nfile with all the information needed to make the miner work. In the case of this binary, the contents of\r\nconfig.json were embedded, disclosing details we can use for tracking the H2Miner campaigns. While the\r\nconfiguration was fairly generic, one piece of information stood out: the Monero wallet address.\r\n\"background\": true,\r\n\"donate-level\": 0,\r\n\"cpu\": true,\r\n\"colors\": false,\r\n\"opencl\": false,\r\n\"pools\": [\r\n\"coin\": \"monero\",\r\n\"algo\": null,\r\n\"url\": \"xmr-eu1.nanopool.org\",\r\n\"user\": \"46V5WXwS3gXfsgR7fgXeGP4KAXtQTXJfkicBoRSHXwGbhVzj1JXZRJRhbMrvhxvXvgbJuyV3GGWzD6JvVMuQwAXxLZmTWkb\",\r\n\"pass\": \"mine\",\r\n\"tls\": false,\r\n\"keepalive\": true,\r\n\"nicehash\": false\r\nLinking Kinsing to SaltStack\r\nGolang RAT + Monero miner\r\nIn May 2020, security vendors linked Kinsing to an additional campaign: one exploiting SaltStack CVE-2020-\r\n11651 and CVE-2020-11652. Initial reports were posted via Twitter and were later followed by reporting from\r\nvarious sources. Intezer took the lead on this documentation, demonstrating through an analysis of code\r\nsimilarities that the samples seen in SaltStack exploits were related to the Kinsing RAT. In this section, I want to\r\nwalk through some of the similarities between the Kinsing RAT used in the SaltStack campaign relative to\r\nmalware used in previous campaigns because it will prove useful to further tie Kinsing to additional exploitation\r\nactivity.\r\nFirst, in observing the TTPs involved for the SaltStack campaign, we can determine the affected SaltStack\r\nservices were exploited to download and execute scripts that are similar to the function and structure of previous\r\nKinsing campaigns. The actor shows the tendency to use single-letter names on their shell scripts, move laterally\r\nvia SSH, manipulate cron jobs for persistence, and perform md5sum hash checking to verify malware integrity\r\nbefore execution.\r\nhttps://redcanary.com/blog/kinsing-malware-citrix-saltstack/\r\nPage 4 of 10\n\nIn the execution of the malware, two binaries showed up: a Golang-based RAT and a XMRIG miner. This matches\r\nprevious Kinsing campaigns.\r\nMatching Monero wallet address\r\nOne of the strongest ties between the SaltStack campaign and the previous H2Miner/Kinsing campaigns is the\r\npresence of a shared Monero wallet address:\r\n46V5WXwS3gXfsgR7fgXeGP4KAXtQTXJfkicBoRSHXwGbhVzj1JXZRJRhbMrvhxvXvgbJuyV3GGWzD6JvVMuQwAXxLZmTWkb\r\nThis wallet address appeared in miner samples from the Docker host, Redis, and SaltStack compromises. As in\r\nprevious samples, the ones from the SaltStack campaign contained an embedded JSON-formatted configuration\r\nfile for XMRIG.\r\nThis does not necessarily indicate that all the campaigns were performed by the same actor, but it does suggest\r\nthat the funds from all the campaigns made a stop in the same account/wallet before distribution. After entering\r\nthis wallet, the funds could funnel through a laundering operation or the operators could convert it to different\r\ncurrencies for distribution.\r\n The play’s the thing: Hamlet in the binary strings\r\nAnother piece of evidence tying the SaltStack campaign to previous H2Miner/Kinsing campaigns was the\r\npresence of the text of Hamlet by William Shakespeare, in its entirety, in the RAT’s binary strings. This additional\r\ntext bloated the RAT binary to 15MB in size and provided some entertainment during analysis of the malware. In\r\nall reality, the padding didn’t prove to slow down analysis greatly. Its inclusion could reflect the adversary’s desire\r\nto increase the malware’s file size, as antivirus configurations sometimes exclude files above a specified size.\r\nEmbedded “masscan” script in binary\r\nAnother piece of familiar evidence appeared in the salt-store Golang RAT binary from the SaltStack\r\ncampaign: an embedded shell script that incorporated masscan functionality. As with the previous campaigns,\r\nthe embedded shell script deployed dependencies, referred to the masscan binary as “firewire,” and called\r\nmasscan with the exact same command-line arguments.\r\nLinking Kinsing to Citrix ADC\r\nGolang RAT + Monero miner\r\nIn January 2020, the year started off with several malware families conducting campaigns against Citrix\r\nApplication Delivery Controller (ADC) devices via CVE-2019-19781. While Kinsing and H2Miner have not been\r\nformally tied to an ADC campaign, we’ve found enough evidence in both public research and our own analysis to\r\nassess with high confidence that Kinsing malware was used in the ADC campaign.\r\nDuring one campaign, a Golang RAT and Monero miner component appeared in Citrix ADCs. An awesome blog\r\npost from IronNet discusses these findings in detail. First, IronNet dove into analysis of a malicious nspps\r\nhttps://redcanary.com/blog/kinsing-malware-citrix-saltstack/\r\nPage 5 of 10\n\nGolang binary masquerading as a legitimate ADC process named nsppe . This malware contained capabilities to\r\nencrypt C2 traffic, use SOCKS proxies, execute commands, run a XMRIG miner, and run masscan .\r\nWhen analyzing the C2 protocol used by nspps, IronNet noted these network POST requests:\r\n/h\r\n/get\r\n/getT\r\n/l\r\n/o\r\n/r\r\n/s\r\nThe article includes a detailed summary of these calls, which when compared to C2 calls documented by Trend\r\nMicro show evidence that nspps and Kinsing malware both use similar, if not the exact same, C2 protocols.\r\nAnalysis also determined nspps contained incredibly similar tasking capabilities:\r\nbackconnect\r\ndownload_and_exec\r\nexec\r\nmasscan\r\nredis_brute\r\nscan\r\nsocks\r\nupdate\r\nIn our own analysis, Red Canary found that numerous binary strings were shared across the nspps binary and\r\nprevious Kinsing malware samples. The entirety of Hamlet did not appear in this binary, but we did find other\r\nsimilarities.\r\nIn the Citrix ADC campaign, nspps deployed a XMRIG miner named netscalerd . This binary was named to\r\nagain masquerade as a system process as ADCs were once named Citrix Netscaler devices. As with former\r\nKinsing campaigns, numerous strings within the binary showed an embedded config.json configuration file\r\nand the expected usage instructions for an XMRIG binary.\r\n\"background\": false,\r\n\"donate-level\": 0,\r\n\"cpu\": true,\r\n\"colors\": false,\r\n\"opencl\": false,\r\n\"pools\": [\r\n\"coin\": \"monero\",\r\n\"algo\": null,\r\n\"url\": \"xmr-eu1.nanopool.org\",\r\n\"user\": \"46V5WXwS3gXfsgR7fgXeGP4KAXtQTXJfkicBoRSHXwGbhVzj1JXZRJRhbMrvhxvXvgbJuyV3GGWzD6JvVMuQwAXxLZmTWkb\",\r\nhttps://redcanary.com/blog/kinsing-malware-citrix-saltstack/\r\nPage 6 of 10\n\n\"pass\": \"mine\",\r\n\"tls\": false,\r\n\"keepalive\": true,\r\n\"nicehash\": false\r\n-o, --url=URL URL of mining server\r\n-a, --algo=ALGO mining algorithm https://xmrig.com/docs/algorithms\r\n--coin=COIN specify coin instead of algorithm\r\n-u, --user=USERNAME username for mining server\r\n-p, --pass=PASSWORD password for mining server\r\n-O, --userpass=U:P username:password pair for mining server\r\n-k, --keepalive send keepalived packet for prevent timeout (needs pool support)\r\n--nicehash enable nicehash.com support\r\n--rig-id=ID rig identifier for pool-side statistics (needs pool support)\r\n-r, --retries=N number of times to retry before switch to backup server (default: 5)\r\n-R, --retry-pause=N time to pause between retries (default: 5)\r\n--user-agent set custom user-agent string for pool\r\n--donate-level=N donate level, default 5%% (5 minutes in 100 minutes)\r\n--donate-over-proxy=N control donate over xmrig-proxy feature\r\n--no-cpu disable CPU mining backend\r\n-t, --threads=N number of CPU threads\r\n-v, --av=N algorithm variation, 0 auto select\r\n--cpu-affinity set process affinity to CPU core(s), mask 0x3 for cores 0 and 1\r\n--cpu-priority set process priority (0 idle, 2 normal to 5 highest)\r\n--cpu-max-threads-hint=N maximum CPU threads count (in percentage) hint for autoconfig\r\n--cpu-memory-pool=N number of 2 MB pages for persistent memory pool, -1 (auto), 0 (disable)\r\n--cpu-no-yield prefer maximum hashrate rather than system response/stability\r\n--no-huge-pages disable huge pages support\r\n--asm=ASM ASM optimizations, possible values: auto, none, intel, ryzen, bulldozer\r\n--randomx-init=N threads count to initialize RandomX dataset\r\n--randomx-no-numa disable NUMA support for RandomX\r\n--randomx-mode=MODE RandomX mode: auto, fast, light\r\n--randomx-1gb-pages use 1GB hugepages for dataset (Linux only)\r\n--randomx-wrmsr=N write custom value (0-15) to Intel MSR register 0x1a4 or disable MSR mod (-1)\r\n--randomx-no-rdmsr disable reverting initial MSR values on exit\r\n-S, --syslog use system log for output messages\r\n-l, --log-file=FILE log all output to a file\r\n--print-time=N print hashrate report every N seconds\r\n--no-color disable colored output\r\n--verbose verbose output\r\n-c, --config=FILE load a JSON-format configuration file\r\n-B, --background run the miner in the background\r\n-V, --version output version information and exit\r\n-h, --help display this help and exit\r\n--dry-run test configuration and exit\r\nXMRig 5.5.0\r\nhttps://redcanary.com/blog/kinsing-malware-citrix-saltstack/\r\nPage 7 of 10\n\nbuilt on Jan 11 2020 with GCC\r\nUsage: xmrig [OPTIONS]\r\nMatching Monero wallet address\r\nWhile examining the XMRIG embedded config.json file, you probably spotted what we did: the Monero wallet\r\naddress\r\n46V5WXwS3gXfsgR7fgXeGP4KAXtQTXJfkicBoRSHXwGbhVzj1JXZRJRhbMrvhxvXvgbJuyV3GGWzD6JvVMuQwAXxLZmTWkb\r\nappeared in the Citrix ADC miner sample. This wallet address also featured prominently in the other Kinsing\r\ncampaigns. While this isn’t definitive evidence for attribution, it proved to be an excellent way to tie the\r\ncampaigns together since searching VirusTotal Intelligence for this wallet address helped us map out the related\r\nsamples.\r\nEmbedded “masscan” script in binary\r\nAs with other Kinsing samples, nspps contained an embedded script to deploy dependencies and run masscan .\r\nIn this script, the binary was named “firewire” and also used the same command-line arguments found in other\r\nsamples.\r\nLinking Kinsing to F5 BIG-IP exploitation\r\nIn June 2020, F5 issued guidance concerning a vulnerability discovered within their BIG-IP network appliances.\r\nCVE-2020-5902 for these devices allows remote code execution without authentication and has subsequently\r\nallowed adversaries to exploit F5 systems for an initial foothold into networks. While monitoring a VirusTotal\r\nLiveHunt YARA rule for Kinsing, we found a new version uploaded under the name “bigip.” As of this writing,\r\nthere is no public documentation around Kinsing/H2Miner exploiting F5 appliances but this binary name could be\r\nan indication. This binary matched the previously mentioned function names for Kinsing malware and also\r\ncontained the complete text of Hamlet. In addition, around the same time another XMRIG sample with the\r\nKinsing Monero wallet address appeared on VirusTotal under the name “bigipdaemon.” This matches the same\r\npattern we observed before: Golang RAT, then XMRIG miner.\r\nAttribution implications and complications\r\nThe Monero wallet connection\r\nThe Monero wallet address shared across all samples mentioned is what originally drew our attention to further\r\nanalyze Kinsing campaigns. It was our first piece of evidence but it wasn’t strong enough to stand on its own. The\r\nlargest implication of this shared wallet address is that the campaigns may be related to the same actor or group.\r\nWhile we can’t assert that the same exact people used Kinsing during the campaigns, we feel there is enough\r\nevidence to indicate that the Kinsing RAT has been used across additional campaigns than previously documented.\r\nThreat intelligence should be always questioned, so let’s take a moment to examine this assumption: should a\r\nshared wallet address indicate the same actor? What other possible explanations exist? Cryptocurrencies have\r\nenabled the rapid movement of funds via the internet, and Monero in particular has introduced privacy features\r\nhttps://redcanary.com/blog/kinsing-malware-citrix-saltstack/\r\nPage 8 of 10\n\nthat complicate the money trail. We know from the miner configurations that funds went into this wallet, but it\r\nremains an opaque structure to us and we cannot know where the funds go afterward. In the physical world, this\r\nwould be the equivalent to dropping money into an anonymous bank account. We generally assume that the\r\naccount belongs to someone, but there’s no way to know if the account belongs to a person, group, or a proxy\r\nholding the funds in escrow for later distribution.\r\nIn the ideal case, the same actors across these campaigns would be the owner of the account. In the worst case, the\r\naccount would be the first stop in a chain of transactions to hide the origin of the funds.\r\nConclusions about capabilities\r\nDuring our analysis of capabilities and campaigns, we made one large assumption: that the H2Miner botnet\r\noperating Kinsing has exclusive access to Kinsing source code. This is the simplest explanation, as we have not\r\nfound evidence suggesting the source code for Kinsing is available publicly on the internet, and it has not been\r\nused widely enough to indicate that Kinsing is a malware-as-a-service offering. Alternate explanations to\r\nchallenge this assumption include the possibility that Kinsing code is shared across multiple actors or groups, but\r\nthis possibility would also need to take into account shared access for the Monero wallet address. Any shared code\r\naccess would also require access to the funds gained.\r\nThe first and most obvious conclusion we can draw about capabilities is the fact that one or more actors have used\r\nKinsing across Linux and FreeBSD platforms. Previous to this assertion there was no evidence that Kinsing or its\r\noperator botnet H2Miner had targeted FreeBSD devices. This capability suggests that the Kinsing operators are\r\nfamiliar with the ability of Golang to cross-compile for multiple platforms and that they are either familiar with\r\nthe operating system components of enterprise network devices or can quickly learn them. This is an important\r\nconclusion to draw in 2020 and beyond because of the increasing number of remote code execution vulnerabilities\r\nfor enterprise network appliances, including those for Palo Alto and F5 Big-IP devices. In addition, Kinsing\r\noperators are familiar with the ability to rapidly weaponize emerging remote code execution exploits for\r\nopportunistic use.\r\nIt’s important to note that these threats are not going away and will seek opportunities to exploit any devices\r\nconnected to the public internet. The safest way to mitigate these threats is to patch and segment your network,\r\nprotecting the management interfaces of network devices from unauthorized access.\r\nhttps://redcanary.com/blog/kinsing-malware-citrix-saltstack/\r\nPage 9 of 10\n\nRelated Articles\r\nSubscribe to our blog\r\nYou'll receive a weekly email with our new blog posts.\r\nSource: https://redcanary.com/blog/kinsing-malware-citrix-saltstack/\r\nhttps://redcanary.com/blog/kinsing-malware-citrix-saltstack/\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://redcanary.com/blog/kinsing-malware-citrix-saltstack/"
	],
	"report_names": [
		"kinsing-malware-citrix-saltstack"
	],
	"threat_actors": [
		{
			"id": "eb3f4e4d-2573-494d-9739-1be5141cf7b2",
			"created_at": "2022-10-25T16:07:24.471018Z",
			"updated_at": "2026-04-10T02:00:05.002374Z",
			"deleted_at": null,
			"main_name": "Cron",
			"aliases": [],
			"source_name": "ETDA:Cron",
			"tools": [
				"Catelites",
				"Catelites Bot",
				"CronBot",
				"TinyZBot"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "75108fc1-7f6a-450e-b024-10284f3f62bb",
			"created_at": "2024-11-01T02:00:52.756877Z",
			"updated_at": "2026-04-10T02:00:05.273746Z",
			"deleted_at": null,
			"main_name": "Play",
			"aliases": null,
			"source_name": "MITRE:Play",
			"tools": [
				"Nltest",
				"AdFind",
				"PsExec",
				"Wevtutil",
				"Cobalt Strike",
				"Playcrypt",
				"Mimikatz"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "3fff98c9-ad02-401d-9d4b-f78b5b634f31",
			"created_at": "2023-01-06T13:46:38.376868Z",
			"updated_at": "2026-04-10T02:00:02.949077Z",
			"deleted_at": null,
			"main_name": "Cleaver",
			"aliases": [
				"G0003",
				"Operation Cleaver",
				"Op Cleaver",
				"Tarh Andishan",
				"Alibaba",
				"TG-2889",
				"Cobalt Gypsy"
			],
			"source_name": "MISPGALAXY:Cleaver",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "a6c351ea-01f1-4c9b-af75-cfbb3b269ed3",
			"created_at": "2023-01-06T13:46:39.390649Z",
			"updated_at": "2026-04-10T02:00:03.311299Z",
			"deleted_at": null,
			"main_name": "Kinsing",
			"aliases": [
				"Money Libra"
			],
			"source_name": "MISPGALAXY:Kinsing",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775433992,
	"ts_updated_at": 1775792099,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/4194845fcc857621588d96cd2edc0b8246923d5e.pdf",
		"text": "https://archive.orkl.eu/4194845fcc857621588d96cd2edc0b8246923d5e.txt",
		"img": "https://archive.orkl.eu/4194845fcc857621588d96cd2edc0b8246923d5e.jpg"
	}
}