{
	"id": "44543eb9-8782-42b1-834e-0444e9e8f4db",
	"created_at": "2026-04-06T01:32:12.218774Z",
	"updated_at": "2026-04-10T03:20:37.982106Z",
	"deleted_at": null,
	"sha1_hash": "9bf9a41a2da446b7a16c10b35a036facbc2b100d",
	"title": "Leaked Environment Variables Allow Large-Scale Extortion Operation in Cloud Environments",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2086991,
	"plain_text": "Leaked Environment Variables Allow Large-Scale Extortion\r\nOperation in Cloud Environments\r\nBy Margaret Kelley, Sean Johnstone, William Gamazo, Nathaniel Quist\r\nPublished: 2024-08-15 · Archived: 2026-04-06 00:17:22 UTC\r\nExecutive Summary\r\nUnit 42 researchers found an extortion campaign's cloud operation that successfully compromised and extorted\r\nmultiple victim organizations. It did so by leveraging exposed environment variable files (.env files) that\r\ncontained sensitive variables such as credentials belonging to various applications.\r\nMultiple security missteps were present in the course of this campaign, including the following:\r\nExposing environment variables\r\nUsing long-lived credentials\r\nAbsence of least privilege architecture\r\nThe campaign operation set up its attack infrastructure within various organizations’ Amazon Web Services\r\n(AWS) environments and used that groundwork to scan more than 230 million unique targets for sensitive\r\ninformation.\r\nThis campaign targeted 110,000 domains resulting in over 90,000 unique variables in the .env files. Of those\r\nvariables, 7,000 belonged to organizations' cloud services and we traced 1,500 variables back to social media\r\naccounts. Additionally, attackers used multiple source networks to facilitate the operation.\r\nBased on our research, the attackers used the following for this extortion campaign:\r\nThe onion router (Tor) network to perform reconnaissance and initial access operations\r\nVirtual private networks (VPN) to achieve lateral movement and perform data exfiltration\r\nVirtual private server (VPS) endpoints for other aspects of the campaign\r\nThe campaign involved attackers successfully ransoming data hosted within cloud storage containers. The event\r\ndid not include attackers encrypting the data before ransom, but rather they exfiltrated the data and placed the\r\nransom note in the compromised cloud storage container.\r\nMoreover, the attackers behind this campaign likely leveraged extensive automation techniques to operate\r\nsuccessfully and rapidly. This indicates that these threat actor groups are both skilled and knowledgeable in\r\nadvanced cloud architectural processes and techniques.\r\nNote that the attackers’ success relied on misconfigurations in victim organizations that inadvertently exposed\r\ntheir .env files. It did not result from vulnerabilities or misconfigurations in cloud providers’ services.\r\nhttps://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/\r\nPage 1 of 20\n\nThis post will detail the cloud extortion campaign by examining different tactics from the MITRE ATT\u0026CK\r\nframework as we recount and explain the events.\r\nPalo Alto Networks customers are better protected from the threats discussed in this article through detection\r\nmechanisms available from the following products:\r\nNext-Generation Firewall\r\nAdvanced WildFire\r\nAdvanced DNS Security\r\nAdvanced URL Filtering\r\nPrisma Cloud, Cortex XDR and XSIAM can be leveraged to protect and monitor your cloud environments.\r\nIf you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response\r\nteam.\r\nRelated Unit 42 Topics Extortion\r\nBackground\r\nThis article exposes an extortion operation that targeted cloud environments and leveraged the dynamic scalability\r\nof cloud platforms. It also leveraged multiple cloud services to successfully hold organizations’ cloud data to\r\nransom.\r\nThe events discussed within this post took place within a cloud environment where the account operators\r\ndeployed and used overly permissive IAM credentials. These credentials allowed the threat actors to perform\r\nseveral operations that would not have been possible if the account operators followed cloud security best\r\npractices.\r\nAttackers obtained initial access to victims' cloud environments through exposed environment files (.env) files\r\nwithin the victim organization's web applications. Due to the security risks associated with authentication data\r\nstored inside .env files, organizations should follow security best practices to never expose environment files\r\npublicly.\r\nEnvironment files allow users to define configuration variables used within applications and platforms. These files\r\noften contain secrets such as hard-coded cloud provider access keys, software-as-a-service (SaaS) API keys and\r\ndatabase login information then used by the threat actor for initial access.\r\nThe attack pattern of scanning the internet for domains and exploiting credentials obtained from exposed\r\nenvironment variable files follows a larger pattern we believe propagates through other compromised AWS\r\nenvironments.\r\nNote: The presence of these secrets resulted from misconfigurations of victim organizations who inadvertently\r\nexposed their .env files. None of the listed vendors’ applications or services had vulnerabilities or\r\nmisconfigurations that resulted in this exposure.\r\nhttps://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/\r\nPage 2 of 20\n\nInitial Access (MITRE ATT\u0026CK Technique TA0001)\r\nThe activity discussed in this post resulted from exposed AWS Identity and Access Management (IAM) access\r\nkeys obtained from publicly accessible .env files. The threat actors located these access keys by scanning and\r\nidentifying exposed .env files hosted on unsecured web applications. Once the actors identified the exposed access\r\nkeys, they used those keys to gain access to the hosting cloud environment.\r\nUnit 42 has responded to a variety of incidents involving AWS environments over the last 12 months, including a\r\npreviously reported incident involving a zero-day vulnerability within the SugarCRM platform. We continue to\r\nsee a growing trend of attackers targeting cloud IAM credentials leading to initial access of organizations’ cloud\r\nenvironments.\r\nThe most common initial access vectors for this particular threat originate from organizations inadvertently\r\nmisconfiguring servers, subsequently exposing sensitive files to the public internet, with the most frequently\r\nexposed files being .env files.\r\nDiscovery (MITRE ATT\u0026CK Technique TA0007)\r\nThe threat actor behind this activity performed various discovery API calls to learn more about the environment\r\nand select services to exploit. These discovery operations targeted various services such as the following:\r\nIAM\r\nSecurity Token Service (STS)\r\nSimple Storage Service (S3)\r\nSimple Email Service (SES).\r\nWe found these aforementioned services targeted by threat actors while they looked to expand their operation’s\r\ncontrol over an organization's cloud environment.\r\nAt the beginning of every operation for the discovery phase in this campaign, attackers ran the GetCallerIdentity\r\nAPI call to verify the identity of the user or role assigned to the exposed IAM credential. GetCallerIdentity is the\r\nAWS version of whoami. It returns information about the IAM credentials – associated UserID, AWS account\r\nnumber and the Amazon Resource Name (ARN) – of the principal used to initiate the request, as shown in Figure\r\n1.\r\nFigure 1. Example GetCallerIdentity and response.\r\nhttps://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/\r\nPage 3 of 20\n\nFor background, the AWS UserID is a unique identifier of the entity that performed the call. The AWS account\r\nnumber is the unique 12-digit identifier of the AWS account to which the UserID belongs.\r\nThe ARN includes the AWS account number and human-readable name of the principal performing the call. Every\r\ncloud resource has a unique ARN within an AWS account that, for example, can be subsequently used as a\r\nreference to that entity in CloudTrail logs or CloudFormation templates.\r\nThe ARN states the following information:\r\nThe AWS service it’s associated with\r\nRegion hosting the AWS resource, but for global services like IAM the region is left blank\r\nThe AWS account it's located in\r\nThe IAM resource type associated with this IAM credential (e.g., user, role, or group)\r\nAttackers also successfully attempted the AWS API request ListUsers to gather a list of IAM users in the AWS\r\naccount as well as the API request ListBuckets to identify all the existing S3 buckets. These operations give the\r\nattackers additional insight into what IAM users exist that they could exploit for future lateral movement, and they\r\nprovide S3 bucket names for data exfiltration targets.\r\nThe threat actors then successfully performed more extensive discovery operations against AWS SES with the\r\nfollowing API calls:\r\nGetSendQuota\r\nListVerifiedEmailAddresses\r\nGetAccountSendingEnabled\r\nGetAccount\r\nListIdentities\r\nWhile the threat actor did not successfully use SES beyond the initial discovery operations listed above during this\r\ncampaign, we have found that attackers often target and leverage the SES service to send phishing messages to\r\npotential victims. By leveraging legitimate SES services for phishing attacks, a threat actor's malicious emails\r\noriginate from a trusted source, often allowing them to evade an organization’s defenses.\r\nAll of these various events provided the threat actor with a strong baseline understanding of what resources\r\nexisted throughout the environment and where they could pivot.\r\nPrivilege Escalation (MITRE ATT\u0026CK Tactic TA0004)\r\nFollowing the threat actor’s discovery operations, they identified that the original IAM credential used to gain\r\ninitial access to the cloud environment did not have administrator access to all cloud resources. We determined\r\nthat the attackers discovered the original IAM role used for initial access did have the permissions to both create\r\nnew IAM roles and attach IAM policies to existing roles. Using these capabilities, the attacker successfully\r\nescalated their privileges within victim cloud environments by creating new IAM resources with unlimited access.\r\nTo accomplish this, they first created an IAM role named lambda-ex with the API request CreateRole, then used\r\nthe API call AttachRolePolicy to attach the AWS-managed policy AdministratorAccess to the newly created\r\nhttps://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/\r\nPage 4 of 20\n\nlambda-ex role, as shown in Figure 2.\r\nFigure 2. JSON permissions for the AdministratorAccess policy.\r\nThese two IAM events resulted in a new IAM role with administrative permissions, within the compromised AWS\r\naccount, completing the threat actor’s privilege escalation portion of the attacks. In the following section, we\r\ndiscuss how the threat actors used this role to grant unfettered access to their newly created lambda functions.\r\nExecution (MITRE ATT\u0026CK Tactic TA0002)\r\nFollowing the successful creation of the privileged IAM role, the threat actor attempted to create two different\r\ninfrastructure stacks, one using Amazon Elastic Cloud Compute (EC2) resources and the other with AWS\r\nLambda. By performing these execution tactics, the actors failed to create a security group, key pair and EC2\r\ninstance, but they successfully created multiple lambda functions with the newly created IAM role attached.\r\nThe threat actor attempted to create new EC2 resources to use for cryptomining based on the size of the instance.\r\nThey successfully created new Lambda functions for their automated scanning operation.\r\nFailed EC2 Creation\r\nDuring these failed operations, the attackers first attempted to perform the API call CreateSecurityGroup and\r\nnamed the group security. Then they ran AuthorizeSecurityGroupIngress to create an ingress rule allowing all\r\nports from 0 - 65535 from any IP address (0.0.0.0/0). Following that, they attempted to CreateKeyPair and\r\nRunInstances with Amazon Machine Image (AMI) ID ami-08e8725a42775740f and an EC2 c6g instance type.\r\nC-series instances are compute optimized virtual machines, which are ideal for computationally intensive\r\nworkloads. As such, malicious actors have often used these instances for cryptojacking operations.\r\nThe AMI ID belonged to a publicly accessible Ubuntu 18.04 LTS image in the us-east-1 region and the c6g\r\ninstance type family ran on AWS Graviton2 processors built for compute-intensive workloads.\r\nAll of these actions took place in under a minute, indicating a pre-scripted, automated activity. However, these\r\nactions failed due to limited permissions associated with the compromised IAM user.\r\nSuccessful Lambda Function Creation\r\nFollowing the failed EC2 service actions, the threat actor successfully pivoted to the AWS Lambda service, a\r\ncloud-based serverless computation service, where they used the granted permissions obtained from the exposed\r\nhttps://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/\r\nPage 5 of 20\n\nIAM credential. Their first operation created a new lambda function using the CreateFunction20150331 API call\r\nin the AWS region us-east-1, which created a new lambda function named ex. We will go into a deep dive into the\r\nlambda function’s code and its purpose in the next section.\r\nOnce the threat actor successfully created the first lambda function, they automatically deployed that same lambda\r\nfunction into every other enabled region in the account within a second. As part of the default lambda function\r\ncreation process, the role attached to the lambda function automatically performs a CreateLogGroup API call\r\nfollowed by CreateLogStream, which begins the process of logging all lambda function operations.\r\nThe CreateLogGroup event created a new CloudWatch log group containing the name of the newly created\r\nlambda /aws/lambda/ex. Each log stream within the log group aggregates various lambda run information by date.\r\nThis allowed us to successfully follow the threat actor's operations using the lambda function ex they created. It is\r\nimportant to note that the lambda function’s logging creation process is automated and attackers cannot turn it off.\r\nThe threat actor created a malicious lambda function by leveraging the stolen IAM user credentials. The Unit 42\r\nreverse engineering team analyzed the malicious lambda function, which consisted of a bash script configured to\r\nperform internet-wide scanning using a preconfigured set of sources containing millions of domains and IP\r\naddresses. Figure 3 displays the complete code of the lambda function.\r\nFigure 3. The lambda function bash script.\r\nThe script retrieved a list of potential targets from a publicly accessible third-party S3 bucket exploited by the\r\nthreat actor. We believe the threat actor hosted these third-party S3 buckets within other compromised and\r\nlegitimate cloud environments, and the threat actor leveraged these resources in this attack. The list of potential\r\ntargets the malicious lambda function iterated over contained a record of victim domains. For each domain in the\r\nlist, the code performed a cURL request, targeting any environment variable files exposed at that domain, (i.e.,\r\nhttp://\u003ctarget\u003e/.env).\r\nUpon successfully retrieving the domain’s exposed environment file, the lambda function uncovered and\r\nidentified cleartext credentials contained within the file. Once the lambda function identified the credentials, it\r\nstored them in a newly created folder within another threat-actor-controlled public S3 bucket.\r\nThe malicious lambda function specifically targeted instances where the .env file referenced the string mailgun as\r\nseen on line 24 within Figure 3. With these compromised Mailgun credentials, threat actors can send large-scale\r\nhttps://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/\r\nPage 6 of 20\n\nphishing attacks against organizations from legitimate domains, making their attacks more likely to bypass\r\nsecurity protections. We accessed the publicly exposed threat actor’s public S3 bucket and assessed that the threat\r\nactor could copy the exposed .env files of at least 110,000 domains.\r\nThe following diagram, Figure 4, shows the threat actor’s architectural design for scanning and retrieving the\r\nexposed authentication credentials in the .env files.\r\nFigure 4. High-level example of the threat actor's operational architecture.\r\nWe believe this design is part of a larger, fully automated operation based upon some of the S3 bucket naming\r\nconventions alone (e.g., s3://\u003cREDACTED\u003e/ref5/). Due to the large number of targeted domains, we have high\r\nconfidence that the attackers heavily relied upon automation to achieve their goals.\r\nFurther evidence for the heavy reliance upon automation came during our analysis of the threat actor’s public S3\r\nbucket. We identified more than 230 million unique targets that the threat actor was scanning for misconfigured\r\nand exposed environment files. Figure 5 shows the contents of the threat actor’s public bucket, listing the number\r\nof configured targets.\r\nhttps://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/\r\nPage 7 of 20\n\nFigure 5. Target count per scan file and total (the name of the file is on the right).\r\nAt the time of access to this public S3 bucket, we estimate that multiple compromised AWS accounts were the\r\ntarget of this malicious scanning as part of a compromise-scan-compromise automated operation. In a later section\r\nof this article, we will describe more details about the misconfigured .env finding.\r\nImpact (MITRE ATT\u0026CK Tactic TA0040)\r\nAfter the threat actor successfully exfiltrated and deleted S3 objects from the target victim’s S3 bucket, they\r\nuploaded a ransom note to the now empty bucket. One example is shown in Figure 7.\r\nFigure 7. Ransom note left by the threat actor.\r\nRansom notes are typically the last step in the extortion process and are designed to scare and coerce the victim to\r\npay an often large fee. Victims make the ransom payment to ostensibly prevent the threat actor from selling or\r\nhttps://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/\r\nPage 8 of 20\n\nleaking their stolen data on the dark web and to hopefully get their deleted data back. See the Unit 42\r\nRansomware and Extortion Report for additional information regarding ransomware and extortion trends.\r\nAttackers often upload ransom notes to the impacted S3 bucket. There are also occurrences where the threat actor\r\nwill email the note to stakeholders of the victim company.\r\nAssessing the Impact of the Leak\r\nAs mentioned earlier, the threat actor created a lambda function to scan an extensive list of domains looking for\r\nmisconfigured and exposed .env files. Ironically, we found we could access the threat actors’ publicly exposed S3\r\nbucket that they used to store and view the stolen .env files. The data in this exposed S3 bucket consisted of the\r\nleaked environment variables collected by the threat actors from the misconfigured publicly exposed .env files.\r\nSome of the .env files contained multiple variables that revealed information about several services used within a\r\nvictim’s infrastructure. Figure 8 shows an example of a complex .env file.\r\nhttps://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/\r\nPage 9 of 20\n\nFigure 8. Example of .env file with more than 40 configurations.\r\nhttps://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/\r\nPage 10 of 20\n\nWe found that the exposed .env files contained a variety of credentials, not only related to cloud infrastructure but\r\nalso to social media accounts and other on-premises applications. Due to the variety of credentials, we categorized\r\nthem based on related services to better represent the breadth of exposed credentials. The chart in Figure 9 shows\r\nthe statistics of credential exposures obtained from the exposed .env files, based on the application type.\r\nFigure 9. Statistics of categorized leaks from .env variables.\r\nWe identified over 90,000 unique combinations of leaked environment variables that contained access keys or\r\nIAM credentials, with 7,000 access keys directly associated with various cloud services. Not all the leaks\r\nnecessarily contained user accounts or secrets, but all of them leaked some details about a victim’s internal\r\ninfrastructure or its configuration.\r\nThe threat actor discovered exposed access keys within these variables and used select access credentials as an\r\ninitial attack vector. Most concerningly, 1,515 of the leaked variables were associated with social media platforms;\r\nsome of them included account names and authentication secret keys.\r\nWe found that while the threat actor’s lambda function initially targeted Mailgun credentials, they captured many\r\nother secrets belonging to cloud service providers and SaaS applications.\r\nAs noted above, the presence of these secrets resulted from misconfigurations in victim organizations, not from\r\nvulnerabilities or misconfigurations in listed vendors’ applications or services.\r\nFigure 10 below shows the breakdown of the top six unique cloud and SaaS secrets stolen and grouped by their\r\nrespective provider.\r\nhttps://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/\r\nPage 11 of 20\n\nFigure 10. Top six cloud and SaaS platforms identified in the .env files.\r\nPlease note that Unit 42 did not assess the validity of these credentials. Through the malicious lambda function,\r\nthe threat actor gained access to several types of credentials. Unit 42 assesses with high confidence that the threat\r\nactor likely leveraged the stolen secrets to carry out further acts against victims.\r\nWe notified AWS about the availability of the public bucket and its role in an ongoing compromise. Shortly after\r\nnotification, the public bucket was no longer available.\r\nNetwork Analysis\r\nWhen reviewing the different components discussed in this article, we identified various correlations based on\r\nnetwork indicators.\r\nThe graph displayed in Figure 11 shows network correlations by IP address, user-agent and exit point type. After\r\ncareful examination of the malicious network traffic, we identified the following exit point categories:\r\nVPN exit node: Known VPN exit point\r\nTor exit node: Tor network\r\nVPS exit node: Hosting provider\r\nInstitution exit node: IP was currently allocated and used by the institution\r\nISP exit node: Internet service provider, giving services directly to users\r\nCloud exit node: The access was performed from a cloud provider\r\nhttps://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/\r\nPage 12 of 20\n\nFigure 11. Network graph of malicious access for all incidents.\r\nWe used internal and public data sources to categorize the originating IP addresses used by the threat actors during\r\nthis campaign according to the exit node type. The activity in Figure 11 above represents access attempts the\r\nthreat actor performed using the AWS IAM credentials either discovered from the victim’s exposed environment\r\nfile or from IAM roles created by the threat actor.\r\nThe threat actor operated discreetly using Tor network connections when creating the lambda function activities.\r\nAfter that, the threat actor pivoted to using a VPN for all S3 access and exfiltration using the S3 Browser tool.\r\nHowever, the threat actor made a connection from a controlled AWS account to access S3 customer internal\r\nbuckets. This event left a trace on AWS-hosted infrastructure that we could follow.\r\nWe assess with medium to high confidence that the threat actor accessed the compromised victims’ AWS\r\nenvironment from IP addresses directly assigned to ISPs. This operational security (OPSEC) misstep allowed us to\r\ndetermine, with medium confidence, the threat actor’s general geographic location.\r\nUnit 42 determined one ISP IP address was geolocated in Ukraine and appeared in part of the lambda function\r\nactivity. The second ISP IP address was geolocated in Morocco and was associated with the S3 access and\r\nexfiltration. Based on the user-agents and time between API calls, we determined the threat actor manually\r\nperformed these access operations, which leaked the threat actor's possible physical location.\r\nCost and Usage Reports\r\nhttps://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/\r\nPage 13 of 20\n\nLogs are essential for effective incident response, and an ideal environment has all logging options enabled. To\r\nidentify exfiltration events from S3 buckets with granularity, organizations should enable S3 access logging or\r\nCloudTrail data events logging prior to an incident occurring.\r\nBoth forms of logging help organizations identify GetObject API calls (e.g., the data being fetched) and\r\nDeleteObject API calls (e.g., the data being deleted). Both S3 access logging and CloudTrail event logging record\r\nthe IP addresses and user agents for each request made to the target bucket.\r\nIt’s important to note that neither of these log sources are enabled by default, and they will increase costs for the\r\norganization’s cloud environment. However, enabling logging for these sources will greatly assist in the\r\nidentification and alerting of malicious cloud operations.\r\nHowever, if neither CloudTrail event logging nor S3 access logs are enabled at the time of an incident, there is still\r\nhope. Leveraging the Cost and Usage report for S3 can allow organizations to identify spikes in the occurrences of\r\nthe API calls for GetObject (bytes out) and DeleteObject (bytes deleted) events.\r\nThere are drawbacks in leveraging Cost and Usage Reports to identify exfiltration operations. Organizations can\r\nonly identify high-level activity that occurred within the bucket and the data can only be aggregated into hourly,\r\ndaily or monthly time frames as shown in Figure 12. This prevents organizations from investigating individual\r\nevents or retrieving the metadata associated with each of the events.\r\nFigure 12. Cost and Usage Report line item examples.\r\nThe GetObject and DeleteObject Cost and Usage Activity records bytes out or bytes deleted, respectively. Using\r\nthese reports, we have successfully assessed the likelihood that exfiltration events have occurred, pointing to key\r\ntime frames when there are anomalous spikes in activity.\r\nRemediation\r\nIn a majority of these attacks, threat actors obtained long-term IAM access keys allowing them to move into the\r\ncontrol plane with no time limit to their credentials. Unless an application or workload requires the use of an\r\naccess key, IAM roles provide the same ability as access keys, but they are temporary. Using temporary\r\ncredentials limits the amount of time a threat actor has access to an account.\r\nAnother way to protect against these attacks is following the principle of least privilege when provisioning\r\npermissions. Limiting the permissions associated with an IAM resource limits the scope of what a compromised\r\ncredential can perform (e.g., restricting identities that can perform iam:CreateRole and iam:AttachRolePolicy).\r\nThat way even if a threat actor were to successfully gain access to long-term or short-term credentials, they\r\nwouldn’t have enough permissions to execute their malicious actions.\r\nAdditionally, disabling all unused regions within an AWS account also protects against these attacks. Threat actors\r\ndeploy resources in multiple regions to attempt to remain undetected, so disabling all unused regions prevents the\r\nhttps://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/\r\nPage 14 of 20\n\nthreat actors from hiding their attacks.\r\nAnd finally, enabling logging and establishing a monitoring process is vital to protecting an organization's\r\nresources. Regarding AWS, enabling basic logging such as CloudTrail and VPC flow logs provides the base level\r\nof visibility into an environment. Amazon GuardDuty also contains a variety of features to help protect against\r\nthreats to EC2 instances and credential exploitation.\r\nDepending on the AWS services used, organizations will want to ensure they enable the specific logging unique to\r\nthat service. After organizations establish the proper logging and retention of that data (90 days minimum\r\nretention recommended), then the focus shifts to monitoring those data sources.\r\nAWS’s GuardDuty provides a base level of alerting, but each organization should review what services they use\r\nand how abnormal activity might appear in the logs. From there, organizations should create alerts for abnormal\r\nactivity.\r\nConclusion\r\nWe identified a wide-scale extortion operation that resulted in the successful compromise of several cloud\r\nenvironments. The initial access used within the extortion campaign was the direct result of exposed environment\r\nfiles (.env) files within the victim organization's web applications.\r\nBy targeting .env files, the threat actor was able to collect the exposed environment files of at least 110,000\r\ndomains. We identified over 90,000 unique leaked environment variables of which 7,000 were associated with\r\ncloud services and 1,500 were associated with social media accounts, oftentimes including account names in\r\naddition to authentication secret keys.\r\nProtections and Mitigations\r\nFor Palo Alto Networks customers, our products and services provide the following coverage associated with the\r\nthreats described above:\r\nNext-Generation Firewall and Advanced WildFire accurately identify known samples as malicious.\r\nAdvanced URL Filtering and Advanced DNS Security identify domains associated with this group as\r\nmalicious.\r\nCortex XDR and XSIAM\r\nPrevent the execution of known malicious malware, and also prevent the execution of unknown\r\nmalware using Behavioral Threat Protection and machine learning based on the Local Analysis\r\nmodule.\r\nProtect against credential gathering tools and techniques using the new Credential Gathering\r\nProtection available from Cortex XDR 3.4.\r\nCortex XDR Pro detects post-exploit activity, including credential-based attacks, with behavioral\r\nanalytics.\r\nPrisma Cloud\r\nAttack Path Policies are built on a unified data model that automatically correlates findings across\r\ncloud misconfigurations, vulnerabilities, excessive IAM permissions and network exposures. When\r\nhttps://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/\r\nPage 15 of 20\n\ncombined with Unit 42 Threat Intelligence, coupled with machine learning (ML) and user and entity\r\nbehavior analytics (UEBA), security teams can detect exploited attack paths.\r\nWhen paired with the WildFire integration, the Prisma Cloud Defender agent will identify malicious\r\nbinaries and make verdict determinations when analyzing executing processes.\r\nWhen paired with XSIAM, the Prisma Cloud Defender is enabled to block malicious processes\r\nfrom operating within the cloud environment.\r\nPrevents the execution of known malicious malware, and also prevents the execution of unknown\r\nmalware using Behavioral Threat Protection and machine learning based on the Local Analysis\r\nmodule.\r\nHunting, Investigation and Detection Queries\r\nThe following queries are intended to assist Palo Alto Networks customers in hunting, investigating and detecting\r\npotentially malicious operations within their Cortex XDR and Prisma Cloud platforms. The results of these\r\nqueries should not be taken as malicious on face value. The queries require careful examination of the resulting\r\nevents before they can be found malicious.\r\nPay close attention to the source IP addresses, user agent and the ARNs for each event. If ARNs are being created,\r\nmodified or deleted, investigate for unwanted modifications to critical infrastructure or the creation of unknown or\r\nsuspicious ARN names. Unit 42 IR services are available for anyone who’s determined they have been breached,\r\ncompromised or otherwise affected by malicious events.\r\nCortex XQL Queries\r\nIAM\r\n1\r\n2\r\n3\r\ndataset=amazon_aws_raw\r\n| filter eventName in (\"CreateRole\", \"AttachRolePolicy\")\r\nSecurity Groups\r\n1\r\n2\r\n3\r\ndataset=amazon_aws_raw\r\n| filter eventName in (\"CreateSecurityGroup\",\r\n\"AuthorizeSecurityGroupIngress\")\r\nEC2\r\nhttps://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/\r\nPage 16 of 20\n\n1\r\n2\r\n3\r\ndataset=amazon_aws_raw\r\n| filter eventName in (\"CreateKeyPair\", \"RunInstances\")\r\nLambda\r\n1\r\n2\r\n3\r\ndataset=amazon_aws_raw\r\n| filter eventName in (\"CreateFunction20150331\", \"CreateLogGroup\", \"CreateLogStream\")\r\nPrisma Cloud RQL Queries\r\nIAM\r\n1\r\nevent from cloud.audit_logs where cloud.type = 'aws' AND cloud.service = 'iam.amazonaws.com' AND\r\noperation IN ( 'CreateRole', 'AttachRolePolicy' ) ADDCOLUMN $.userAgent\r\n$.requestParameters.policyArn\r\nSecurity Groups\r\n1\r\nevent from cloud.audit_logs where cloud.type = 'aws' AND cloud.service = 'iam.amazonaws.com' AND\r\noperation IN ( 'CreateSecurityGroup', 'AuthorizeSecurityGroupIngress' ) ADDCOLUMN $.userAgent\r\n$.requestParameters.policyArn\r\nEC2\r\n1\r\nevent from cloud.audit_logs where cloud.type = 'aws' AND cloud.service = 'iam.amazonaws.com' AND\r\noperation IN ( 'CreateKeyPair', 'RunInstances' ) ADDCOLUMN $.userAgent\r\n$.requestParameters.policyArn\r\nLambda\r\nhttps://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/\r\nPage 17 of 20\n\n1\r\nevent from cloud.audit_logs where cloud.type = 'aws' AND cloud.service = 'iam.amazonaws.com' AND\r\noperation IN ( 'CreateFunction20150331', 'CreateLogGroup', 'CreateLogStream' ) ADDCOLUMN\r\n$.userAgent $.requestParameters.policyArn\r\nPrisma Cloud Attack Path Alerting\r\nPrisma Cloud Attack Paths offer a unique view into the configuration of cloud environments. By linking potential\r\narchitectural misconfigurations, attack path alerts allow security operation center (SOC) personnel the ability to\r\nzero in on potential malicious cloud events.\r\nBy combining DevOps configurations and behavioral anomaly detection rules, attack path alerts trigger if a\r\ncombination of event operations takes place. These alerts scale with the dynamic nature of cloud environments\r\nand allow SOC teams to maintain awareness of security events across multiple cloud platforms.\r\nWhile there are many Attack Path Policies that could assist organizations, the following Attack Path Policies could\r\nassist SOC and DevOps teams monitor and maintain cloud security:\r\nCredential exposure risk due to a publicly exposed and unauthenticated AWS Lambda function with risky\r\ncredential exposure permissions\r\nCredential exposure risk due to a publicly exposed and vulnerable EC2 instance with risky credential\r\nexposure permissions\r\nCredential exposure risk due to malware in Amazon EC2 instances with risky credential exposure\r\npermissions\r\nData breach risk due to a publicly exposed and unauthenticated AWS Lambda function with Amazon RDS\r\ndatabase SQL query execution permissions\r\nData breach risk due to AWS S3 bucket containing sensitive data not configured with access log feature\r\nand is accessible by unmonitored cloud accounts\r\nData exposure and data loss risk due to a publicly exposed unauthenticated AWS Lambda function with\r\npermissions over sensitive S3 configuration\r\nIndicators of Compromise\r\nURL\r\nhttps[:]//github[.]com/brentp/gargs/releases/download/v0.3.9/gargs_linux (not malicious, used by the\r\nlambda function)\r\nIPv4\r\nTor Exit Nodes\r\n109.70.100[.]71\r\n144.172.118[.]62\r\nhttps://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/\r\nPage 18 of 20\n\n176.123.8[.]245\r\n185.100.85[.]25\r\n185.100.87[.]41\r\n185.220.101[.]190\r\n185.220.101[.]19\r\n185.220.101[.]21\r\n185.220.101[.]29\r\n185.220.101[.]30\r\n185.220.101[.]86\r\n185.220.103[.]113\r\n192.42.116[.]181\r\n192.42.116[.]187\r\n192.42.116[.]18\r\n192.42.116[.]192\r\n192.42.116[.]199\r\n192.42.116[.]201\r\n192.42.116[.]208\r\n192.42.116[.]218\r\n198.251.88[.]142\r\n199.249.230[.]161\r\n45.83.104[.]137\r\n62.171.137[.]169\r\n80.67.167[.]81\r\n89.234.157[.]254\r\n94.142.241[.]194\r\n95.214.234[.]103\r\nVPS Endpoints\r\n125.20.131[.]190\r\n196.112.184[.]14\r\n46.150.66[.]226\r\n49.37.170[.]97\r\nVPN Endpoints\r\n139.99.68[.]203\r\n141.95.89[.]92\r\n146.70.184[.]10\r\n178.132.108[.]124\r\n193.42.98[.]65\r\n193.42.99[.]169\r\n193.42.99[.]50\r\nhttps://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/\r\nPage 19 of 20\n\n193.42.99[.]58\r\n195.158.248[.]220\r\n195.158.248[.]60\r\n45.137.126[.]12\r\n45.137.126[.]16\r\n45.137.126[.]18\r\n45.137.126[.]41\r\n45.94.208[.]42\r\n45.94.208[.]63\r\n45.94.208[.]76\r\n45.94.208[.]85\r\n72.55.136[.]154\r\n95.214.216[.]158\r\n95.214.217[.]173\r\n95.214.217[.]224\r\n95.214.217[.]242\r\n95.214.217[.]33\r\nHash\r\nSHA256 for Lambda.sh - 64e6ce23db74aed7c923268e953688fa5cc909cc9d1e84dd46063b62bd649bf6\r\nUpdated title Sept. 3, 2024, at 1:1o p.m. PT for clarity.\r\nSource: https://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/\r\nhttps://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/\r\nPage 20 of 20",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/"
	],
	"report_names": [
		"large-scale-cloud-extortion-operation"
	],
	"threat_actors": [],
	"ts_created_at": 1775439132,
	"ts_updated_at": 1775791237,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/9bf9a41a2da446b7a16c10b35a036facbc2b100d.pdf",
		"text": "https://archive.orkl.eu/9bf9a41a2da446b7a16c10b35a036facbc2b100d.txt",
		"img": "https://archive.orkl.eu/9bf9a41a2da446b7a16c10b35a036facbc2b100d.jpg"
	}
}