{
	"id": "c8c35106-1021-45b9-b67b-0fd66e063901",
	"created_at": "2026-04-06T00:09:10.374192Z",
	"updated_at": "2026-04-10T13:12:47.170897Z",
	"deleted_at": null,
	"sha1_hash": "07938b102c880350636aaae79cb14d8a1c134f76",
	"title": "Bling Libra’s Tactical Evolution: The Threat Actor Group Behind ShinyHunters Ransomware",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 4211141,
	"plain_text": "Bling Libra’s Tactical Evolution: The Threat Actor Group Behind\r\nShinyHunters Ransomware\r\nBy Margaret Kelley, Chandni Vaya\r\nPublished: 2024-08-23 · Archived: 2026-04-05 20:12:39 UTC\r\nExecutive Summary\r\nIn an incident response engagement handled by Unit 42, the threat actor group Bling Libra (the group behind the\r\nShinyHunters ransomware) showcased their new shift to extorting victims rather than their traditional tactic of\r\nselling/publishing stolen data. This engagement also displayed how the group acquires legitimate credentials,\r\nsourced from public repositories, to gain initial access to an organization’s Amazon Web Services (AWS)\r\nenvironment.\r\nWhile the permissions associated with the compromised credentials limited the impact of the breach, Bling Libra\r\ninfiltrated the organization’s AWS environment and conducted reconnaissance operations. The threat actor group\r\nused tools such as the Amazon Simple Storage Service (S3) Browser and WinSCP to gather information on S3\r\nbucket configurations, access S3 objects and delete data.\r\nThreat actors commonly use S3 Browser and WinSCP during their attacks. To expand incident responders’\r\nunderstanding of how these tools generate events in the logs, this research differentiates activity initiated by the\r\nthreat actors versus activity automatically generated by each tool.\r\nAs businesses increasingly embrace cloud technologies, the threat posed by groups like Bling Libra underscores\r\nthe importance of robust cybersecurity practices. By implementing proactive security measures and monitoring\r\ncritical log sources, organizations can effectively safeguard their cloud assets and mitigate the impact of\r\ncyberthreats.\r\nAWS log sources and services such as Amazon GuardDuty, AWS Config and AWS Security Hub play a crucial\r\nrole in enhancing the security posture of organizations. When using AWS Organizations, using AWS Service\r\nControl Policies and permission boundaries add additional protection. These tools provide valuable insights and\r\nalerts to security analysts, enabling them to monitor and respond to security incidents effectively.\r\nPalo Alto Networks customers are better protected from the threats discussed above through the following\r\nproducts:\r\nCortex XDR for cloud can offer a comprehensive incident story by integrating activity from cloud hosts,\r\ncloud traffic and audit logs together with endpoint and network data.\r\nPalo Alto Networks customers can also take advantage of Prisma Cloud to monitor posture and maintain\r\ncompliance across public clouds.\r\nPalo Alto Networks Cloud Security Agent (CSA) uses XSIAM to provide detection and monitoring\r\ncapabilities to cloud infrastructure through both Prisma Cloud and Cortex cloud agents.\r\nhttps://unit42.paloaltonetworks.com/shinyhunters-ransomware-extortion/\r\nPage 1 of 18\n\nIf you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response\r\nteam.\r\nBling Libra Background: The Threat Actors Behind ShinyHunters\r\nUnless a threat actor leaves specific indicators behind, researchers have a difficult time performing attribution for\r\ncloud attacks. However, the threat actor group Bling Libra does not hold back in making sure their attacks\r\nexplicitly link back to them.\r\nBling Libra first emerged in 2020 and has been linked to significant data breaches, such as the Microsoft GitHub\r\nand the Tokopedia attacks in 2020 as reported by Wired. While Bling Libra’s targets span various industries and\r\ngeographic regions, their modus operandi remains consistent.\r\nThis group typically acquires legitimate credentials before targeting database infrastructure to gather personally\r\nidentifiable information (PII) for resale on underground marketplaces. In 2024, the group shifted from trying to\r\nsell data they’ve collected to extorting their victims, and targeting cloud environments.\r\nIntroduction to MITRE ATT\u0026CK® Framework\r\nThis article uses the MITRE ATT\u0026CK framework to categorize the different tactics present within the attack. The\r\nmatrix comprises 14 unique tactics (Enterprise version 15) and categorizes various common characteristics seen\r\nby threat actors. For more information on the tactics present in this article, each header contains a link to each\r\nspecific tactic and their corresponding techniques. Figure 1 represents the first step in the attack.\r\nFigure 1. Initial access begins with stealing AWS access keys.\r\nInitial Access (TA0001)\r\nTo gain initial access into the organization's AWS environment, the threat actors obtained AWS credentials from a\r\nsensitive file exposed on the internet. The file contained a variety of credentials, but the group specifically targeted\r\nthe exposed AWS access key belonging to an identity and access management (IAM) user and a handful of other\r\nexposed credentials.\r\nhttps://unit42.paloaltonetworks.com/shinyhunters-ransomware-extortion/\r\nPage 2 of 18\n\nThese cloud credentials allowed the threat actors to gain access to the AWS account where this IAM user resided\r\nand perform AWS application program interface (API) calls. The permissions associated with these credentials\r\nonly allowed the attackers to successfully interact with S3 with the AmazonS3FullAccess policy. This AWS-managed policy grants unlimited permissions to S3 resources within an AWS account depending on what other\r\norganizational policies the AWS account might employ.\r\nUnit 42 commonly investigates matters where overly permissive cloud credentials deployed by organizations lead\r\nto further exploitation of an environment. This Bling Libra attack exemplifies the results of not following the\r\nprinciple of least privilege.\r\nDiscovery (TA0007)\r\nOnce Bling Libra gained access to the organization’s AWS environment, they performed a variety of API calls to\r\ndetermine the extent of the permissions the compromised credentials contained. To determine what API calls the\r\nthreat actors made, Unit 42 used CloudTrail logs to track the group’s activities in the environment. CloudTrail logs\r\nall the management events that occur within an AWS account. Figure 2 captures the various discovery attempts.\r\nFigure 2. Discovery begins the attacker’s process of learning more about the environment.\r\nAgainst the IAM service, the threat actor performed ListUsers, which returns a list of the existing users within the\r\nAWS account. Due to the limited permissions associated with the access key, the API call failed.\r\nTo learn more about the S3 buckets that existed within the AWS account, the group performed the ListBuckets\r\nAPI call using the AWS Command Line Interface (CLI). The AWS CLI provides people the ability to interact with\r\nan AWS account through the command line, and it provides the building blocks for automation.\r\nFrom there, the threat actors switched to using the S3 Browser tool to iterate through the S3 buckets in the account\r\nand that generated both GetBucketLocation and GetBucketObjectLockConfiguration events in the CloudTrail\r\nlogs. The S3 Browser tools provide a graphical user interface (GUI) to interact with the S3 buckets within an AWS\r\naccount.\r\nThe S3 Browser analysis section discusses in more depth which API calls the tool automatically generates to help\r\nincident responders differentiate between tool automation and threat actor activity.\r\nData Access and Impact (TA0010 and TA0040)\r\nhttps://unit42.paloaltonetworks.com/shinyhunters-ransomware-extortion/\r\nPage 3 of 18\n\nFollowing the discovery operations, the threat actor waited almost a month before returning and taking disruptive\r\nactions within the organization’s AWS account. Due to both CloudTrail S3 data logging and S3 server access\r\nlogging not being enabled within the organization's AWS environment, no logs existed that showed exfiltration\r\nactivity from the S3 buckets. Figure 3 illustrates the next two stages of the attack.\r\nFigure 3. Data access and impact of the attacker's actions.\r\nAfter waiting that extended period of time, the threat actor group used WinSCP to graphically view all the S3\r\nbuckets in the account. After selecting the Amazon S3 file protocol and entering the access key ID and secret\r\naccess key, the tool automatically generates the ListBuckets API call to populate the list of buckets in the GUI.\r\nDue to the lack of object level logging, no other API calls appeared in the CloudTrail logs until the threat actor\r\ndeleted a handful of buckets, which resulted in the DeleteBucket API call.\r\nAs described below, WinSCP provides various methods to interact with the S3 storage objects in an AWS account.\r\nThe ransom note later sent by the threat actor provided proof of data access, but it did not provide enough\r\nspecifics to determine what S3 data left the environment.\r\nExecution (TA0002)\r\nFollowing the deletion of all the S3 buckets, the threat actor used an automated script with the AWS CLI and\r\nattempted to create new S3 buckets. These buckets had various name variations of contact-shinycorp-tutanota-com-# with the # replaced with ascending numbers. Figure 4 shows the final step – execution of the script.\r\nhttps://unit42.paloaltonetworks.com/shinyhunters-ransomware-extortion/\r\nPage 4 of 18\n\nFigure 4. The attacker creates new S3 buckets.\r\nAll the buckets were created within ten minutes of starting the CreateBucket operations. We see no motive behind\r\ncreating these S3 buckets other than to mock the organization about the attack. Figure 5 shows the full MITRE\r\ntimeline based on key events detailed above.\r\nFigure 5. The MITRE timeline details the attack path taken by the threat actor.\r\nExtortion\r\nAfter Bling Libra performed all the aforementioned actions (i.e., data access via API key, discovery, deletion and\r\ncreation of buckets), they completed their attack by sending an extortion email to the victim organization. The\r\nnote stated the group had shifted to extortion to make more money and that the victim organization had one week\r\nto pay, as seen in Figure 6.\r\nhttps://unit42.paloaltonetworks.com/shinyhunters-ransomware-extortion/\r\nPage 5 of 18\n\nFigure 6. Extortion email.\r\nS3 Browser and WinSCP Analysis\r\nIn many Unit 42 investigations involving cloud compromises, S3 Browser and WinSCP appear in the logs as\r\nthreat actors use them for nefarious activity. Unit 42 performed tests to determine which activity in the AWS\r\nCloudTrail logs came from specific actions taken in the tools’ GUIs versus automation API calls performed by the\r\ntools themselves.\r\nThe following tests used S3 Browser version 11.6.7 and WinSCP version 5.21.7.0.\r\nS3 Browser\r\nUnit 42 performed tests to understand which API calls automatically happen in the background by the tool, and\r\nwhich API calls get logged because of specific actions performed by a user in the GUI. The API calls can be\r\ntracked via the user agent field in the CloudTrail logs, which would contain a value of S3 Browser/\u003cVersion\u003e\r\n(https://s3browser[.]com).\r\nThe test activities we discuss here took place against a bucket we created with data events logging enabled in\r\nCloudTrail, to compare the visibility in management versus data events. Data events provide visibility into the\r\nresource operations performed on or within a resource (e.g., creating, downloading or deleting an object within the\r\nS3 buckets). We denote object-level logging events with an asterisk (*) in the following sections.\r\nThe first connection to the S3 storage service after entering the access key credentials resulted in the API\r\ncalls listed below. As noted in Figures 7 and 8, S3 Browser automatically queries the object list, location\r\nand object lock configuration for the first S3 bucket alphabetically. If the S3 Browser application stays\r\nopen when adding and removing the access key, only ListBuckets and ListDistributions appear in the\r\nCloudTrail logs (shown in Figures 9 and 10):\r\nListBuckets\r\nListObjects*\r\nGetBucketLocation\r\nGetBucketObjectLockConfiguration\r\nListDistributions\r\nhttps://unit42.paloaltonetworks.com/shinyhunters-ransomware-extortion/\r\nPage 6 of 18\n\nFigure 7. First connection to S3 service using S3 Browser.\r\nFigure 8. API calls for first connection to S3 service using S3 Browser.\r\nhttps://unit42.paloaltonetworks.com/shinyhunters-ransomware-extortion/\r\nPage 7 of 18\n\nFigure 9. Connection using the same API keys without closing the S3 Browser.\r\nFigure 10. API calls for the connection using the same API keys without closing the S3 Browser.\r\nWhen selecting and viewing the directory structure of another bucket in S3 Browser, it results in the\r\nfollowing API calls.\r\nListObjects*\r\nGetBucketLocation\r\nGetBucketObjectLockConfiguration\r\nWhen previewing an object in S3 Browser (shown in Figure 11), the previewed file gets downloaded as a\r\ntemporary file locally onto the host running the S3 Browser application. The file then immediately gets\r\nhttps://unit42.paloaltonetworks.com/shinyhunters-ransomware-extortion/\r\nPage 8 of 18\n\ndeleted from disk (even if the preview window is still open with the file in the GUI). The S3 Browser\r\nstores the file in a temporary directory: C:\\Users\\\u003cusername\u003e\\AppData\\Local\\Temp\\S3 Browser\\\r\n\u003cTempFileName\u003e. The CloudTrail logs generate two data events for this action, one of them being\r\nGetObject, which appears in the logs since the object retrieval took place to populate the preview window.\r\nThe HeadObject API call retrieves metadata about the object selected (e.g., its size, last modified date and\r\nmetadata displayed by the application in the Properties tab).\r\nHeadObject*\r\nGetObject*\r\nC:\\Users\\\u003cusername\u003e\\AppData\\Local\\Temp\\S3 Browser\\\u003cTempFileName\u003e\r\nFigure 11. Previewing an object in S3 Browser.\r\nCreating and deleting buckets and objects resulted in Put, Create and Delete API calls as listed below:\r\nDeleteObject*\r\nPutObject*\r\nCreateBucket\r\nDeleteBucket\r\nViewing the permissions in S3 Browser (shown in Figure 12) results in the API calls below for the access\r\ncontrol list (ACL), OwnershipControls and PublicAccessBlock of the currently selected bucket.\r\nGetBucketAcl\r\nGetBucketOwnershipControls\r\nGetBucketPublicAccessBlock\r\nhttps://unit42.paloaltonetworks.com/shinyhunters-ransomware-extortion/\r\nPage 9 of 18\n\nFigure 12. Viewing the permissions of the bucket.\r\nViewing the properties (shown in Figure 13) will result in multiple API calls to gather information about all\r\nthe properties related to the bucket to populate all the information in the Preview window.\r\nGetBucketLogging\r\nGetBucketObjectLockConfiguration\r\nGetBucketReplication\r\nGetBucketVersioning\r\nGetAccelerateConfiguration*\r\nGetBucketRequestPayment\r\nhttps://unit42.paloaltonetworks.com/shinyhunters-ransomware-extortion/\r\nPage 10 of 18\n\nFigure 13. Viewing properties of a bucket in S3 Browser.\r\nAttempting to enable and disable versioning for the bucket (shown in Figure 14) results in the API calls\r\nbelow, which first gather the versioning state and then set it to the required value.\r\nGetBucketVersioning\r\nPutBucketVersioning with request parameter showing the status as shown in Figure 15\r\nFigure 14. Attempting to modify the versioning properties.\r\nhttps://unit42.paloaltonetworks.com/shinyhunters-ransomware-extortion/\r\nPage 11 of 18\n\nFigure 15. Request Parameters of the API call when enabling the versioning for bucket.\r\nAttempting to disable public block access for the bucket (shown in Figure 16) results in the API calls\r\nbelow, which first gather the public access block configuration and then attempts to remove it.\r\nGetBucketPublicAccessBlock\r\nDeleteBucketPublicAccessBlock\r\nPutBucketAcl\r\nhttps://unit42.paloaltonetworks.com/shinyhunters-ransomware-extortion/\r\nPage 12 of 18\n\nFigure 16. Attempting to modify the public access block configuration.\r\nWinSCP\r\nWindows Secure Copy, commonly known as WinSCP, is a popular file transfer application primarily used for\r\ntransferring files between local and remote systems using various protocols such as SFTP, SCP, FTPS and FTP.\r\nWhile not specifically designed for Amazon S3, WinSCP can be configured to interact with S3 buckets. While\r\nWinSCP provides versatile file transfer capabilities, it does not offer dedicated features for managing Amazon S3\r\nstorage, such as advanced bucket and object management functionalities found in S3 Browser.\r\nUnit 42 tested to understand what API calls are automatically made when performing specific actions. WinSCP\r\nAPI calls can be tracked via the user agent field in the CloudTrail logs: WinSCP/\u003cversion\u003e.\r\nThese test activities took place against a bucket we created with data events logging enabled in CloudTrail to\r\ncompare the visibility in management versus data events.\r\nhttps://unit42.paloaltonetworks.com/shinyhunters-ransomware-extortion/\r\nPage 13 of 18\n\nThe first connection to the S3 storage service after entering the access key credentials (shown in Figure 17)\r\nresults in the API call below to list all the buckets in the GUI:\r\nListBuckets\r\nFigure 17. Connection to S3 using WinSCP.\r\nViewing the properties of an object will result in an API call that returns metadata about the object such as\r\nlocation, size, owner, ACL as shown in Figure 18.\r\nGetObjectAcl*\r\nhttps://unit42.paloaltonetworks.com/shinyhunters-ransomware-extortion/\r\nPage 14 of 18\n\nFigure 18. Viewing the properties of an object in WinSCP.\r\nDownloading, deleting and creating objects and buckets generated the API calls below.\r\nGetObject*\r\nDeleteObject*\r\nPutObject*\r\nCreateBucket\r\nDeleteBucket\r\nWhen comparing the two tools, S3 Browser generates a lot more API calls that automatically appear in the\r\nCloudTrail logs based on user interaction, compared to WinSCP. The difference in the events generated in the\r\nCloudTrail logs comes down to the purpose of the two tools. Being a cloud native tool, S3 Browser takes\r\nadvantage of more AWS features that generate additional API calls versus WinSCP, which works for more file\r\ntransfer types than solely S3. Figure 19 shows the entire attack broken down based on API calls to display the\r\nvarious results from each tool used.\r\nhttps://unit42.paloaltonetworks.com/shinyhunters-ransomware-extortion/\r\nPage 15 of 18\n\nFigure 19. API call-delineated attack chain.\r\nConclusion\r\nAs organizations increasingly migrate their critical operations to the cloud, we continuously witness a concerning\r\ntrend of overly permissive credentials. Threat actors like Bling Libra have evolved their tactics to exploit\r\nmisconfigurations and exposed credentials in cloud environments.\r\nDue to limited permissions of the compromised access keys, the breach covered in this post did not have an\r\nimpact past the S3 buckets. However, in the past, Unit 42 has observed threat actors abusing overly permissive\r\nhttps://unit42.paloaltonetworks.com/shinyhunters-ransomware-extortion/\r\nPage 16 of 18\n\ncredentials to create resources for malicious use or modifying the IAM users and permissions to maintain\r\npersistence within an environment.\r\nUse IAM Access Analyzer to better identify and manage access risks by analyzing resource policies. Additionally,\r\nwhen using AWS Organizations, AWS Service Control Policies and permission boundaries can be used to help\r\nensure that only permitted actions are allowed, regardless of the individual IAM policies within each account.\r\nFigure 20 shows the complete attack path taken by the threat actor as grouped by MITRE tactics.\r\nFigure 20. The MITRE timeline details the attack path taken by the threat actor.\r\nEnsuring appropriately configured security configurations lays the groundwork to better protect organizations\r\nagainst potential breaches and data compromises. In this attack, attaching an S3 bucket policy requiring MFA to\r\nperform sensitive API calls such as DeleteBucket would have provided additional layers of protection against data\r\nloss. For critical data, we recommend replicating the data into another region or account to help ensure availability\r\nand resilience against security breaches including data destruction.\r\nEnsuring adequate protection also involves regularly auditing and updating access controls, encryption settings\r\nand network configurations to align with best practices and compliance requirements. Leveraging services like\r\nAWS Config and AWS Security Hub provides continuous monitoring and assessment of the AWS environment's\r\nsecurity posture.\r\nAdditionally, comprehending the attack lifecycle and the tactics, techniques and procedures (TTPs) of threat actors\r\nallows defenders to build the proper understanding for safeguarding cloud environments. By understanding how\r\nadversaries operate and the stages they go through to achieve their objectives, security analysts can proactively\r\nconfigure and monitor the necessary log sources in AWS . This allows defenders to more effectively detect and\r\nrespond to cloud threats. Additionally, integrating Amazon GuardDuty for threat detection further strengthens\r\nsecurity postures.\r\nPalo Alto Networks customers are better protected from the threats discussed above through the following\r\nproducts:\r\nhttps://unit42.paloaltonetworks.com/shinyhunters-ransomware-extortion/\r\nPage 17 of 18\n\nCortex XDR for cloud can offer a comprehensive incident story by integrating activity from cloud hosts,\r\ncloud traffic and audit logs together with endpoint and network data.\r\nPalo Alto Networks’ customers can also take advantage of Prisma Cloud to monitor posture and maintain\r\ncompliance across public clouds.\r\nPalo Alto Networks’ Cloud Security Agent (CSA) uses XSIAM to provide improved security posture and\r\nfurther enable detection and runtime monitoring capabilities to critical cloud infrastructure through both\r\nPrisma Cloud and Cortex cloud agents.\r\nIf you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response\r\nteam 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\nPalo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA\r\nmembers use this intelligence to rapidly deploy protections to their customers and to systematically disrupt\r\nmalicious cyber actors. Learn more about the Cyber Threat Alliance.\r\nIoCs\r\nThreat actor email address\r\nshinycorp@tutonota[.]com\r\nUser Agents\r\n(X stands for varying version numbers)\r\nS3 Browser/X.X.X (https://s3browser.com)\r\nWinSCP/X.X.X neon/X.X.X\r\naws-cli/X.X.X Python/X.X.X Linux/X.X.X-aws botocore/X.X.X\r\naws-cli/X.X.X md/Botocore#X.X.X ua/X.X os/linux#X.X.X-aws md/arch#x86_64 lang/python#X.X.X\r\nmd/pyimpl#CPython cfg/retry-mode#legacy botocore/X.X.X\r\naws-cli/X.X.X md/Botocore#X.X.X md/awscrt#X.X.X ua/2.0 os/linux#X.X.X md/arch#x86_64\r\nlang/python#X.X.X md/pyimpl#CPython cfg/retry-mode#legacy botocore/X.X.X\r\nSource: https://unit42.paloaltonetworks.com/shinyhunters-ransomware-extortion/\r\nhttps://unit42.paloaltonetworks.com/shinyhunters-ransomware-extortion/\r\nPage 18 of 18",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://unit42.paloaltonetworks.com/shinyhunters-ransomware-extortion/"
	],
	"report_names": [
		"shinyhunters-ransomware-extortion"
	],
	"threat_actors": [
		{
			"id": "c071c8cd-f854-4bad-b28f-0c59346ec348",
			"created_at": "2023-11-08T02:00:07.132524Z",
			"updated_at": "2026-04-10T02:00:03.422366Z",
			"deleted_at": null,
			"main_name": "ShinyHunters",
			"aliases": [],
			"source_name": "MISPGALAXY:ShinyHunters",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "6f7f2ed5-f30d-4a99-ab2d-f596c1d413b2",
			"created_at": "2025-10-24T02:04:50.086223Z",
			"updated_at": "2026-04-10T02:00:03.770068Z",
			"deleted_at": null,
			"main_name": "GOLD CRYSTAL",
			"aliases": [
				"Scattered LAPSUS$ Hunters",
				"ShinyCorp",
				"ShinyHunters"
			],
			"source_name": "Secureworks:GOLD CRYSTAL",
			"tools": [],
			"source_id": "Secureworks",
			"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": "d8dff631-87b0-4320-8352-becff28dbcf1",
			"created_at": "2022-10-25T16:07:24.565038Z",
			"updated_at": "2026-04-10T02:00:05.034516Z",
			"deleted_at": null,
			"main_name": "ShinyHunters",
			"aliases": [],
			"source_name": "ETDA:ShinyHunters",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434150,
	"ts_updated_at": 1775826767,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/07938b102c880350636aaae79cb14d8a1c134f76.pdf",
		"text": "https://archive.orkl.eu/07938b102c880350636aaae79cb14d8a1c134f76.txt",
		"img": "https://archive.orkl.eu/07938b102c880350636aaae79cb14d8a1c134f76.jpg"
	}
}