Between October 14 and 26, an unidentified attacker used stolen IAM credentials tied to the AWS account of Qubole, a big data and analytics platform, to get into the AWS environments of Qubole's customers. Sentra confirmed dozens of victims, and one customer alone lost millions of files. Researchers at Wiz, Sentra, and Mandiant investigated the activity, but the reporting does not name a threat group, assign a threat type, or explain how the attacker obtained the credentials. This analysis draws on reporting from BleepingComputer.

The entry point was a trust relationship. Companies give providers like Qubole access by creating cross-account IAM roles, which are permissions in your AWS account that a named outside account is allowed to take on. If your firm connected AWS to a third-party platform at some point, that trust stays active until someone removes it.

Once inside, the attacker pulled secrets from AWS Secrets Manager, SSM Parameter Store, and Lambda environment variables. They then ran TruffleHog to test which of those secrets still worked. TruffleHog is a legitimate open-source secret-scanning tool that security teams use to find leaked credentials, and it is not malware. Here it confirmed live AWS keys, Microsoft Entra ID client secrets, and Okta client credentials, which meant a foothold in one cloud account could extend into the identity systems that control sign-in to other business applications. Sentra observed the attacker collecting 100 passwords and keys in seven minutes.

No software flaw was involved. AWS stated its services were not compromised and operated as designed. Every step was a valid API call made with valid credentials: ListBuckets, ListObjects, HeadObject, and GetObject, repeated until the attacker had downloaded the contents of every S3 bucket the role could reach. Because a trusted vendor account made these calls, the activity resembled routine administrative use and was harder to separate from normal integration traffic.

The organizations most exposed are those with cross-account roles that trust outside providers, particularly unused roles with broad permissions. Exposure is greater where those roles can read long-lived credentials for other services stored in Secrets Manager, Parameter Store, or Lambda environment variables.

From Secret Scanning to Cloud Compromise: The Credential Abuse Chain

The source confirms most of the chain from the moment the attacker held working Qubole credentials. It does not explain how two Qubole IAM users were compromised in the first place. The stages below separate what researchers documented in this campaign from the general patterns typical of secret-scanning attacks.

Stage 1: Discovery (general pattern, not confirmed here). TruffleHog is an open-source secret scanner. In typical use, it searches GitHub and GitLab repositories, including full commit history, along with S3 buckets, Docker images, and log files. It flags high-entropy strings (random-looking text that resembles a key) and known credential formats, such as AWS access key IDs that begin with AKIA. A key removed in a later commit still exists in Git history, so old mistakes stay discoverable. This maps to MITRE ATT&CK T1552.001 Credentials in Files. For a business, a key a developer committed long ago can still open an account today if no one revoked it.

In this campaign, the confirmed harvesting happened inside victim environments. After gaining access, the attacker pulled secrets from AWS Secrets Manager and SSM Parameter Store and read Lambda environment variables, which often hold database passwords and API tokens that functions need at runtime.

Stage 2: Verification (confirmed). TruffleHog can test each candidate credential against the issuing service's API to see whether it still works. The attacker used this to validate AWS keys, Microsoft Entra ID client secrets, and Okta client credentials. Sentra measured the pace at 100 passwords and keys in seven minutes, which points to automation. The business consequence is scope creep. A breach that starts in one AWS account can extend into identity providers that control sign-in for many other applications.

Stage 3: Initial access (confirmed). With two compromised Qubole IAM users, the attacker called the STS AssumeRole API to obtain temporary credentials for roles in customer accounts. These roles had been configured to trust Qubole but were otherwise unused. This is T1078.004 Valid Accounts: Cloud Accounts. In general, attackers run these calls through the AWS CLI or an SDK, the same tooling legitimate automation uses. Because the trust relationship was valid, AWS treated each role assumption as authorized, and the attacker received whatever permissions the role carried.

Stage 4: Post-access activity (partly confirmed). Wiz documented a repeatable pattern: "assume a role, call ListBuckets to see what the role could reach, call ListObjects and HeadObject to enumerate and inspect the contents, then call GetObject to download them." The attacker downloaded data from every accessible bucket and made no apparent attempt to select specific files. For your organization, that means everything a role could reach is exposed, whatever its sensitivity.

Other activity common in AWS intrusions was not reported in this case, though it fits the pattern:

• Reconnaissance calls such as sts:GetCallerIdentity to confirm which identity a key belongs to, and iam:ListUsers to map the account.
• Privilege escalation by attaching broader policies or assuming more powerful roles.
• Persistence through new IAM users or additional access keys, which maps to T1098 Account Manipulation and keeps access alive after the original credentials are rotated.

The campaign also leaves traces. When TruffleHog verifies an AWS key, it makes a live API call, and unless the attacker changes the default, the tool's user-agent string can appear in the userAgent field of the resulting CloudTrail record. The ListBuckets, ListObjects, HeadObject, and GetObject sequence from a single role session is a second pattern. S3 object-level calls such as GetObject appear in CloudTrail only when data event logging is enabled on your trail.

Why Valid-Credential Intrusions Are Harder to Catch and Costlier to Contain

AWS told reporters that its services "were not compromised by this issue and operated as designed." That statement describes the detection problem. Every request in this campaign came through a role your organization had approved, carrying temporary credentials that AWS issued normally, so the activity looked like a vendor doing routine work.

Perimeter controls such as firewalls and VPN gateways never see this traffic, because it moves between AWS accounts through the provider's API access. Many anomaly rules watch for failed logins, unfamiliar IP ranges, or brute-force patterns, and a valid role assumption triggers none of them. The longer valid-credential access goes unnoticed, the more data and secrets an attacker can collect before your team starts scoping the incident.

Speed makes the lag more expensive. Sentra reported the attacker collected 100 passwords and keys in seven minutes. If your security team reviews cloud alerts daily or weekly, an intruder working at that pace can finish discovery and collection before anyone opens a ticket.

The exposure reaches well past file storage. The attacker downloaded every S3 bucket the role could reach, pulled entries from AWS Secrets Manager and SSM Parameter Store, and read Lambda environment variables. Those stores often hold database connection strings and API keys, which means your databases and connected applications fall inside the blast radius. Validated Microsoft Entra ID client secrets and Okta client credentials extend that reach into your identity systems, where an attacker can access email, SaaS applications, and internal tools under trusted application identities.

The source describes data theft in this campaign. Valid cloud credentials with compute permissions can also be used to launch instances for cryptomining, and your organization pays for that usage on its next AWS invoice. Beyond any unexpected charges, you carry the cost of rotating every exposed secret, reviewing CloudTrail history, and bringing in outside forensic help.

Bulk data theft frequently becomes the basis for extortion demands. The reporting does not mention a ransom demand here. Because the attacker took whatever was reachable instead of targeting specific records, affected companies may not know what was taken until they reconstruct object-level download activity from their logs.

That uncertainty drives your regulatory exposure. If downloaded buckets held personal data of EU residents, customer records covered by U.S. state breach laws, protected health information under HIPAA, or cardholder data under PCI DSS, notification obligations may apply. Those obligations depend on what the data contained, so your legal team cannot assess them until your technical team finishes scoping.

The supply-chain effect cuts both ways. A compromise at one provider opened access to many customer environments at once, because each customer had granted that provider a standing role. Keys and roles you grant to your own vendors and contractors work the same way, and if your stored data includes information about your clients, a breach of your account becomes their incident too.

The root cause in this case is process. Roles were left trusting an external account after they stopped being used, and credentials sat in environment variables and parameter stores where any principal with read access could collect them. Secrets embedded in code, build artifacts, and configuration persist through security product upgrades, and the attack path closes only when teams retire stale integrations and remove plaintext secrets from the places workloads read them.

Detecting and Shutting Down AWS Credential Abuse

Your first step is to search CloudTrail from October 1 onward for sts:AssumeRole events where the calling principal belongs to Qubole's AWS account, then trace every session those calls produced. Wiz documented a repeatable sequence in this campaign: role assumption, then ListBuckets, ListObjects, HeadObject, and GetObject. A session that runs that pattern across many buckets in a short window matches the observed activity and should be contained.

Within the next 24 to 48 hours, work through these steps in order:

• Revoke active role sessions on any role trusted by a third-party account you cannot vouch for. The IAM console's "Revoke active sessions" option attaches a deny policy that invalidates temporary credentials issued before that moment, which cuts off an attacker already inside.
• Rotate every secret the role could read. That includes Secrets Manager entries, SSM Parameter Store values, and Lambda environment variables. Treat any Microsoft Entra ID client secrets and Okta client credentials stored there as exposed, since the attacker validated those credential types, and review sign-in logs in both identity platforms.
• Hunt for follow-on API activity in CloudTrail. Look for bursts of sts:GetCallerIdentity (the call a scanner typically makes to confirm a stolen key works), iam:List*, iam:CreateUser, and iam:CreateAccessKey, especially from unfamiliar IP addresses, ASNs, or user-agent strings.
• Check for new IAM users, roles, and policies created since October 1. These are the usual way an intruder keeps access after you rotate the original credentials.
• Turn on S3 data event logging in CloudTrail and enable AWS's managed threat detection service if it is off. GetObject calls are data events that are not recorded by default, so without them you cannot establish which files left your account.

Those steps tell you whether data and credentials were taken. That answer drives your notification obligations to customers and regulators, so document what you find as you go.

Over the next two to four weeks, shrink the trust relationships this campaign abused:

• Delete cross-account roles for integrations you no longer use. The attacker assumed roles that customers had configured once and then left idle, and AWS's own guidance calls for removing access for integrations no longer in use.
• Tighten trust policies. Name the specific trusted principal, require an external ID, and add aws:SourceIp conditions limited to the provider's documented address ranges.
• Scope role permissions to specific resources. A vendor role that needs one bucket should list that bucket's ARN and should not hold secretsmanager:GetSecretValue or s3:ListAllMyBuckets unless the integration requires them.
• Replace long-lived access keys with IAM roles, IAM Identity Center, or OIDC federation for CI/CD pipelines, and require MFA for human IAM users. Add secret scanning with push protection and pre-commit hooks in your code repositories so new keys are blocked before they are committed.
• Set billing anomaly alerts. Bulk downloads from S3 show up as unexpected data transfer charges, which gives your finance team a second signal alongside security logs.

For the long term, use service control policies in AWS Organizations to deny high-risk actions such as creating IAM users, stopping CloudTrail, or reading secrets outside approved roles. These policies apply even when a trusted role is misused. Move secrets out of Lambda environment variables into a central managed store with automatic rotation, so one compromised role exposes fewer credentials in plain text.

Finally, schedule a recurring audit that lists every cross-account role, its trusted account, its last-used date, and its permissions. Assign an owner to each vendor integration and remove any role that no owner can justify at the next review.

Treat Every Long-Lived AWS Key as a Potential Entry Point

The secret scanner in this campaign was built to help defenders find leaked credentials, and the attacker used it the same way, to confirm which discovered keys still worked. Your real exposure is any static AWS access key, client secret, or vendor credential sitting somewhere reachable, such as a code repository, build artifact, environment variable, or configuration file. These secrets stay valid until someone rotates them, and whoever finds one inherits the access it carries. Sentra observed the attacker collecting secrets at a rate of 100 passwords and keys in seven minutes, so the time between a credential being found and being used can be very short.

The single most useful step for your organization is to scan your own code, container images, and deployment artifacts for exposed AWS keys, then rotate every key the scan turns up. Once those are replaced, move your workloads and integrations toward short-lived, role-based credentials, so a copied secret expires on its own before anyone can reuse it. If you are unsure whether your environment still holds long-lived keys, the team or provider that manages your AWS account and your code repositories can run that scan and tell you what it found. A security assessment is a reasonable next step after that conversation: a 15-minute call, followed by written findings on five areas, including dark web exposure and security controls.