{
	"id": "516d75aa-46e1-4508-8340-fe66048d4443",
	"created_at": "2026-04-06T01:29:19.64076Z",
	"updated_at": "2026-04-10T03:31:49.855414Z",
	"deleted_at": null,
	"sha1_hash": "fd01a4f0faec85d7c66faedba9e9dc8ab82fd6cb",
	"title": "ESXi Ransomware Attacks: Evolution, Impact, and Defense Strategy",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 361729,
	"plain_text": "ESXi Ransomware Attacks: Evolution, Impact, and Defense\r\nStrategy\r\nBy Sygnia\r\nPublished: 2024-05-15 · Archived: 2026-04-06 00:51:19 UTC\r\nUnderstand how ransomware attacks unfold in virtualized environments, and how to defend against these attacks\r\nacross each phase of the cyber-attack kill chain.\r\nNital Ruzin, Omer Kidron\r\n15 May 2024\r\n16 min\r\nExecutive Summary\r\nIn recent years, Sygnia’s Incident Response team has seen a steady increase in ransomware attacks targeting\r\nvirtualized environments, particularly against VMware ESXi infrastructure. Virtualization platforms are a core\r\ncomponent of organizational IT infrastructure, yet they often suffer from inherent misconfigurations and\r\nvulnerabilities, making them a lucrative and highly effective target for threat actors to abuse.\r\nSygnia’s analysis and investigative activities show that this attack vector is often leveraged by ransomware tools\r\nand groups such as LockBit, HelloKitty, BlackMatter, RedAlert (N13V), Scattered Spider, Akira, Cactus,\r\nBlackCat and Cheerscrypt.\r\nThrough its numerous incident investigations, Sygnia has identified that these attacks follow a typical attack\r\npattern, and has gained a profound understanding of the most effective defense strategies.\r\nThis blog post describes how ransomware attacks against virtualized environments unfold across each phase of the\r\nattack kill chain, and provides mitigation strategies and specific, actionable tactics for defending against these\r\nthreats, ensuring the resilience of digital assets in virtualized environments.\r\nCommon Virtualization Attack Phases\r\nSygnia’s analysis indicates that ransomware attacks on virtualization environments typically follow a similar\r\npattern:\r\nInitial access: Threat actors gain initial access into the organization using established techniques such as\r\nconducting phishing attacks, downloading malicious files, or exploiting known vulnerabilities in internet-facing assets.\r\nLateral movement and privilege escalation: Upon gaining access, threat actors escalate their privileges\r\nto obtain credentials for ESXi hosts or vCenter. This escalation can be achieved through various methods,\r\nhttps://www.sygnia.co/blog/esxi-ransomware-attacks/\r\nPage 1 of 9\n\nsuch as altering domain group memberships for domain-connected VMware, employing brute-force\r\nattacks, executing RDP hijacking attempts that target IT personnel.\r\nAccess validation: After securing initial access to the virtualization infrastructure, threat actors validate\r\ntheir ability to interface with it. If direct access is denied, attackers use vCenter to enable SSH on all ESXi\r\nservers – and might also reset server passwords or execute commands remotely using custom-made\r\nvSphere Installation Bundles (VIBs).\r\nVirtualized ransomware deployment: Threat actors then utilize their access to connect to the ESXi, and\r\nexecute the ransomware on the ESXi hosts.\r\nCompromise of backups: Targeting beyond the virtualized environment, threat actors might try to seize\r\ncontrol of backup systems. By encrypting or deleting backup storage and, in some instances, changing the\r\npasswords for the backup system, threat actors aim to hinder the recovery of the virtualized environment\r\nand thus gain additional leverage over their victims.\r\nData exfiltration: Threat actors often attempt to enact a double extortion scheme, by exfiltrating data to\r\nexternal locations such as Mega.io, Dropbox, or their own hosting services. This enables threat actors not\r\nonly to encrypt the existing files, but also to release the exfiltrated data publicly, to cause additional\r\nreputational damage.\r\nRansomware execution: At this point, threat actors shut down all virtual machines and initiate\r\nransomware that encrypts the ‘/vmfs/volumes’ folder of the ESXi filesystem.\r\nAdditional ransomware deployment: Threat actors who obtain prior access to deployment mechanisms\r\n(such as SCCM or Active Directory) may spread additional ransomware to non-virtualized servers and\r\nworkstations, amplifying the attack’s impact beyond the virtualization realm.\r\nhttps://www.sygnia.co/blog/esxi-ransomware-attacks/\r\nPage 2 of 9\n\nFigure 1: ESXi Ransomware Attack Kill-Chain\r\nThe Defender’s Perspective\r\nNow that we have a general understanding of the attack flow, let’s look at this attack from the defender’s\r\nperspective. It is usually possible to mitigate – or at the very least, increase the likelihood of recovering from –\r\nattacks targeting ESXi infrastructure, by taking the following key elements into consideration:\r\nMonitoring is a cornerstone of detecting, containing, and blocking attacks in the early stages, and can\r\nassist in containing an attacker’s activities before damage is done.\r\nBackups that are comprehensive and have robust protection are the most reliable way to enable a company\r\nto return to operation in a timely manner after a breach.\r\nAuthentication and authorization such as Role-Based Access Control (RBAC) helps to restrict attackers’\r\naccess abilities, inhibiting privilege escalation and containing the attack.\r\nHardening aids in mitigating attackers’ Tactics, Techniques and Procedures (TTPs), and can repel\r\ninstances of privilege escalation, code execution, data exfiltration and more.\r\nNetwork restrictions help to limit an attacker’s lateral movement.\r\nA Mitigation Strategy\r\nhttps://www.sygnia.co/blog/esxi-ransomware-attacks/\r\nPage 3 of 9\n\nThe following recommendations are designed specifically to inhibit ransomware attacks on VMware (versions 6.7\r\nand above) virtualized environments. Nevertheless, similar measures can be adopted to protect any other\r\nvirtualization environment.\r\nWe recommend including the following resources and activities as part of your security hardening, in addition to\r\nother security measures and best practices. As always, it is recommended to test the implementation of the\r\nfollowing recommendations in a test environment before implementing them in production. The following\r\nrecommendations are ordered in a way that simplifies implementation, starting with the easiest and quickest\r\nsolutions.\r\nMonitoring\r\nMonitoring and logging should be in place to ensure that attacks and misuse are detected, and to facilitate\r\nforensic examination. Remember that logging and data collection should aim to provide as much information as\r\npossible, in preparation for D-Day.\r\n1. Ensure logs are collected: Make sure that all the components of the virtualization environment – namely\r\nESXi hosts, vCenter, and storage – are sending logs to the Security Information and Events Management\r\n(SIEM) solution for retention, correlation, and alerting.\r\nIn some instances, threat actors deliberately encrypt or delete logs to conceal their activities, rendering\r\nlocally-stored logs unreliable. This highlights the importance of maintaining immutable backups of all logs\r\nthat are sent to the SIEM – particularly for self-hosted SIEMs. These backups ensure the availability of\r\ncritical log data for investigation in the event of a total compromise and encryption of the environment.\r\nDetails on how to configure syslog for ESXi hosts can be found here.\r\nSome monitoring solutions look at the log files directly; in such cases, the auth.log file\r\n(/var/log/auth.log) holds all authentication attempts to ESXi hosts. Additional information on\r\nthe ESXi log file can be found here.\r\nExamples of authentication and shell logs can be found here.\r\nDetails on how to configure syslog for vCenter servers can be found here.\r\n2. Create SIEM alerts: Configure alerts for suspicious behavior that may indicate that virtualized\r\ninfrastructure has been compromised. This behavior can range from root password changes to critical\r\nconfiguration changes such as disabling security features, installation of third-party VIBs, and more. These\r\nalerts should be custom-fit to the environment to reduce false-positives. Following are some actions that\r\nare worth highlighting, as they are mostly unique, and are highly likely to indicate that a ransomware attack\r\nis in process:\r\nESXi host shutting down all virtual machines – threat actors have been observed powering off all\r\nmachines before starting the encryption process. More information about logs related to reasons for\r\nvirtual machine shutdown can be found here. \r\nESXi host executing command-line commands, including the phrases:\r\n*./encryptor*\r\n*sudo ./encryptor\r\n*encryptor/vmfs/volumes*\r\nLook for users’ first logins, and logins of abnormal or suspicious user accounts.\r\nhttps://www.sygnia.co/blog/esxi-ransomware-attacks/\r\nPage 4 of 9\n\nIf vCenter is integrated with Active Directory, it is essential to establish alerts for modifications to\r\ngroups associated with vCenter administrative privileges, such as VMware admins, ESX admins\r\nvirtualization admins, and storage admins. This proactive measure ensures timely detection and\r\nresponse to unauthorized changes, thereby reinforcing the security posture of the virtualization\r\nenvironment.\r\nEvent ID for a user being added to an AD group: 4728, 4732, 4756.\r\nEvent IDs 4728, 4732, and 4756 can also apply when a group (rather than an individual user)\r\nis added to another group, depending on the group’s scope (global, local, or universal,\r\nrespectively).\r\nEnable “Audit account management” in the Group Policy settings under Computer\r\nConfiguration → Security Settings → Advanced Audit Policy Configuration → Audit\r\nPolicies → Account Management on the domain controllers, to ensure these events are\r\ncaptured.\r\nThreat actors have been observed using ESXi profiles to perform privilege escalation, by modifying\r\nconfigurations such as running services, Active Directory integration, and even the root password.\r\nThese modifications can be monitored through specific log files. Key logs to monitor include the\r\nvCenter ‘vpxd.log’ and the ESXi ‘hostd.log’:\r\nThreat actors might alter the configuration of an ESXi host to gain a foothold, by utilizing\r\nthe built-in feature of ESXi profiles, without having direct access to the ESXi hosts. Trigger\r\nalerts on profile changes using the following log entry format: Profile [profile-name] has\r\nbeen applied to host [host-name]\r\nUnplanned root account password changes can indicate an active threat in the network,\r\ngaining elevated privileges on the ESXi. Trigger alerts for root password changes using this\r\nlog entry: Applying password change for root user on host [host-name]\r\nAddition of ESXi to Active Directory could suggest that a threat actor is attempting to gain\r\naccess to the ESXi host using domain credentials. Look for the following entry in the logs:\r\nHost [host-name] has been added to the Active Directory domain [domain-name]\r\n3. Set up SIEM redundancy: Avoid SIEM single point of failure by setting up redundancy – keep in mind\r\nthat if the SIEM is hosted on a ESX server, a failure of or an attack on the ESX will blind the SIEM.\r\nBackups\r\nBackups are the last resort if all other mitigations have failed. Backups must be secure, robust, and reliable. Never\r\ntest a backup on D-Day for the first time. Ensure that your backups are working and are hosted in a secure\r\nlocation so that in case of emergency, there are no surprises in your last line of defense. Keep in mind that one of\r\nthe ways adversaries ensure complete lockdown of the environment is by targeting backup infrastructure – so\r\nyours should be well protected.\r\n1. Scope: Backups must be created and retained in alignment with the organization’s business impact\r\nanalysis. These backups should encompass all critical assets of the organization, including the necessary\r\nsupporting infrastructure. Taking these assets into consideration is crucial for determining which systems\r\nmust be reinstated to full operation in the event of a crisis, as indicated by the Recovery Time Objective\r\nhttps://www.sygnia.co/blog/esxi-ransomware-attacks/\r\nPage 5 of 9\n\n(RTO). For instance, an ERP system is regarded as a business-critical asset, while Active Directory serves\r\nas supporting infrastructure. \r\n2. Method: At a minimum, it is advised to store backups on a modern, immutable storage and backup\r\nplatform. This approach guarantees that once a backup has been created, it cannot be erased until the\r\nspecified retention duration has elapsed. \r\n3. Testing: It is essential to verify that backups are functioning as anticipated, and that the data remains\r\nrecoverable. This verification can be achieved by attempting to restore a service using a backup and\r\nensuring that the data’s integrity is preserved. It is important to recognize that certain servers and services\r\nnecessitate distinct backup protocols. For instance: \r\nMicrosoft SQL Server backups should be performed through the utilization of the SQL Server\r\nManagement Studio (SSMS) task schedule, with backups being stored in a secure location.\r\nAdditional details regarding the creation of full database backups without utilizing backup solutions\r\ncan be found here. \r\nFor Active Directory, the built-in ‘Windows Server backup utility’ can be used. Further information\r\ncan be found here. Additional information on how to back up and restore Active Directory servers\r\ncan be found here.\r\n4. Backup locations: It is essential to ensure that NAS (Network Attached Storage) and SAN (Storage Area\r\nNetwork) backup locations are completely isolated from the production environment. This can be achieved\r\nthrough dedicated hardware and network segmentation, or by using a dedicated, secure cloud account\r\nexclusively for backup purposes. This principle extends to virtual machines and other storage scenarios.\r\nFor instance, if backups made using snapshots are kept in the same storage location as the machine itself,\r\nthere is a greater risk that threat actors will encrypt the backups in parallel with the servers. Such scenarios\r\nhave been observed in several recent ransomware incidents. \r\n5. Security measures: It is vital to secure backups against unauthorized access and malicious tampering.\r\nWhen determining suitable security measures for backups in your environment, consider the following\r\ncritical factors: \r\nAuthentication: Evaluate the authentication method utilized. Enforce multi-factor authentication\r\n(MFA) for all access points to the backup and define where you expect sources to connect from;\r\nonly jump servers or a privileged access management solution should be used for such connections. \r\nAuthorization: Determine the users authorized to access or delete backup data. Specify the\r\nconditions under which such actions are allowed – particularly deletions. For example, allow users\r\nwith deletion capabilities to access the server only from a secure source, such as a Privileged Access\r\nManagement (PAM) solution, and only during maintenance windows. Consider this access to be\r\nequivalent to the use of a break-glass account and configure the appropriate alerts. \r\nAccounting: Implement comprehensive logging and monitoring mechanisms. Establish protocols\r\nfor alerting relevant personnel upon detection of potentially destructive actions, such as\r\nunauthorized configuration modifications or deletions of backups. \r\nConfidentiality: Ensure backups are encrypted during transmission and at rest. Ensure that you\r\nknow which encryption methods are used, the lifecycle of encryption keys, and where they are\r\nstored – ideally offline. All of the above should be well documented and referenced in the Incident\r\nResponse Plan (IRP), to ensure that the relevant information can be retrieved quickly amid the\r\nchaos of an attack.\r\nhttps://www.sygnia.co/blog/esxi-ransomware-attacks/\r\nPage 6 of 9\n\nAuthentication and Authorization\r\nStrong authentication mechanisms with MFA and strict authorization policies will help reduce the attack surface.\r\nRemember: the threat actor will try to take the path of least resistance – so it is crucial to create resistance in your\r\npolicies, systems, and procedures.\r\n1. Principle of Least Privilege: Ensure that only the required personnel have permission (authorization) to\r\naccess the virtualized environment (e.g., VMware Enterprise vCenter, ESXi hosts), and that each person\r\nhas their own dedicated personal privileged user account with the minimal permissions required.\r\nImplementing a robust separation of duties – and thus permissions – according to system criticality,\r\ntype, and data will ensure that the attack blast radius is kept to a minimum.  \r\nUsually only a small and/or dedicated team requires direct access to ESXi hosts – particularly with\r\n‘write’ permissions – as most deployments utilize vCenter for management, meaning that there is no\r\nactual need for continuous ESXi access. \r\n2. Authentication: Wherever possible, enforce the use of MFA to access the vCenter – with the exception of\r\nthe highly-monitored break-glass accounts. This can be achieved using Radius or smart card authentication.\r\nFurther information about MFA in vCenter can be found here. Ensure that all passwords are complex and\r\nunique for each ESXi host and vCenter, as password reuse has been exploited by adversaries to gain access\r\nto various systems. If a Privileged Identity Management (PIM) or password vault solution exists in the\r\norganization, store the passwords using this solution.  \r\n3. Credential rotation: If a PIM solution exists in the organization, rotate all Privileged Accounts passwords\r\non a regular basis. Otherwise, ensure periodic rotation of passwords for the dedicated personal users, and\r\nonce a year change the break-glass account’s password.  \r\n4. Break-glass account protection: It is essential to secure all break-glass accounts (for example, root user\r\naccounts) with unique, long passwords. These passwords should be stored offline to guarantee accessibility\r\nin emergency situations. Additionally, it is crucial to implement a policy for regular password rotation. If a\r\nPIM solution is in place, it should be leveraged to automate this task.\r\nHardening\r\nThe keystone of security is to limit the attack surface to the greatest extent possible, making the adversary’s life\r\nharder. Hardening is not the be-all and end-all of attack surface reduction, but is a significant aspect of it, and an\r\nimportant tool in the defender’s toolkit. For example, a threat actor will not be able to run scripts without\r\nresistance if the organization’s execution policy is hardened by being set to ‘signed only’.\r\n1. Disable unused protocols: Ensure that SSH is disabled on all ESXi hosts. Emergency access can be\r\nachieved by utilizing out-of-band management protocols such as iLO, DRAC, or by temporarily enabling\r\nSSH and immediately closing the service again after the activity. Additionally, ensure that other\r\nunnecessary management services, such as HTTPS (port 443), vSphere Client for console (902 TCP/UDP),\r\nand vMotion (TCP 8000), are properly restricted to minimal required usage, if any.\r\n2. Up-to-date security patches: Ensure that vCenter and ESXi hosts receive periodic updates, at least once\r\nevery year. Additionally, you should follow threat intel feeds and bulletins to stay informed about critical\r\nvulnerabilities, such as the Log4Shell vulnerability on vCenter. It is also recommended to use vulnerability\r\nscanners on a regular basis, to identify and address vulnerabilities within the platform.\r\nhttps://www.sygnia.co/blog/esxi-ransomware-attacks/\r\nPage 7 of 9\n\n3. Lockdown mode: VMware environments can be configured to allow management only via vCenter, and\r\nthus to prevent any direct access to ESXi hosts.\r\nWhen using the ‘Normal lockdown mode’ configuration, the ESXi hosts are accessible only through\r\nvCenter and direct console UI.\r\nWhen using ‘Strict lockdown mode’, direct console is disabled, and only vCenter can change\r\nconfiguration in the ESXi hosts.\r\nThe emergency break-glass, third-party solution, and external application accounts must be\r\nexempted from lockdown mode in order to be able to communicate directly with the ESXi. More\r\ninformation about how to configure the exception list can be found here.\r\nFurther information about lockdown mode can be found here.\r\n4. Restrict unsigned scripts: Disable the ability to execute unsigned scripts on ESXi hosts, to prevent\r\nmalicious executables such as the encryptor from running on the hosts. As a prerequisite to this\r\nconfiguration, ensure that the infrastructure supports UEFI Secure boot, and that Trusted Platform Module\r\n(TPM) is enabled on the hosts.\r\nEnable UEFI Secure boot and TPM.\r\nEnable the ‘execInstalledOnly’ flag on all ESXi hosts in the environment. This feature will block\r\nany unsigned code from running on the ESXi. Refer to this article for details on how to restrict the\r\nexecution of the unsigned script.\r\n5. Segregate hosts containing sensitive systems: Although not the most cost-effective strategy for\r\nsafeguarding critical infrastructure, it is highly recommended to segregate ESXi hosts and storage for\r\ncritical assets from other servers. Such assets include Domain Controllers and Public Key Infrastructure\r\n(PKI) systems. The rationale behind this is to mitigate the risk that a compromise, even at the virtualization\r\nlayer, could provide a threat actor with overarching access privileges, metaphorically handing them the\r\n‘keys to the kingdom’. For instance, if an Active Directory virtual machine’s storage is not encrypted, a\r\nthreat actor might extract the NTDS.dit file directly from the virtualization platform. This action could\r\nenable the attacker to execute a KRBTGT golden ticket attack, which would severely compromise the\r\nenvironment’s security.\r\n6. Follow best practices: Ensure that security best practices are followed for VMware.\r\nFurther information on the ESXi host can be found here and here, and CIS recommendations can be found\r\nhere. Additional information about VMware environment security can be found here.\r\nNetwork Restrictions \r\nStrict network policies will hinder the lateral movement of an adversary. It is vital to ensure that only the required\r\naccess is allowed.\r\n1. Access policy: Implement a restrictive network access policy for all virtualization components, including\r\nstorage, ESXi, and vCenter. Access should be restricted solely to essential entities, such as internal\r\ncomponents, secure workstations, jump servers, out-of-band machines, and the Privileged Access\r\nManagement (PAM) solution, if one is deployed.\r\n2. Restrict administrative access: Network access to ESXi hosts and administrative interfaces must be\r\nstrictly controlled. Ensure that such access is granted only after establishing that the source complies with\r\nthe principle of least privilege, and is one of the entities mentioned above – meaning: personal IT\r\nhttps://www.sygnia.co/blog/esxi-ransomware-attacks/\r\nPage 8 of 9\n\nworkstations should not be allowed to have access directly, but relevant jump servers are allowed, with the\r\nrestriction that the server is denied access to the internet. This can be achieved by utilizing robust firewall\r\npolicies, or through identity-aware network restrictions.\r\n3. Outbound traffic: Deny the ability to initiate outbound traffic to the internet and other non-trusted\r\nnetworks from all virtualization components – or limit the ability to the greatest extent possible. Such\r\ncomponents include vCenter, ESXi hosts, and storage components. This approach will mitigate the risk of\r\ndata exfiltration and other external threats.\r\n4. Out of band: For environments that require additional security, restrict access to ESXi hosts and storage to\r\na dedicated administrative out-of-band network. This measure ensures an additional layer of security by\r\nsegregating administrative traffic from the operational network.\r\nConclusion\r\nIn the modern digital era, virtualized environments are crucial to organizational IT infrastructure, yet they also\r\nrepresent significant ransomware risks. This article highlights how attackers exploit vulnerabilities within\r\nhypervisors, transforming operational benefits into severe security risks. Nonetheless, by adopting a proactive\r\nsecurity posture – encompassing regular monitoring, stringent network restrictions, robust authentication, timely\r\nsecurity patches, and segregation of critical systems – organizations can significantly mitigate these threats. The\r\ncreation and regular testing of secure, reliable backups is also essential, providing a vital safety net against\r\nbreaches. Despite the evolving cyber threat landscape, with informed strategies and diligent best practices,\r\nbusinesses can strengthen their defenses against ransomware, ensuring the integrity and resilience of digital\r\ninfrastructures.\r\nSource: https://www.sygnia.co/blog/esxi-ransomware-attacks/\r\nhttps://www.sygnia.co/blog/esxi-ransomware-attacks/\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.sygnia.co/blog/esxi-ransomware-attacks/"
	],
	"report_names": [
		"esxi-ransomware-attacks"
	],
	"threat_actors": [
		{
			"id": "9ddc7baf-2ea7-4294-af2c-5fce1021e8e8",
			"created_at": "2023-06-23T02:04:34.386651Z",
			"updated_at": "2026-04-10T02:00:04.772256Z",
			"deleted_at": null,
			"main_name": "Muddled Libra",
			"aliases": [
				"0ktapus",
				"Scatter Swine",
				"Scattered Spider"
			],
			"source_name": "ETDA:Muddled Libra",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "7da6012f-680b-48fb-80c4-1b8cf82efb9c",
			"created_at": "2023-11-01T02:01:06.643737Z",
			"updated_at": "2026-04-10T02:00:05.340198Z",
			"deleted_at": null,
			"main_name": "Scattered Spider",
			"aliases": [
				"Scattered Spider",
				"Roasted 0ktapus",
				"Octo Tempest",
				"Storm-0875",
				"UNC3944"
			],
			"source_name": "MITRE:Scattered Spider",
			"tools": [
				"WarzoneRAT",
				"Rclone",
				"LaZagne",
				"Mimikatz",
				"Raccoon Stealer",
				"ngrok",
				"BlackCat",
				"ConnectWise"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "8c8fea8c-c957-4618-99ee-1e188f073a0e",
			"created_at": "2024-02-02T02:00:04.086766Z",
			"updated_at": "2026-04-10T02:00:03.563647Z",
			"deleted_at": null,
			"main_name": "Storm-1567",
			"aliases": [
				"Akira",
				"PUNK SPIDER",
				"GOLD SAHARA"
			],
			"source_name": "MISPGALAXY:Storm-1567",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "c3b908de-3dd1-4e5d-ba24-5af8217371f0",
			"created_at": "2023-10-03T02:00:08.510742Z",
			"updated_at": "2026-04-10T02:00:03.374705Z",
			"deleted_at": null,
			"main_name": "Scattered Spider",
			"aliases": [
				"UNC3944",
				"Scattered Swine",
				"Octo Tempest",
				"DEV-0971",
				"Starfraud",
				"Muddled Libra",
				"Oktapus",
				"Scatter Swine",
				"0ktapus",
				"Storm-0971"
			],
			"source_name": "MISPGALAXY:Scattered Spider",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "910b38e9-07fe-4b47-9cf4-e190a07b1b84",
			"created_at": "2024-04-24T02:00:49.516358Z",
			"updated_at": "2026-04-10T02:00:05.309426Z",
			"deleted_at": null,
			"main_name": "Akira",
			"aliases": [
				"Akira",
				"GOLD SAHARA",
				"PUNK SPIDER",
				"Howling Scorpius"
			],
			"source_name": "MITRE:Akira",
			"tools": [
				"Mimikatz",
				"PsExec",
				"AdFind",
				"Akira _v2",
				"Akira",
				"Megazord",
				"LaZagne",
				"Rclone"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "d093e8d9-b093-47b8-a988-2a5cbf3ccec9",
			"created_at": "2023-10-14T02:03:13.99057Z",
			"updated_at": "2026-04-10T02:00:04.531987Z",
			"deleted_at": null,
			"main_name": "Scattered Spider",
			"aliases": [
				"0ktapus",
				"LUCR-3",
				"Muddled Libra",
				"Octo Tempest",
				"Scatter Swine",
				"Scattered Spider",
				"Star Fraud",
				"Storm-0875",
				"UNC3944"
			],
			"source_name": "ETDA:Scattered Spider",
			"tools": [
				"ADRecon",
				"AnyDesk",
				"ConnectWise",
				"DCSync",
				"FiveTran",
				"FleetDeck",
				"Govmomi",
				"Hekatomb",
				"Impacket",
				"LOLBAS",
				"LOLBins",
				"LaZagne",
				"Living off the Land",
				"Lumma Stealer",
				"LummaC2",
				"Mimikatz",
				"Ngrok",
				"PingCastle",
				"ProcDump",
				"PsExec",
				"Pulseway",
				"Pure Storage FlashArray",
				"Pure Storage FlashArray PowerShell SDK",
				"RedLine Stealer",
				"Rsocx",
				"RustDesk",
				"ScreenConnect",
				"SharpHound",
				"Socat",
				"Spidey Bot",
				"Splashtop",
				"Stealc",
				"TacticalRMM",
				"Tailscale",
				"TightVNC",
				"VIDAR",
				"Vidar Stealer",
				"WinRAR",
				"WsTunnel",
				"gosecretsdump"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "e424a2db-0f5a-4ee5-96d2-5ab16f1f3824",
			"created_at": "2024-06-19T02:03:08.062614Z",
			"updated_at": "2026-04-10T02:00:03.655475Z",
			"deleted_at": null,
			"main_name": "GOLD HARVEST",
			"aliases": [
				"Octo Tempest ",
				"Roasted 0ktapus ",
				"Scatter Swine ",
				"Scattered Spider ",
				"UNC3944 "
			],
			"source_name": "Secureworks:GOLD HARVEST",
			"tools": [
				"AnyDesk",
				"ConnectWise Control",
				"Logmein"
			],
			"source_id": "Secureworks",
			"reports": null
		}
	],
	"ts_created_at": 1775438959,
	"ts_updated_at": 1775791909,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/fd01a4f0faec85d7c66faedba9e9dc8ab82fd6cb.pdf",
		"text": "https://archive.orkl.eu/fd01a4f0faec85d7c66faedba9e9dc8ab82fd6cb.txt",
		"img": "https://archive.orkl.eu/fd01a4f0faec85d7c66faedba9e9dc8ab82fd6cb.jpg"
	}
}