The Hacker News
Il y a 4 jours
Hackers Exploit Qubole's Trusted AWS Access to Breach Customer Accounts and Steal Data
Par [email protected] (The Hacker News)

An attacker broke into AWS accounts belonging to multiple Qubole customers between October 14 and October 26 and stole stored secrets and data, cloud security company Wiz said today. The attacker used credentials for an AWS account that Qubole's platform uses to reach those customers. How the attacker got those credentials has not been disclosed. Qubole, a data lake platform owned by Idera,
Hackers Exploit Qubole's Trusted AWS Access to Breach Customer Accounts and Steal Data
Swati KhandelwalNov 09, 2026Cloud Security / Data Breach
An attacker broke into AWS accounts belonging to multiple Qubole customers between October 14 and October 26 and stole stored secrets and data, cloud security company Wiz said today.
The attacker used credentials for an AWS account that Qubole's platform uses to reach those customers. How the attacker got those credentials has not been disclosed.
Qubole, a data lake platform owned by Idera, operates within its customers' AWS accounts. To let it in, a customer creates an IAM role, which is an AWS identity with its own set of permissions.
The role's trust policy allows Qubole's AWS account to assume the role, granting those permissions. Each request to do this, called AssumeRole, must include a matching code from Qubole known as an External ID.
Apart from the attack, most of the roles the attacker assumed were unused, according to Wiz's researchers. But each role still trusted Qubole's account, so the attacker's requests worked.
Any organization that has connected Qubole to AWS, even one that no longer uses it, should check its CloudTrail logs from October 1 onward. The sign to look for is an AssumeRole request from the account Qubole's platform uses, 805246085872, that came from an address outside AWS.
The researchers did not say whether the credentials have since been disabled or whether the activity has stopped. Neither Qubole nor Idera had posted a statement about the attack on their websites when The Hacker News checked today.
Every AssumeRole request tied to the attacker carried an External ID and was accepted, the researchers said in their technical analysis.
AWS accepts an AssumeRole request for such a role when it comes from the trusted account and includes the correct External ID. The code is not treated as a secret, and anyone with access to the role can view it, according to AWS's external ID guidance.
Sentra spotted the activity in several of its customers' environments and alerted the researchers.
In the accounts the researchers examined, the attacker looked for stored credentials. It read environment variables for Lambda functions, pulled secrets from Secrets Manager, and read values from the SSM Parameter Store.
It then ran the credentials it had found through TruffleHog to test whether they worked. These were the victims' own AWS access keys, Entra ID client secrets, and Okta client credentials.
The attacker also copied data out of S3. It retrieved data from any bucket a role could access rather than searching for specific data, and sometimes downloaded an entire bucket in a single session.
The researchers have not linked this campaign to any other publicly reported activity, and say the targeting does not match what state-backed groups usually go after.
Qubole also lets customers connect with AWS access keys instead of a role. From October 8 to October 11, an attacker used customers' own AWS access keys, which the researchers believe had been set up for Qubole.
That attacker then compromised a few of the victims' cloud environments. This activity has not been linked to the AssumeRole abuse.
Wiz's hunting guidance covers CloudTrail logs from October 1 onward in every AWS account that holds a Qubole role. Look for:
Account: AssumeRole requests where userIdentity.accountId is 805246085872 and sourceIPAddress is not an AWS address. The researchers saw Qubole's real traffic come only from AWS.
IAM principal ID: AIDA3W7DIFLYOLTK63SFS. Any activity from this IAM user should be investigated, because only the attacker used it in the accounts the researchers examined.
IAM principal ID: AIDAJYRRH5Y3A7AAJM2HW, when the source address is outside AWS. The attacker used this IAM user from October 18, but Qubole's normal traffic also uses it.
IP: 57.129.54[.]120 and 2001:41d0:70d[:]7800::, OVH-hosted addresses that the attacker used.
IP: 45.83.220[.]211, 185.209.199[.]73 and 89.37.63[.]175, which are Mullvad VPN addresses. Other VPN users share them, so a match alone is not proof.
Session name: role sessions that start with quiam-, such as quiam-enum.
User agent: TruffleHog on GetCallerIdentity calls from one of the IP addresses above. Look for the same user agent in your identity provider's sign-in logs.
For every suspicious session, review everything it did afterward, especially in Secrets Manager, SSM Parameter Store, Lambda, and S3.
CloudTrail management events log each AssumeRole request and bucket listing, but not which S3 objects were read. That needs S3 data events or S3 server access logs. Several victims lacked the required logs, so responders could not determine which objects the attacker had read.
If the attacker assumed one of your Qubole roles, rotate all secrets, parameters, and Lambda environment variables that role had access to, and revoke the role's active sessions. Rotating a credential does not end sessions that were already issued.
Remove any Qubole role you no longer need, or take Qubole's account out of its trust policy.
Where Qubole supports it, swap the account-wide :root principal in the trust policy for the specific IAM principal that Qubole uses.
Add an aws:SourceIp or aws:SourceVpce condition that limits AssumeRole requests to the vendor's documented network ranges. In this attack, the researchers said, "a source IP condition alone would have blocked every role assumption we observed."
Assume others can see the External ID. It is logged in plain text in CloudTrail, and vendors and infrastructure-as-code files often store it, so do not use it as your only control. After an incident like this, change it to Qubole and use a different value for each role where possible.
Review what each vendor role can reach. Qubole's setup guide includes a sample S3 policy that lets the role read every bucket in the account. Vendor roles are often granted access to Lambda settings, Secrets Manager, SSM parameters, and broad S3 read permissions for convenience, according to the researchers.
Set alerts for AssumeRole requests from a vendor account that arrive through a VPN or a hosting company the vendor has not used before.
Log every account and region with an organization trail, and enable S3 data events or server access logs for buckets that store sensitive data.
Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.
Cloud security, Cyber Attack, data breach, Identity Security, Supply Chain
Critical Rails Flaw Lets Attackers Write Server Files via Crafted ImageMagick Uploads
Hackers Target OpenSSH SSHole Flaw Within Hours of Disclosure, Gain Root on Honeypot
Synology NAS Devices Targeted in Ransomware Attacks Exploiting Patched DSM Flaw
Xen Hypervisor Flaws Let One Malicious VM Read and Write Any Other VM's Memory
The Flood is Coming And The Pipes Were Already Full
OpenSSH Issues Emergency Fix for Flaw Letting Long Passwords Bypass SSH Auth on Alpine Linux
OpenAI AI Pipeline Generates 948 Linux Root Escalation Exploits in 30-Hour Run
5 Active Cyber Threats That Put US Enterprises at Risk in October 2026
ThreatsDay: Apache OFBiz RCE, DreamHost Breach, DeFi Site Hijacks + 17 More Stories
New Wave of Refrigeration Cyberattacks Hits Supermarkets Across Europe, Forcing Stores to Pull Food
The Rise of the Threat Operator: How AI Will Redefine Security Operations and Careers
Red Hat Patches 9.8-Rated Linux TCP RCE Flaw While Ubuntu Releases Fixes for Testing
Is Your Exposure Management Platform Leaving You Exposed? Five Tests to Find Out
Google Issues Patches for Critical Android Flaw That Could Allow RCE Without User Interaction
Apple to Start Scanning Publicly Shared iCloud Photos and Files for Harmful Content
Binance Reveals How Fake Job Interviews and AI Tool Abuse Led to $6.43 Billion Theft
Google Warns LLMjacking Attacks Are Costing Some Enterprises Up to $1 Million in Cloud Charges
Microsoft Paint RCE Fix Now Available, but Windows Update Won't Deliver It
Claude Code's “Don't Ask Again” File Exposes Passwords and Keys in 1,122 Public Copies on GitHub
CISA Confirms Hackers Exploiting WordPress Core Flaw During Software Upgrades
Debian and Ubuntu APT Flaw Lets MitM Attackers Swap Verified Packages and Run Code as Root
The Collapsed Patch Window: Why Runtime Protection is Now Your First Line of Defense Against AI-Driven Attacks
Google Disrupts 1.3 Million-Device Android Botnet, Says TV Box Maker Sold Criminal Access
Hackers Hide Linux Backdoor in Control Web Panel Server to Execute Commands Without Logs
Detect Lateral Movement and Evasive Attacks With Corelight's Open NDR Platform
Beyond CVE Scanning: Book a Demo of Continuous AI-Powered Web Pentesting
See How Bitdefender GravityZone Identifies Shadow AI and Prioritizes Endpoint Risks
Assess Your Organization's AI Code Sprawl Exposure With This Practical Guide
Your SOC Has an Identity Blind Spot. Here's How to Fix It
Learn how to close critical identity visibility gaps in your SOC, detect hidden threats, and accelerate incident response across human, machine, and AI identities.
Join the Experts Roadmap for AI-Ready Security Operations
Evaluate Attack Surface Visibility With an AI Threat Readiness Framework
Learn how to assess AI threat readiness, strengthen attack surface visibility, and prepare security operations for emerging threats in this practical webinar.
BeyondTrust an 8X Gartner® Magic Quadrant™ Leader for PAM
Gain clarity on the PAM market and understand why BeyondTrust is again a Leader.
11 Real Stories: How Identity Exposure Unlocks Active Attack Paths
Map cross-domain privilege escalation to sever breach routes at key choke points.
Governance Sets the Ceiling on Your AI Security Program
See the five moves that raise a Stage 2 Govern score to a defensible Stage 3.
Uncover Identity Dark Matter: SACR Research Brief
Eliminate the blind spots undermining your security. Download the SACR brief.
The Collapsed Patch Window: Why Runtime Protection is Now Your First Line of Defense Against AI-Driven Attacks
Your Attack Surface Is Growing Faster Than Your Team Can Respond
The MSP Margin Math Nobody's Doing: Your Next Technician Might Already be on Payroll
PEDM vs. Standing Elevated Privileges: Control Access Without Flooding the Helpdesk
Publié le 9 novembre 2026
Source originale : The Hacker News
