PubSunuCyberSecuritySunuCyberSecurityCybersecurite pour l'AfriqueTests d'intrusion et audits de securite. Scans automatises, pentest et detection continue.Scanner mon sitePubSunuBarometreSunuBarometreCybersecurite AfriqueDonnees reelles, mises a jour en continu, sans extrapolation.Voir les chiffres
PubSunuCyberSecuritySunuCyberSecurityCybersecurite pour l'AfriqueTests d'intrusion et audits de securite. Scans automatises, pentest et detection continue.Scanner mon sitePubSunuBarometreSunuBarometreCybersecurite AfriqueDonnees reelles, mises a jour en continu, sans extrapolation.Voir les chiffres
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)
Hackers Exploit Qubole's Trusted AWS Access to Breach Customer Accounts and Steal Data
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 KhandelwalNov 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