{
	"id": "70b88e9f-f73f-4d74-86b1-075d8e39a16a",
	"created_at": "2026-04-06T00:12:00.165833Z",
	"updated_at": "2026-04-10T03:28:24.266077Z",
	"deleted_at": null,
	"sha1_hash": "a2e2b5d741df3062cb097ac8dc6860615df584c6",
	"title": "A Look Into Public Clouds From the Ransomware Actor's Perspective",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 508668,
	"plain_text": "A Look Into Public Clouds From the Ransomware Actor's\r\nPerspective\r\nBy Jay Chen\r\nPublished: 2022-05-16 · Archived: 2026-04-05 16:45:50 UTC\r\nExecutive Summary\r\nTraditional ransomware mainly targets on-premises IT infrastructure but doesn't work well in cloud environments,\r\nwhich is one reason we haven't heard much about ransomware in public clouds. However, ransomware actors\r\ncould adapt their tactics, techniques and procedures (TTPs) to be more cloud native, and now is a good time for\r\norganizations to get ahead of this possibility.\r\nRansomware incidents have severely disrupted business operations across all industries. In 2021, the average\r\nransom demand was $2.2 million, and the average payment was $541,010. Since 2020, researchers have detected\r\nat least 130 different ransomware families. There is still no sign of a decrease in the frequency and severity of\r\nransomware attacks.\r\nWhile there are many known ransomware families, there is no known ransomware actor targeting cloud\r\nenvironments. With the increasing demands of the remote workforce, many organizations are migrating on-premises data centers to the public clouds. Cloud-native infrastructure is also the de facto way that startups can\r\nquickly build their business.\r\nHere, we explore how ransomware threat actors might operate in cloud environments – what approaches they\r\nmight use to attack and impact resources in public clouds. We ask questions including:\r\nAre cloud-hosted resources more resilient to ransomware attacks?\r\nWhat types of cloud resources are more vulnerable to ransomware?\r\nHow might adversaries attack cloud resources?\r\nOur goal is to help organizations prepare for this threat while it is still largely theoretical. The discussed scenarios\r\nare intended to be broad and not specific to any cloud service provider.\r\nKnowing that threat actors such as Rocke and TeamTNT target unsecured cloud environments, it is sensible that\r\nransomware actors will also turn to the cloud sooner or later. Due to the fundamental difference between cloud-native and on-premises IT infrastructure, existing ransomware will not be effective in attacking cloud\r\nenvironments. Ransomware actors will need new TTPs in order to target cloud workloads.\r\nHowever, we have seen threat actors evolve in this way to target cloud workloads before. In our latest Cloud\r\nThreat Report, “IAM The First Line of Defense,” we designated cloud threat actors as a new type of threat,\r\ndefining a cloud threat actor as “an individual or group posing a threat to organizations through directed and\r\nsustained access to cloud platform resources, services or embedded metadata.”\r\nhttps://unit42.paloaltonetworks.com/ransomware-in-public-clouds/\r\nPage 1 of 10\n\nRansomware actors may also find ways to adapt to the cloud – especially if they begin to see the rewards as worth\r\nthe effort. Unit 42 researchers identified the possible infection vectors, vertical/lateral movements, targeted\r\nresources and impact of such attacks. We incorporated our knowledge of existing ransomware groups and known\r\nsecurity incidents in public clouds to derive possible TTPs of cloud-targeted ransomware attacks.\r\nOverall, we believe that cloud environments are more resilient to ransomware. The shared responsibility\r\nmodel significantly reduces users' burden in securing the infrastructure, platform and software in the cloud. API-driven cloud services make monitoring, automation and centralized access control easier. Cloud-native backup\r\nservices provide reliable ways to back up cloud resources. Nevertheless, it is the user's responsibility to securely\r\nconfigure, operate and monitor cloud workloads. As IT infrastructure grows with the business, securing thousands\r\nof dynamic workloads in a multi-cloud and hybrid cloud environment can become challenging.\r\nPalo Alto Networks customers can get ahead of potential cloud-based ransomware through Prisma Cloud’s threat\r\ndetection capability, which can identify anomalies and zero-day attacks. Unit 42 offers a ransomware readiness\r\nassessment that organizations can use to enhance the ability to quickly and effectively respond to a ransomware\r\nattack. Cloud incident response services can help address and mitigate cloud security incidents if they do happen.\r\nInitial Access\r\nPhishing, exposed remote desktop protocol (RDP), compromised credentials and unpatched vulnerabilities\r\nare the most common attack vectors that ransomware actors exploit to gain initial access, as detailed in the Unit 42\r\nRansomware Threat Report. These techniques are simple but effective and can be carried out against any\r\nindividual or organization. Some ransomware combines multiple techniques and utilizes commodity malware such\r\nas Emotet and TrickBot to breach a victim's environment. We believe attackers can also use the same techniques\r\nto gain initial access to cloud environments.\r\nAs with on-premises IT infrastructure, where hundreds of employees may work in the same network, hundreds of\r\nengineers may share and work in the same cloud infrastructure. If an attacker can compromise one engineer's\r\nlaptop, that attacker can then potentially pivot from the laptop to the cloud infrastructure. This helps explain why\r\nattackers often see credentials as a prime target.\r\nAnother common attacker vector is unpatched vulnerabilities exposed to the public internet. Our previous research\r\non exposed vulnerabilities found that 24% of exposed VM instances in public clouds have known vulnerabilities.\r\nIf an attacker could find and compromise a vulnerable VM instance on the internet, the instance could serve as a\r\ngateway into the victim's cloud infrastructure.\r\nBelow are two hypothetical examples showing how an attacker could use these techniques to gain an initial\r\nfoothold in a victim's cloud environment.\r\nExample 1: Compromised Laptop via Phishing Emails\r\nIf a developer's laptop is compromised – for example, by phishing emails – cloud credentials stored on the laptop\r\ncould give attackers initial access to an organization’s cloud infrastructure. Cloud Service Providers’ (CSPs)\r\ncommand-line tools commonly store credentials in specific directories on the host. Malware that targets cloud\r\nenvironments often enumerates these directories.\r\nhttps://unit42.paloaltonetworks.com/ransomware-in-public-clouds/\r\nPage 2 of 10\n\nIf the developer also uses CSPs’ web consoles, attackers may also find passwords in the password manager or\r\nactive access tokens in the browsers. Any retrieved credential could be used to impersonate the developer and gain\r\ninitial access to the victim's cloud infrastructure.\r\nExample 2: Compromised Server via Unpatched Vulnerabilities\r\nAny remote code execution (RCE) vulnerability exposed to the internet may allow attackers to gain initial access.\r\nFor example, an attacker can remotely exploit an RDP server with the BlueKeep vulnerability and gain full control\r\nof the server. Since the server is in the victim's cloud environment, the attacker may find cloud credentials on the\r\nserver and use the credentials to pivot into the cloud.\r\nAnother way that attackers can harvest cloud credentials is through metadata services. Metadata services listen on\r\na special IP address that applications on a VM instance can query to obtain the instance's information such as tags,\r\nregion and cloud access tokens. All CSPs support metadata services. Any exposed vulnerability that allows\r\nattackers to reach this special IP address may allow the attacker to steal cloud access tokens. Vulnerabilities like\r\nserver-side request forgery (SSRF) are commonly exploited to access metadata services.\r\nBest Practices to Limit Initial Access\r\nThese hypothetical examples both illustrate the value of using best practices to limit the potential for initial access.\r\nIn particular, organizations can reduce the likelihood of cloud incidents – ransomware or otherwise – by educating\r\nemployees about phishing, improving identity and access management policies and limiting what is exposed to the\r\npublic internet. If possible, use the latest version of the metadata service to prevent attacks like SSRF.\r\nExecution\r\nAfter an attacker gains the initial foothold, their next step is to plan and execute the attack.\r\nThe two most probable avenues for executing an attack in cloud environments are through control plane APIs or\r\ndata plane APIs.\r\nIn an on-premises IT infrastructure, administrators typically directly connect to each endpoint – such as a router, a\r\nfirewall or network-attached storage – to manage each device. In contrast, users rarely directly connect to\r\nresources in a cloud environment. Instead, they authenticate with a CSP's API gateway and call a set of control\r\nplane APIs to manage cloud resources. This centralized access control is a double-edged sword. It simplifies the\r\naccess control management, but a leaked credential with high privilege can also be devastating, as every cloud\r\nresource may be accessed with the same key.\r\nControl plane APIs are used for resource management, such as creating/configuring networks, creating/deleting\r\nVM instances and reading/writing resource policies. Data plane APIs are used for accessing data inside individual\r\nresources – for example, reading/writing files on a virtual machine instance or querying data from a database\r\ntable.\r\nUsing the hypothetical examples in the Initial Access section, an attacker could gain access to the control plane if\r\ncloud credentials are found on a compromised laptop or RDP server. Once the attacker is in possession of a cloud\r\nhttps://unit42.paloaltonetworks.com/ransomware-in-public-clouds/\r\nPage 3 of 10\n\ncredential with sufficient privileges, the attacker can authenticate with the API gateway and access cloud\r\nresources.\r\nThe attacker may also compromise cloud resources through the data plane. On a compromised laptop, the attacker\r\nmay find data plane credentials such as VMs’ SSH keys or database passwords. From a compromised RDS server\r\nexposed to the internet, the attacker may use data plane APIs to search for other vulnerable servers in the same\r\nprivate network or harvest credentials in the environment variables or memory.\r\nAttackers can move from the data plane to the control plane or vice versa. For example, an attacker who\r\ncompromises a virtual machine instance through the data plane APIs may find control plane credentials in the\r\ninstance's metadata. On the other hand, an attacker who can access virtual machine service through control plane\r\nAPIs may use features like code execution[1][2] and remote access control to gain access into a VM instance and\r\nattack other hosts from the VM instance through the data plane APIs. In the next section, we will show it is\r\ncommon for attackers to move between the control plane and the data plane to escalate their privileges.\r\nFigure 1. Control plane (red) and data plane (blue) in a cloud infrastructure.\r\nBest Practices to Limit Execution\r\nModern cloud-native infrastructure is built with layers of security boundaries, e.g., containers, namespaces, virtual\r\nmachines, virtual private clouds and account isolation. When possible, create a boundary for each logically\r\nseparated resource and workload to reduce the impact in case of security accidents.\r\nPrivilege Escalation and Lateral Movement\r\nThe objective of a ransomware attack is to extort for ransom by disrupting a victim's business operations and\r\ncausing loss of business revenue. Attackers accomplish this through privilege escalation and lateral movement –\r\ntechniques that can allow them to gain access to valuable resources.\r\nTraditional lateral movement techniques such as remote service hijacking or alternation bypass can still allow\r\nattackers to move laterally in the data plane. For example, attackers may use tools like mimikatz to dump\r\ncredentials in the compromised VM instance, identify reachable endpoints in the same network and pivot to\r\nhttps://unit42.paloaltonetworks.com/ransomware-in-public-clouds/\r\nPage 4 of 10\n\nanother VM instance in the same virtual private clouds (VPC). The vulnerabilities that ransomware routinely\r\nexploits can allow attackers to escalate privileges or perform remote code execution on the compromised VM\r\ninstances.\r\nHowever, the cloud has some additional protections against these vulnerabilities – such as CSPs’ hypervisors or\r\nVPC perimeters, which virtually isolate a group of cloud resources. At the time of writing, no known malware\r\nexploits vulnerabilities in CSPs’ infrastructure to break out of the security boundary. CSPs are also more diligent\r\nin patching and securing their infrastructure than many individual organizations. This means that after attackers\r\ncompromise a VM instance, they for the most part can’t gain access to other cloud resources outside the security\r\nboundaries, unless they find ways into the control plane and pivot using control plane APIs.\r\nAs a result, the more concerning way of achieving privilege escalation and lateral movement is through control\r\nplane APIs. Attackers could potentially bypass all the security boundaries if they obtained the right credentials.\r\nThe defense mechanism for securing control-plane APIs is identity and access management (IAM). Every request\r\nsent to the control plane needs to be first examined by IAM. Any unauthenticated or unauthorized request will be\r\ndropped immediately.\r\nWhy Organizations Should Use Strong IAM Policies\r\nIAM is the most critical component that governs the authentication and authorization of every resource in a cloud\r\nenvironment. Put simply: IAM is the first line of defense in most cloud environments. Therefore, a more \"cloud\r\nnative\" way of performing privilege escalation and lateral movement in the cloud is through IAM\r\nmisconfigurations.\r\nDue to cloud infrastructure's complexity and dynamic nature, cloud identities are often overly permissive,\r\nmeaning that they are granted more permissions than they actually need. We recently analyzed cloud accounts\r\nfrom 200 different organizations and found that nearly all lacked the proper IAM management policy controls to\r\nremain secure.\r\nFor example, a user who only needs to access one storage bucket may be granted permission to access all the\r\nbuckets in the same account/subscription. Similarly, a container that only needs to write to a database may also be\r\ngranted read and delete permissions. Our previous Cloud Threat Report described how misconfigured IAM\r\ncontrols allowed Unit 42 researchers to gain access to source code repositories and many private keys of a multi-million dollar SaaS company.\r\nIt is common that combining a set of permissions enables another unintended permission, leading to privilege\r\nescalation. For example, suppose a user has permission to:\r\n1. Access a VM instance.\r\n2. Modify the identity associated with the instance using actions that can update or impersonate the role\r\nassociated with the VM.\r\nIn that case, the user may associate the VM instance with a more privileged identity and use this instance to gain\r\nmore privileged permission.\r\nhttps://unit42.paloaltonetworks.com/ransomware-in-public-clouds/\r\nPage 5 of 10\n\nPrior research such as IAM-Vulnerable, GCP Privilege Escalation, and Azure Privilege Escalation identified many\r\nvulnerable paths to achieve privilege escalation. Tools like pacu and skyArk can help identify privilege escalation\r\nvulnerabilities in IAM – and show organizations where to focus to improve security posture.\r\nThis blog focuses on the potential TTPs of ransomware actors in the cloud. The hypothetical attacks demonstrated\r\nin the next section assume that the attacker already performed various lateral movement and privilege escalation to\r\ngain access to the targeted resources.\r\nImpacts\r\nRansomware impacts the availability or confidentiality of a targeted system. Attacks like data encryption and\r\nsystem lockout affect availability, and attacks like eavesdropping and data exfiltration affect confidentiality. In a\r\ndouble extortion attack, both availability and confidentiality are impacted. 60% of the top ransomware in 2021\r\nattempted to both encrypt the data and exfiltrate the data.\r\nFigure 2. Impacts of ransomware attacks.\r\nTraditional Ransomware\r\nWe consider ransomware that targets Windows or Linux systems in on-premises infrastructure as traditional\r\nransomware, e.g., Ryuk, Maze (ChaCha), Defray777. This type of ransomware attempts to infect many hosts\r\nwithin an organization and then encrypts files on the disk. Traditional ransomware uses file I/O operations to read\r\nand write files in the file systems. Any files that can be accessed through file I/O operations are vulnerable to\r\ntraditional ransomware, including cloud-based file systems remotely mounted to a host such as Network File\r\nSystem (NFS) and Ceph File System (CephFS).\r\nFortunately, due to the differences in file access methods and architectural design, traditional ransomware is less\r\neffective in cloud environments.\r\nhttps://unit42.paloaltonetworks.com/ransomware-in-public-clouds/\r\nPage 6 of 10\n\nMost Cloud Storage Is Accessed Through APIs, Not File Systems\r\nMore and more cloud-native applications rely on CSPs’ APIs to access storage resources. Clients and servers can\r\naccess the storage resources using the same APIs regardless of operating systems or platforms. Applications\r\nrunning on mobile devices, browsers or IoT devices can download/upload any size and type of data. These API-based cloud storage systems are not vulnerable to traditional ransomware because they are not exposed to file\r\nsystems.\r\nMost Compute Resources Are Immutable and Ephemeral\r\nThe design and architecture of cloud-native workloads make them more resilient to traditional ransomware.\r\nCompute resources such as VM instances and containers are usually dedicated to running applications, not storing\r\ndata. Ransomware can still infect these compute resources, but there is no valuable data to encrypt or steal.\r\nFurthermore, compute resources are designed to be immutable and ephemeral, meaning that these resources do not\r\nchange after deployment, and they only “live” for a short time. They are automatically created and deleted by the\r\norchestrator based on the demands of the situation. If an application in a compute resource needs to be updated, a\r\nnew VM instance or container is deployed to replace the old one. These characteristics make establishing\r\npersistence or exfiltrating data from these computer resources difficult for attackers, which contributes to why\r\ncloud environments have so far been more resilient against ransomware than on-premises environments.\r\nCloud-Native Ransomware\r\nThreat actors, however, may develop new TTPs to make it easier for them to launch ransomware attacks in cloud\r\nenvironments. By thinking ahead to what those TTPs might entail, organizations can better prepare to defend\r\nagainst them – and can identify key best practices for improving cloud security posture.\r\nTTPs for cloud ransomware actors would likely focus on finding the cloud resources that contain persistent data\r\nsuch as object storage, block storage and databases, and then on using cloud APIs to access and encrypt that data.\r\nBecause the APIs for accessing every cloud service are very different, threat actors might choose to focus on\r\nspecific services, or they might develop a different payload for each targeted service (as some traditional\r\nransomware actors today have developed payloads targeting different operating systems).\r\nFor example, ransomware targeting one CSP’s storage service will be different from ransomware targeting another\r\nCSP’s storage service. Ransomware targeting an object storage service will be different from ransomware\r\ntargeting a database service. Considering the number of different data storage services in each CSP, the good news\r\nfor organizations is that threat actors would likely need more effort in order to launch a successful ransomware\r\nattack in the cloud.\r\nHypothetical Attack\r\nIn this section, we hypothesize a high-level attack scenario. The attack scenario can help us understand the\r\npossible TTPs ransomware actors would use in the cloud and create protection strategies against these attacks. The\r\nnext section will cover several protection and mitigation practices.\r\nhttps://unit42.paloaltonetworks.com/ransomware-in-public-clouds/\r\nPage 7 of 10\n\nFor this hypothetical attack, we assume that the attacker gains initial access from a leaked credential and executes\r\nthe attack using the control plane APIs. Through lateral movement and privilege escalation, the attacker eventually\r\ngains access to the targeted data. The attacker then attempts to encrypt the storage resources using the CSP’s data-at-rest encryption capabilities. The data-at-rest encryption is usually managed by the CSPs and transparent to the\r\nusers, but if the attacker can control the encryption key, they may lock others out of accessing the resources. The\r\nattack scenario contains three stages: Create Master Key, Modify Targeted Resource and Hide Master Key, as\r\nshown in Figure 3.\r\nFigure 3. Hypothetical attack scenario.\r\n1. Create Master Key: As data encryption in public clouds is often done by cloud-native key management\r\nservices, an attacker might start by creating an attacker-controlled master key using the CSP’s key\r\nmanagement services. The key can be created in the victim's cloud environment or in the attacker’s cloud\r\nenvironment. In the second case, the attacker must also have the “cross-account” permission to access\r\ncloud resources in one account from another account.\r\n2. Modify Targeted Resource: In the second step, the attacker attempts to use the attacker-controlled key to\r\nencrypt the victim's cloud resources. Some cloud resources allow the data-at-rest encryption keys to be\r\nchanged after the resources have been created, and the existing data will be automatically re-encrypted\r\nwith the new keys. Some cloud resources do not allow data-at-rest encryption keys to be changed after the\r\nresources have been created. The attacker in this case would then create a decrypted data dump (e.g.,\r\nsnapshots), encrypt the data with the attacker-controlled key, and overwrite the original resource.\r\n3. Hide Master Key: The last step is to hide the attacker-controlled keys from the victims or CSPs. An\r\nattacker might remove the keys from the cloud environments and locally store the raw key material that can\r\nbe used to reconstruct the encryption key.\r\nProtection and Remediation\r\nThe root causes of the hypothetical attack scenario were a credential leak and an overly permissive identity. If the\r\nvictim did not use long-lived credentials, or if the permissions granted to the credential had been more restricted,\r\nthe attack would not be possible. Most cloud workloads do not need full access to the key management service,\r\nnor do they need to update the storage service's data-at-rest keys. As a result, securing identities is the most\r\nimportant step to start securing a cloud environment.\r\nWhile a comprehensive protection strategy against ransomware attacks is out of the scope of this research, major\r\nCSPs have all published guidelines to protect their customers (for example, see guidelines from Azure and GCP).\r\nBelow is a list of best practices that are CSP-agnostic.\r\nhttps://unit42.paloaltonetworks.com/ransomware-in-public-clouds/\r\nPage 8 of 10\n\nSecure IAM:\r\nMinimize the usage of long-lived credentials such as password, access key and service-account key.\r\nEnforce multi-factor authentication (MFA) for APIs that modify business-critical resources such as\r\ndatabase deletion, snapshot deletion and encryption key update.\r\nUse Federated Identity Management (FIM) to centrally manage access control.\r\nGrant each user and identity only the necessary permissions for their jobs. (In other words, follow the\r\nprinciple of least privilege). Tools such as AirIAM and IAM analyzer can help generate least-privilege\r\npermissions.\r\nEnable additional protection:\r\nEnable version control such as blob versioning and object versioning.\r\nEnable delete protection such as database delete protection, object lock and resource lock.\r\nEnable logging on all cloud workloads.\r\nCreate backups:\r\nCreate backups for business-critical data regularly and automatically.\r\nCreate cross-region and cross-account backups to prevent having a single point of failure.\r\nTest and verify the backups regularly.\r\nShift-left security:\r\nAdopt shift-left security to identify vulnerabilities and misconfigurations as early as possible.\r\nIntegrate vulnerability scanner and IaC scanner into every CI/CD pipeline.\r\nTools such as Checkov can identify insecure configurations in infrastructure as code (IaC) across all major\r\nCSPs.\r\nConclusion\r\nPublic clouds offer agile, reliable and scalable storage services that on-premises data centers would find almost\r\nimpossible to keep up with. As cloud adoption is getting faster and more prevalent, cybercriminals will also find\r\nnew ways to go after valuable data.\r\nAlthough we have not seen ransomware groups targeting cloud environments, ransomware attacks are probable\r\nand concerning, and the time to consider and prepare for the possibility of ransomware in the cloud is now. Our\r\nhypothetical attack demonstrates that control plane APIs could be abused to encrypt data in cloud storage and\r\ndatabase.\r\nOverall, we think public clouds are more secure and resilient against ransomware attacks than traditional\r\nenvironments. Centralized APIs, immutable workloads and cloud native-backup services all make protecting\r\ncloud resources easier. In a shared responsibility model, users can focus more on the applications, and the CSPs\r\ntake care of the infrastructure, platform or software, which significantly reduces the attack surface compared to an\r\non-premises data center. With the assistance of Cloud Security Posture Management (CSPM), Cloud Workload\r\nhttps://unit42.paloaltonetworks.com/ransomware-in-public-clouds/\r\nPage 9 of 10\n\nProtection Platform (CWPP) or Cloud Infrastructure Entitlement Management (CIEM) solutions, this also makes\r\nmanaging thousands of dynamic cloud workloads feasible.\r\nUnit 42 offers a ransomware readiness assessment that organizations can use to enhance the ability to quickly and\r\neffectively respond to a ransomware attack. Cloud incident response services can help address and mitigate cloud\r\nsecurity incidents if they do happen.\r\nIf you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident\r\nResponse team or call:\r\nNorth America Toll-Free: 866.486.4842 (866.4.UNIT42)\r\nEMEA: +31.20.299.3130\r\nAPAC: +65.6983.8730\r\nJapan: +81.50.1790.0200\r\nSource: https://unit42.paloaltonetworks.com/ransomware-in-public-clouds/\r\nhttps://unit42.paloaltonetworks.com/ransomware-in-public-clouds/\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://unit42.paloaltonetworks.com/ransomware-in-public-clouds/"
	],
	"report_names": [
		"ransomware-in-public-clouds"
	],
	"threat_actors": [
		{
			"id": "7c053836-8f50-4d40-bc5c-7088967e1b57",
			"created_at": "2022-10-25T16:07:24.549525Z",
			"updated_at": "2026-04-10T02:00:05.03048Z",
			"deleted_at": null,
			"main_name": "Rocke",
			"aliases": [
				"Aged Libra",
				"G0106",
				"Iron Group",
				"Rocke"
			],
			"source_name": "ETDA:Rocke",
			"tools": [
				"Godlua",
				"Kerberods",
				"LSD",
				"Pro-Ocean",
				"Xbash"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "f809bfcb-b200-4988-80a8-be78ef6a52ef",
			"created_at": "2023-01-06T13:46:39.186988Z",
			"updated_at": "2026-04-10T02:00:03.240002Z",
			"deleted_at": null,
			"main_name": "TeamTNT",
			"aliases": [
				"Adept Libra"
			],
			"source_name": "MISPGALAXY:TeamTNT",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "c3ca592f-0669-49bd-ab5c-310007ab2fb4",
			"created_at": "2022-10-25T15:50:23.334495Z",
			"updated_at": "2026-04-10T02:00:05.264841Z",
			"deleted_at": null,
			"main_name": "TeamTNT",
			"aliases": [
				"TeamTNT"
			],
			"source_name": "MITRE:TeamTNT",
			"tools": [
				"Peirates",
				"MimiPenguin",
				"LaZagne",
				"Hildegard"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "905eabd9-2b7f-483d-86bd-0c72f96b4162",
			"created_at": "2023-01-06T13:46:39.02749Z",
			"updated_at": "2026-04-10T02:00:03.185957Z",
			"deleted_at": null,
			"main_name": "Rocke",
			"aliases": [
				"Aged Libra"
			],
			"source_name": "MISPGALAXY:Rocke",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "0b02af5f-2027-42b7-a6f2-51e2fd49ba7f",
			"created_at": "2022-10-25T15:50:23.360509Z",
			"updated_at": "2026-04-10T02:00:05.337702Z",
			"deleted_at": null,
			"main_name": "Rocke",
			"aliases": [
				"Rocke"
			],
			"source_name": "MITRE:Rocke",
			"tools": null,
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775434320,
	"ts_updated_at": 1775791704,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/a2e2b5d741df3062cb097ac8dc6860615df584c6.pdf",
		"text": "https://archive.orkl.eu/a2e2b5d741df3062cb097ac8dc6860615df584c6.txt",
		"img": "https://archive.orkl.eu/a2e2b5d741df3062cb097ac8dc6860615df584c6.jpg"
	}
}