{
	"id": "e8cb3662-6c28-4313-8258-a13959e2cc6d",
	"created_at": "2026-04-06T00:18:21.373988Z",
	"updated_at": "2026-04-10T03:21:12.506543Z",
	"deleted_at": null,
	"sha1_hash": "51bc7d60cc47b54b886462e217b291a25880a531",
	"title": "Old Services, New Tricks: Cloud Metadata Abuse by UNC2903",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2405221,
	"plain_text": "Old Services, New Tricks: Cloud Metadata Abuse by UNC2903\r\nBy Mandiant\r\nPublished: 2022-05-04 · Archived: 2026-04-05 13:52:06 UTC\r\nWritten by: Brandan Schondorfer, Nader Zaveri, Tyler McLellan, Jennifer Brito\r\nSince July 2021, Mandiant identified exploitation of public-facing web applications by UNC2903 to harvest and\r\nabuse credentials using Amazon’s Instance Metadata Service (IMDS). Mandiant tracked access attempts by\r\nUNC2903 to access S3 buckets and additional cloud resources using the stolen credentials. This blog post covers\r\nhow UNC2903 performed exploitation and IMDS abuse, as well as related best practices on cloud hardening\r\ntechniques.\r\nAlthough UNC2903 targeted Amazon Web Services (AWS) environments, many other cloud platforms offer\r\nsimilar metadata services that could be at risk of similar attacks. Similar threat actor motives and operations are\r\ngaining prominence as enterprises continue their migration to cloud hosting services. This article also describes\r\npotential risks and considerations for security and information technology teams using hosted services.\r\nTimeline\r\nMandiant’s Incident Response, Intelligence, and Transformational Services teams collected information described\r\nin this blog post to help better detect, prevent, and respond to similar opportunistic intrusions. The following\r\ntimeline describes UNC2903 activity performed during their earliest observed campaigns.\r\nFebruary 2021, CVE-2021-21311 was published describing vulnerable database administration software\r\ncalled Adminer\r\nFebruary 2021, proof-of-concept code (PoC) was published to show how to leverage the exploit and obtain\r\ncredentials in AWS applications hosting vulnerable versions\r\nJune 2021, UNC2903 exploited a server-side request forgery vulnerability, gaining access to victim\r\nAmazon Web Services secret keys and subsequently steal data\r\nAlthough this blog post discusses a now patched version of Adminer software, any web-application vulnerable to\r\nrequest forgery or remote code execution may also open avenues for similar metadata service attacks.\r\nUsage in the Wild and Evidence of Exploitation\r\nThe Threat Landscape for Cloud Metadata\r\nMandiant’s analysts identified recent upticks in the abuse and exploitation of services hosted in AWS and similar\r\ncloud platforms. The threats identified in campaigns carried out by UNC2903 were multi-phased attacks, which\r\ninvolved infrastructure scanning, reconnaissance and further abuse of the underlying abstraction layers offered by\r\nhttps://www.mandiant.com/resources/cloud-metadata-abuse-unc2903\r\nPage 1 of 18\n\ncloud-hosted platforms. Once exploitation and abuse of the underlying systems occurred, stolen credentials are\r\nleveraged for data exfiltration in other AWS services in the compromised tenant.\r\nNamely, for events leading up to UNC2903 stealing data, Mandiant’s Incident Response team identified:\r\n1. Network scanning attempts on externally facing AWS web infrastructure hosting Adminer software\r\n2. Additional web navigation and reconnaissance performed, once infrastructure is identified\r\n3. Attempts of multiple web application exploits which may exist on the hosted web server\r\n4. Further attempts indicative of manual exploitation and testing using the identified exploit\r\nGiven that the infrastructure is hosted within Amazon Web Services cloud, IMDS is an attractive target for threat\r\nactors like UNC2903. In UNC2903’s case, the threat actor was observed targeting exploitable web applications\r\nwhich were also running IMDSv1. Amazon’s IMDSv1 permits web requests to a specialized URL against the link\r\nlocal IP address (169.254.169.254) which was designed to enhance internal service communication and\r\ntroubleshooting within the overall hosting platform. The retrievable metadata includes information to understand\r\nconfiguration, topology, and even obtain user role and credentialing.\r\nAmazon released IMDSv2 to add additional layers of protection and alerting through AWS security features such\r\nasGuardDuty. The way IMDSv2 remediates this type of attack is by a user obtaining a token via a PUT from\r\nhttp://169.254.169[.]254/latest/api/token, then that token is used and repeated for all requests to the IMDS via a\r\nspecial header ( x-aws-ec2-metadata-token ).\r\nAlthough Amazon recommends implementing the IMDSv2 with GuardDuty enhancements, EC2 instances created\r\nby Amazon customers that instead use IMDSv1 may be at risk when combined with also running unpatched\r\nvulnerable third party software. As the adoption of cloud technology expands, so does the threat surface and\r\ntargeting for vulnerable web infrastructure with underlying dated or deprecated metadata services with limited\r\nsecurity capabilities. The level of risk related to web application vulnerabilities should be evaluated and paired\r\nwith the understanding that underlying metadata services in cloud environments could increase the possibility of\r\nadvanced or continued threats.\r\nClever Techniques, Some SSRF, and Easy Access\r\nMandiant has observed in campaigns that UNC2903 utilized a dedicated operational relay box to perform web\r\nscanning and carry out exploitation and related IMDSv1 abuse. The threat actor carries out a series of web scans\r\nand activity consistent with manual reconnaissance of the identified application prior to the attack. The attack\r\nobserved by UNC2903 utilized a Server-Side Request Forgery (“SSRF”) vulnerability to return the temporary\r\naccess keys used for AWS S3 bucket storage access.\r\nFigure 1 provides the critical attack path identified during UNC2903 using CVE-2021-21311.\r\nhttps://www.mandiant.com/resources/cloud-metadata-abuse-unc2903\r\nPage 2 of 18\n\nFigure 1: UNC2903 attack leveraged CVE-2021-21311 and IMDSv1 abuse\r\nIn the observed campaign, UNC2903 utilized CVE-2021-21311 to perform the following attack:\r\nThreat actor hosts a web server on their operational relay box with a script configured to 301 redirect to\r\nhttp://169.254.169[.]254/latest/meta-data/iam/security-credentials/.\r\nFigure 2: Mandiant test environment\r\nNext, the threat actor navigates to the Adminer page versioned between 4.0.0 and before 4.7.9, of which\r\nthey’re trying to perform the SSRF vulnerability.\r\nhttps://www.mandiant.com/resources/cloud-metadata-abuse-unc2903\r\nPage 3 of 18\n\nThe IP address and port for the operational relay box hosting the malicious redirection script is typed into\r\nthe victim Adminer’s server dialogue box, and the login button is pressed.\r\nFigure 4: Exploiting Adminer\r\nThe victim server with Adminer is fooled into making a web request to the operational relay box, then the\r\nvictim server requests and follows the 301 redirect which completes the SSRF.\r\nhttps://www.mandiant.com/resources/cloud-metadata-abuse-unc2903\r\nPage 4 of 18\n\nThe victim server returns an error to the threat actor, but since the IMDS returns the results from the\r\nservice, the metadata credentials are displayed directly in the response in an error message.\r\nFigure 6: Credential theft\r\nNote that the while these steps do not reflect the exact threat actor commands used to perform an attack, this\r\nhighlights the methods used by UNC2903. Since the attack involves exploitation and SSRF abuse through CVE-2021-21311, limited artifacts are available based on default cloud-based system and tenant configurations.\r\nArtifacts and Notable Observations\r\nMandiant Incident Response identified and collected artifacts of the related exploitation and IMDS abuse carried\r\nout by UNC2903. The activity recorded from initial scanning and exploitation, as well as the AWS metadata\r\nservice and credential abuse may be subject to the configuration of the hosted infrastructure and cloud logs\r\navailable in the tenant. Without a security operator’s keen eye on event logs, even with increased levels of logging\r\nenabled, similar attacks carried out by UNC2903—or other threat actors—may go undetected.\r\nSince the attack leverages an exploit of the Adminer PHP application page, the malicious navigation and\r\ninteraction may be easily overlooked by investigators. The activity identified is characteristically unique compared\r\nto some exploits which return a standard successful web response to the screen or within recorded event logs.\r\nThe few sources which evidenced the exploitation and abuse included:\r\nWeb access and error logs\r\nGuardDuty events\r\nhttps://www.mandiant.com/resources/cloud-metadata-abuse-unc2903\r\nPage 5 of 18\n\nVPC Flow Logs\r\nS3 Data and Access Events\r\nFigure 7 provides an example of the initial access and web application scanning activity identified for the Adminer\r\nweb page. Note that the web response shows a 302 redirect or other 403 error as the web response in the available\r\nlog although the exploit was successful.\r\nFigure 7: Web access logs generated after a simulated attacker types in their server information and performs\r\nCVE-2021-21311\r\nFigure 8 provides an example of a VPC flow which represents the web server when the SSRF completes. Note\r\nthat the victim server which made the outbound request is suspicious to an external IP address. However, the port\r\ncould be configured to any desired, or more discrete, port chosen for an attack.\r\nFigure 8: AWS VPC flow logs noting that the simulated victim server made a web request outbound over a\r\nmalicious port 1337\r\nFigure 9 provides an example of a GuardDuty event after credentials are stolen and leveraged. Note that\r\nGuardDuty in our testing alerted after data theft was complete from the S3 bucket.\r\nhttps://www.mandiant.com/resources/cloud-metadata-abuse-unc2903\r\nPage 6 of 18\n\nFigure 9: AWS GuardDuty event showing data theft from S3 using the stolen metadata credential\r\nMission Completion and Future Implications\r\nFinal phases of attacks carried out by UNC2903, and similar threat actors, have involved data exfiltration or\r\ninteraction with the AWS tenant. The information stolen through application exploitation and metadata service\r\nabuse could allow threat actors to manipulate or steal data from an organization’s cloud environments. Abuse of\r\nsimilar cloud-oriented metadata services show how threat actors can further exploit environments beyond the\r\noriginal application targets. When architecting cloud services and solutions, configurations for prevention and\r\nresponse should be evaluated and considered by the technology teams. Later, we cover potential strategies to\r\nmitigate, limit, and aid in unauthorized metadata service usage detection.\r\nMandiant Intelligence Findings\r\nAttribution\r\nUNC2903 is a group whose motivations are unknown and tracked by Mandiant since July 2021. UNC2903 is\r\nopportunistic, hunting for vulnerable systems on the internet, and has been observed stealing data from at least one\r\nvictim, however, Mandiant did not observe any monetization of the stolen data such as extortion or sale. Analysis\r\nof web logs showed that the actors were specifically scanning for adminer.php and testing for CVE-2019-0211, an\r\nApache Root Privilege Escalation to install the WSO webshell, directly from GitHub.\r\nEighteen minutes after the CVE-2021-21311 vulnerable adminer.php was discovered by the threat actor through\r\nautomated scanning, Mandiant observed indexing of the adminer.php by Telegram bot, indicating that the link to\r\nthe adminer.php was shared in a Telegram chat group. A few minutes later, an automated session from a free VPN\r\nservice also scanned the adminer.php. The same automated process was executed from different a different IP a\r\nhttps://www.mandiant.com/resources/cloud-metadata-abuse-unc2903\r\nPage 7 of 18\n\nfew hours later, followed by interactive activity and successful access of the IMDS service 3 hours and 15 minutes\r\nafter the initial access.\r\nScanning Activity\r\nMandiant observed indications that the UNC2903 infrastructure was used to scan over 2,100 IP addresses in late\r\nJune 2021. Scanning focused on web services such as port 80 or 443 and did not focus on any specific service\r\nprovider suggesting the actor may have been operating from a list of targets with open HTTP ports from prior\r\nresearch and not targeting any specific service provider.\r\nUser Agent Strings\r\nUser agent strings used by UNC2903 observed by Mandiant:\r\nMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)\r\nChrome/91.0.4472.101 Safari/537.36 Edg/91.0.864.48\r\nMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)\r\nChrome/91.0.4472.106 Safari/537.36\r\nMozilla/5.0 (X11; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0\r\nTransform Security and Mitigate Similar Threats\r\nMandiant recommends organizations detect, remediate, and prevent EC2 Instances from having IMDSv1 enabled.\r\nBefore remediating and converting EC2 Instances to use IMDSv2, the organization should test all\r\ninstances/application to ensure the operations will not be impacted by such remediation measures.\r\nUsing our vulnerable Adminer web application, once the EC2 Instance running the application has IMDSv2\r\nenabled, the secrets/credentials are no longer able to be obtained by the threat actor (see Figure 10).\r\nFigure 10: Error message received when attempted to obtain credentials from an EC2 Instance with IMDSv2\r\nenforced\r\nNext we will provide multiple ways an organization can detect, remediate, and prevent IMDSv1 from their\r\nenvironment.\r\nhttps://www.mandiant.com/resources/cloud-metadata-abuse-unc2903\r\nPage 8 of 18\n\nDetections, Remediations, and Preventions\r\nDetecting EC2 Instances with IMDSv1\r\nAudit currently deployed EC2 Instance to verify if IMDSv1 or IMDSv2 is being used in the environment.\r\nNative AWS Services:\r\nAWS Security Hub – Check [EC2.8] EC2 instances should use IMDS v2\r\nCloudWatch – MetadataNoToken (Counts the number of times the Instance Metadata service was\r\nsuccessfully access without a token (i.e., IMDSv1))\r\nAWS Config – A Config rule that checks if the organization’s EC2 Instance is set to require\r\nHTTPTokens (see the following).\r\nAWSTemplateFormatVersion: \"2010-09-09\"\r\nDescription: \"\"\r\nResources:\r\n ConfigRule:\r\n Type: \"AWS::Config::ConfigRule\"\r\n Properties:\r\n ConfigRuleName: \"ec2-imdsv2-check\"\r\n Scope:\r\n ComplianceResourceTypes:\r\n - \"AWS::EC2::Instance\"\r\n Description: \"A Config rule that checks whether your Amazon Elastic Compute Cloud (Amazon EC2) instance me\r\n Source:\r\n Owner: \"AWS\"\r\n SourceIdentifier: \"EC2_IMDSV2_CHECK\"\r\nParameters: {}\r\nMetadata: {}\r\nConditions: {}\r\nOpen-Source Tools:\r\nProwler - Check 7.86 – Check if EC2 Instance Metadata Service Version 2 (IMDSv2) is Enabled\r\nand Required\r\n./prowler -c check786\r\nMetabadger\r\n./metabadger discover-metadata\r\nCloudMapper – EC2_IMDSV2_NOT_ENFORCED\r\nAWS CLI:\r\nhttps://www.mandiant.com/resources/cloud-metadata-abuse-unc2903\r\nPage 9 of 18\n\naws ec2 describe-instances --filters Name=metadata-options.http-tokens,Values=optional --query \"Reservations[*].\r\nInstances[*].{Instance:InstanceId}\" --region [EnterRegionHere]\r\nGuardDuty alert for use of EC2 instance credential from outside of current account.\r\nInstanceCredentialExfiltration.InsideAWS - High: If EC2 Instance Credential is used by another AWS\r\nAccount (see Figure 9 ).\r\nInstanceCredentialExfiltration.OutsideAWS - High: If EC2 Instance Credential is used by an external IP\r\nAddress.\r\nRestrict access to IMDS to a limited set of users or EC2 role\r\nExecute the following command to limit the IMDS service to bobuser:\r\nip-lockdown 169.254.169.254 bobuser\r\nRemediating IDMSv1\r\nNote: Before proceeding to disable IMDSv1 from an organization’s EC2 Instance, there must be extensive testing\r\nperformed prior to the remediation actions.\r\nDisable IMDS completely on infrastructure that does not require the metadata service.\r\naws ec2 modify-instance-metadata-options –instance-id \u003cinstance-id\u003e –http-endpoint disabled\r\nIf IMDS is needed, then an organization can enforce an EC2 Instance to run only IMDSv2:\r\naws ec2 modify-instance-metadata-options –instance-id \u003cINSTANCE-ID\u003e –http-endpoint enabled –http-token required\r\nUtilize an open-source tool, such as Remediate AWS-IMDSv1, to detect and remediate all EC2 instances\r\nthat have IMDSv1 enabled.\r\npython remediate-imdsv1.py --profile \u003cAWS_PROFILE\u003e --remediate –debug\r\nSet iptables rules to DENY access to the metadata service\r\niptables -A OUTPUT –proto tcp -m owner --uid-owner root -d 169.254.169.254 -j REJECT\r\nPreventing IMDSv1 from the Environment\r\nAn organization can create a Service Control Policy (SCP) to require API Calls to utilize IMDSv2 if there\r\nare role credentials for an EC2. See the following Sample SCP:\r\nhttps://www.mandiant.com/resources/cloud-metadata-abuse-unc2903\r\nPage 10 of 18\n\n{\r\n \"Version\": \"2012-10-17\",\r\n \"Statement\": [\r\n {\r\n \"Sid\": \"RequireAllEc2RolesToUseV2\",\r\n \"Effect\": \"Deny\",\r\n \"Action\": \"*\",\r\n \"Resource\": \"*\",\r\n \"Condition\": {\r\n \"NumericLessThan\": {\r\n \"ec2:RoleDelivery\": \"2.0\"\r\n }\r\n }\r\n }\r\n ]\r\n}\r\nAn organization should utilize Infrastructure-as-Code (IaC) to disallow and/or disable the use of IMDSv1.\r\nThere are several ways to enforce IMDSv2, here are a few via CloudFormation:\r\nEC2 AutoScaling Launch Configuration:\r\n{\r\n \"HttpTokens\" : required\r\n}\r\nEC2 Launch Template:\r\n{\r\n \"HttpTokens\" : required\r\n}\r\nCreate a custom CloudFormation or Terraform template that prevents users from launching EC2 instances\r\nthat are not configured for IMDSv2\r\nCloudFormation\r\nAWSTemplateFormatVersion: \"2010-09-09\"\r\nDescription: \"\"\r\nResources:\r\n IamPolicy:\r\n Type: \"AWS::IAM::ManagedPolicy\"\r\n Properties:\r\n PolicyDocument:\r\n Version: \"2012-10-17\"\r\nhttps://www.mandiant.com/resources/cloud-metadata-abuse-unc2903\r\nPage 11 of 18\n\nStatement:\r\n - Action:\r\n - \"ec2:RunInstances\"\r\n Resource:\r\n - \"arn:aws:ec2:*:*:instance/*\"\r\n Effect: \"Deny\"\r\n Condition:\r\n StringNotEquals:\r\n ec2:MetadataHttpTokens: \"required\"\r\n Description: \"An IAM policy that prevents users from launching new EC2 Instances if they are\r\nParameters: {}\r\nMetadata: {}\r\nConditions: {}\r\nTerraform\r\nprovider \"aws\" {\r\n}\r\nresource \"aws_iam_policy\" \"IamPolicy\" {\r\n name = \"Require_IMDSv2\"\r\n description = \"IAM Policy that requires IMDSv2\"\r\n policy = \u003c\u003cPOLICY\r\n{\r\n \"Version\": \"2012-10-17\",\r\n \"Statement\": [\r\n {\r\n \"Action\": [\r\n \"ec2:RunInstances\"\r\n ],\r\n \"Resource\": [\r\n \"arn:aws:ec2:*:*:instance/*\"\r\n ],\r\n \"Effect\": \"Deny\",\r\n \"Condition\": {\r\n \"StringNotEquals\": {\r\n \"ec2:MetadataHttpTokens\": \"required\"\r\n }\r\n }\r\n }\r\n ]\r\n}\r\nPOLICY\r\n}\r\nCreate an IAM Policy that prevents users from launching an EC2 Instance if the EC2 instance is not\r\nconfigured for using IMDSv2.\r\nhttps://www.mandiant.com/resources/cloud-metadata-abuse-unc2903\r\nPage 12 of 18\n\n{\r\n \"Version\": \"2012-10-17\",\r\n \"Statement\": [\r\n {\r\n \"Action\": [\r\n \"ec2:RunInstances\"\r\n ],\r\n \"Resource\": [\r\n \"arn:aws:ec2:*:*:instance/*\"\r\n ],\r\n \"Effect\": \"Deny\",\r\n \"Condition\": {\r\n \"StringNotEquals\": {\r\n \"ec2:MetadataHttpTokens\": \"required\"\r\n }\r\n }\r\n }\r\n ]\r\n}\r\nCreate an IAM Policy that enforces all newly created EC2 Instances are configured to use IMDSv2\r\n(note: existing EC2 Instances will not be impacted by this IAM Policy).\r\n{\r\n \"Version\": \"2012-10-17\",\r\n \"Statement\": {\r\n \"Sid\": \"RequireImdsV2\",\r\n \"Effect\": \"Deny\",\r\n \"Action\": \"ec2:RunInstances\",\r\n \"Resource\": \"arn:aws:ec2:*:*:instance/*\",\r\n \"Condition\": {\r\n \"StringNotEquals\": {\r\n \"ec2:MetadataHttpTokens\": \"required\"\r\n }\r\n }\r\n }\r\n}\r\nAdditional Preventions and Hardening\r\nReview all EC2 Instances, and ensure User Data Scripts for EC2s do not contain cleartext\r\nsecrets or sensitive data\r\nUser Data Scripts are a set of commands that you provide during the launch of\r\nthe EC2. The User Data Scripts are performed using root permissions, and it\r\nhttps://www.mandiant.com/resources/cloud-metadata-abuse-unc2903\r\nPage 13 of 18\n\ncan be viewed via IMDS. An attacker can read the script being ran by a simple\r\ncurl command.\r\ncurl http://169.254.169.254/latest/user-data\r\nLimit the number of HTTP Put Response Hops (minimum value is defaulted to 1 and the maximum is 64).\r\nThe following example limits the maximum number of hops that occurs to 1:\r\n{\r\n \"Version\": \"2012-10-17\",\r\n \"Statement\": {\r\n \"Sid\": \"MaxImdsHopLimit\",\r\n \"Effect\": \"Deny\",\r\n \"Action\": \"ec2:RunInstances\",\r\n \"Resource\": \"arn:aws:ec2:*:*:instance/*\",\r\n \"Condition\": {\r\n \"NumericLessThanEquals\":\r\n {\"ec2:MetadataHttpPutResponseHopLimit\": \"1\"}\r\n }\r\n }\r\n}\r\nLimit API Calls to use IMDSv2 to deliver the Amazon EC2 Role credentials via an IAM Policy\r\n{\r\n \"Version\": \"2012-10-17\",\r\n \"Statement\": {\r\n \"Sid\": \"RequireAllEc2RolesToUseV2\",\r\n \"Effect\": \"Deny\",\r\n \"Action\": \"*\",\r\n \"Resource\": \"*\",\r\n \"Condition\": {\r\n \"NumericLessThan\":\r\n {\"ec2:RoleDelivery\": \"2.0\"}\r\n }\r\n }\r\n}\r\nLimit access to be able to modify the EC2 Instance metadata service\r\n{\r\n \"Version\": \"2012-10-17\",\r\n \"Statement\": {\r\n \"Sid\": \"LimitModifyInstanceMetadataService\",\r\nhttps://www.mandiant.com/resources/cloud-metadata-abuse-unc2903\r\nPage 14 of 18\n\n\"Effect\": \"Deny\",\r\n \"Action\": \"ec2:ModifyInstanceMetadataOptions\",\r\n \"Resource\": \"*\",\r\n \"Condition\": {\r\n \"StringNotLike\":\r\n {\"aws:PrincipalARN”: “arn:aws:iam:*:role/ec2-imds-admin\"}\r\n }\r\n }\r\n}\r\nRestrict the scope of IAM role / credential access to S3 buckets\r\nBlock or reduce of IAM role / credential usage ability from the public Internet\r\nLimit server Internet egress to prevent outbound server traffic\r\nImplement S3 Bucket Policies to further restrict access to the S3 Bucket\r\nEnable VPC flows and S3 bucket / object level access data events\r\nProxy or monitor web requests for possible exploitation\r\nLimit service ports allowed inbound or outbound to the server\r\nSanitize or limit unnecessary HTTP headers to the web server\r\nLog all the things, and prioritize alerting for possible credential abuse\r\nFollow Amazon Web Services best practices for solutions, and regularly test security controls\r\nKey Takeaways\r\nAs organizations move further into cloud environments, additional complexities of default settings can offer\r\nopportunities for an attacker to leverage access from one system, to pivot to many others similar. Data stored in\r\ncloud systems can be stolen, tampered, or deleted just like any other environment. Mandiant’s expertise in\r\nresponding to intrusions extends to cloud environments which continue to be targeted both by espionage and\r\nfinancially motivated groups.\r\nAcknowledgements\r\nWith thanks to Nick Richard for technical review and Justin Moore for MITRE D3FEND mapping.\r\nIndicators\r\n141.94.43.37\r\n37.59.152.171\r\n191.96.108.227\r\n191.96.108.8\r\nhxxps://raw.githubusercontent[.]com/wso3/wso3/master/wso.php\r\n35b03c6bc21d140201670005923333de\r\nMITRE Mappings\r\nhttps://www.mandiant.com/resources/cloud-metadata-abuse-unc2903\r\nPage 15 of 18\n\nMITRE ATT\u0026CK UNC2903\r\nTactic Description\r\nDiscovery    T1580: Cloud Infrastructure Discovery\r\nInitial Access    T1190: Exploit Public-Facing Application\r\nPersistence    T1505.003: Web Shell\r\nCredential Access    T1552.004: Private Keys   T1552.005: Cloud Instance Metadata API\r\nCollection    T1530: Data from Cloud Storage Object\r\nMITRE D3FEND UNC2903\r\nTactic Description\r\nHarden\r\nApplication Hardening\r\nD3-PSEP: Process Segment Execution Prevention\r\nD3-SAOR: Segment Address Offset Randomization\r\nDetect File Analysis\r\nD3-DA: Dynamic Analysis\r\nD3-EFA: Emulated File Analysis\r\nD3-FCR: File Content Rules\r\nD3-FH: File Hashing\r\nNetwork Traffic Analysis\r\nD3-CSPP: Client-Server Payload Profiling\r\nD3-NTCD: Network Traffic Community Deviation\r\nD3-PHDURA: Per Host Download-Upload Ratio Analysis\r\nD3-PMAD: Protocol Metadata Anomaly Detection\r\nhttps://www.mandiant.com/resources/cloud-metadata-abuse-unc2903\r\nPage 16 of 18\n\nD3-RTSD: Remote Terminal Session Detection\r\nD3-UGLPA: User Geolocation Logon Pattern Analysis\r\nD3-ISVA: Inbound Session Volume Analysis\r\nProcess Analysis\r\nD3-DQSA: Database Query String Analysis\r\nD3-PSMD: Process Self-Modification Detection\r\nD3-PSA: Process Spawn Analysis\r\nD3-PLA: Process Lineage Analysis\r\nIsolate\r\nNetwork Isolation\r\nD3-ITF: Inbound Traffic Filtering\r\nD3-OTF: Outbound Traffic Filtering\r\nExecution Isolation\r\nD3-HBPI: Hardware-based Process Isolation\r\nD3-MAC: Mandatory Access Control\r\nD3-EDL: Executable Denylisting\r\nDeceive\r\nDecoy Object\r\nD3-DF: Decoy File\r\nD3-DNR: Decoy Network Resource\r\nD3-DUC: Decoy User Credential\r\nEvict\r\nCredential Invalidation\r\nD3-ACI: Authentication Cache Invalidation\r\nProcess Eviction\r\nD3-PT: Process Termination\r\nPosted in\r\nThreat Intelligence\r\nSecurity \u0026 Identity\r\nhttps://www.mandiant.com/resources/cloud-metadata-abuse-unc2903\r\nPage 17 of 18\n\nSource: https://www.mandiant.com/resources/cloud-metadata-abuse-unc2903\r\nhttps://www.mandiant.com/resources/cloud-metadata-abuse-unc2903\r\nPage 18 of 18\n\nobserved by access keys UNC2903 utilized used for AWS a Server-Side S3 bucket storage Request access. Forgery (“SSRF”) vulnerability to return the temporary\nFigure 1 provides the critical attack path identified during UNC2903 using CVe-2021-21311.\n   Page 2 of 18",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.mandiant.com/resources/cloud-metadata-abuse-unc2903"
	],
	"report_names": [
		"cloud-metadata-abuse-unc2903"
	],
	"threat_actors": [],
	"ts_created_at": 1775434701,
	"ts_updated_at": 1775791272,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/51bc7d60cc47b54b886462e217b291a25880a531.pdf",
		"text": "https://archive.orkl.eu/51bc7d60cc47b54b886462e217b291a25880a531.txt",
		"img": "https://archive.orkl.eu/51bc7d60cc47b54b886462e217b291a25880a531.jpg"
	}
}