High-Profile Access Control Breaches

Introduction

Over the past few years, even the biggest tech firms have fallen victim to attacks exploiting weak or misconfigured access controls. Attackers have leveraged stolen credentials, misused privileged sessions, bypassed multi-factor authentication (MFA), and abused support workflows to infiltrate networks. The fallout has ranged from leaked source code and internal records to costly ransom demands, lawsuits, and damaged reputations.
In this blog post, I discuss some notable incidents involving access control failures, summarising the company, flaw, detection, impact, and remedies for each.

Uber – MFA Fatigue & Hardcoded Credentials [1]

Flaw: In September 2022, an attacker bought an Uber employee’s credentials on the dark web. Uber had MFA on its VPN, but the hacker repeatedly triggered push notifications (“MFA fatigue”) until the employee grudgingly approved one. Once inside, the attacker found PowerShell scripts on a shared drive containing hard-coded super-admin credentials (for Slack, GitHub, etc.). The flaw was twofold: overuse of stored credentials and too-easy MFA approval.
Discovery: Shortly after gaining entry, the hacker allegedly posted screenshots of Uber’s internal intranet on Twitter. Uber discovered the intrusion and quickly locked things down. Uber later confirmed the breach internally.
Impact: The attacker claimed no user data was stolen – the hack appeared aimed at causing disruption or “bragging rights.” Still, it exposed Uber’s secret admin passwords and validated that its remote access was vulnerable to social engineering. Uber’s CISO noted the attacker said, “I can get the entire world’s Internet” after breaching it – a PR hit for the company.
Remediation: Uber revoked the compromised credentials immediately and required re-authentication everywhere. They removed the hard-coded passwords from scripts and introduced a credential vault.
Lessons learned: Never store admin passwords in plain text, enforce truly phishing-resistant MFA, and use contextual MFA policies (e.g. limit push requests). Uber has since improved its employee training on MFA usage and now vets out-of-band MFA requests more carefully.

Reddit – Employee Phishing & 2FA Bypass [2]

Flaw: In early February 2023, Reddit fell victim to a targeted phishing attack. Employees were lured to a fake login page mimicking Reddit’s intranet portal. One employee entered their credentials and submitted 2FA tokens to the phishers. This gave attackers access to some internal systems and code repositories. The underlying flaw was the inability of Reddit’s 2FA system to resist an adversary-in-the-middle phishing site.
Discovery: The employee realised they had been phished and reported the incident to security. Reddit’s CISO confirmed one account had been compromised. The breach was publicly disclosed via a Reddit blog post on February 5, 2023.
Impact: Hackers accessed a limited set of internal documents and source code. Crucially, Reddit said no production systems or user data (private messages, credentials, etc.) were compromised. The stolen information was reportedly limited to “company contacts and employees” data and unspecified source code. Still, exposure of any internal code raised concerns about potential future exploits. The incident did not have a reported financial cost, but served as a cautionary tale in the industry about phishing 2FA.
Remediation: Reddit immediately disabled the compromised credentials and reviewed affected systems.
Lessons learned: Key lessons were to educate employees that 2FA can be phished and to implement stronger MFA (e.g. hardware keys or app-based push with MFA signing). It also highlights the need for anti-phishing training and possibly for pipeline scanning of code repos for credentials.

Salesforce – Data Loader Social-Engineering Attack [3]

Flaw: Attackers used a sophisticated vishing (voice phishing) campaign against employee IT staff at various companies. They convinced targets to visit a fake Salesforce connected-app setup page and approve a malicious, modified version of Salesforce’s Data Loader tool. Once “installed” (i.e. authorised), the fake app had full OAuth access to the victim’s Salesforce data – effectively bypassing normal access controls without a brute-force exploit.
Discovery: Google’s Threat Intelligence observed these attacks over spring 2025 and alerted the world. Google reported that around 20 organisations (mostly in finance/government) were hit by the UNC6040 gang, who then extorted victims with stolen data. Salesforce also warned customers of “voice phishing” and malicious Data Loader in a March 2025 blog. The campaign was discovered by Google after victims identified fraudulent Data Loader installations.
Impact: A subset of those 20 or so companies had data exfiltrated. Once the app was approved, attackers could query and download any Salesforce records and even pivot deeper into networks. The breach is still under investigation, but it caused sensitive corporate and personal data to be stolen from large enterprises. The financial losses include potential extortion payouts and investigation/remediation costs; exact figures are not public.
Remediation: Salesforce emphasised that the issue was not a product vulnerability but user trickery. In response, victims revoked the malicious app grants, rotated OAuth keys, and retrained staff. Google and Salesforce both advise that organisations only approve apps from trusted sources and verify requests (e.g. via out-of-band confirmation). This incident shows that access-control hinges on human judgment: training on vishing and strict app-whitelisting policies are key defences.

Amazon – MOVEit/Clop Vendor Breach [4]

Flaw: Attackers exploited a critical SQL injection zero-day (CVE-2023-34362) in Progress Software’s MOVEit Transfer (file-sharing) product. The Clop ransomware group used this vulnerability in mid-2023 to breach hundreds of organisations’ file systems. Amazon itself was not running MOVEit, but one of its third-party property-management vendors was. Because the vendor handled Amazon employee records, Clop’s breach spilt Amazon data. This was essentially a vendor misconfiguration/vulnerability issue.
Discovery: In November 2024, a threat actor named “Nam3L3ss” claimed on a leak site that he had stolen Amazon data during the MOVEit wave. Amazon confirmed the breach shortly afterwards. Company spokespeople told TechCrunch the only information leaked was basic employee work contact data (email, phone, office location) from that vendor. No Amazon corporate systems were directly compromised, and AWS accounts were unaffected.
Impact: Roughly 2.8 million lines of Amazon employee data appeared on dark-web forums. The data was limited to work emails, desk phone numbers, and office addresses – still, such data can fuel phishing and identity theft. Amazon expects minimal direct financial loss (customer accounts weren’t touched), but the reputational damage was real. Many class-action lawsuits and regulatory inquiries have targeted MOVEit victims and their partners, though Amazon employees have not individually sued to date.
Remediation: Amazon and the vendor patched the MOVEit flaw, informed affected employees, and improved vendor management. The incident underscores the importance of rapidly patching third-party software and monitoring supplier security. It also highlights that even non-sensitive “business contact” data is worth protecting, and that companies should vet how vendors store even this information.

Nvidia – LAPSUS$ Credential Theft [5]

Flaw: In late February 2022, LAPSUS$ claimed to have stolen Nvidia’s internal data. Nvidia confirmed that on February 23, 2022, attackers breached an IT system, exfiltrating employee credentials and proprietary information. The initial vector was likely social engineering or credential reuse (Nvidia later said the attacker accessed an MDM-enrolled VM), but publicly, the key flaw was that valid privileged credentials were compromised.
Discovery: Nvidia’s security team detected the intrusion and immediately hardened its network. LAPSUS$ posted a 20 GB archive of allegedly stolen data on Telegram shortly after the disclosure. Though Nvidia reported no ransomware was deployed and business operations continued, the breach was publicized by BleepingComputer (Nvidia’s statement) and widely reported.
Impact: The attackers released gigabytes of confidential files: driver source code, schematics, technical documentation and more. No customer data was involved. Financially, Nvidia did not report any losses, but the leak of the GPU driver source can hasten the discovery of hardware or software flaws. It also forced Nvidia to revisit its internal access policies. Fortunately for Nvidia shareholders, no direct service disruption occurred.
Remediation: Nvidia stated it engaged forensic experts and law enforcement, then revoked compromised credentials and locked down access. Lessons included enforcing MFA on all privileged accounts, eliminating hard-coded passwords, and isolating high-value repositories. The incident illustrated that even resource-rich companies need zero-trust controls: credentials found in one system should not grant broad access elsewhere. (Security teams advise organisations to disable default accounts, use hardware tokens for admin logins, and monitor for unusual account use.)

Samsung – LAPSUS$ Source Code Leak [6]

Flaw: In early March 2022, LAPSUS$ turned its sights to Samsung. The group published about 190 GB of Samsung’s internal source code, including Galaxy device bootloader code, biometric unlock algorithms, and other sensitive codebases. Samsung confirmed it suffered a “security breach” where attackers exfiltrated internal data. The public details suggest the flaw was again stolen credentials or unauthorised access to source repositories.
Discovery: The breach came to light when LAPSUS$ posted the data online. Samsung issued a statement confirming a breach of internal data (but said no personal customer or employee data was involved). Qualcomm, whose chipsets were implicated in the leaked files, also acknowledged an incident.
Impact: The leaked source code could allow attackers to find firmware vulnerabilities in Samsung devices or clone proprietary technology. Samsung reported that customer business wouldn’t be disrupted, but it did commit to “prevent further such incidents”. No fines or costs have been publicised, but having trade secrets exposed can have a long-term R&D impact and enable malware targeting Samsung devices.
Remediation: Samsung reportedly rotated relevant keys and access tokens after the breach. Its likely tightened network segmentation to prevent lateral movement. The case underscores the need for strong encryption of code repositories and strict network monitoring around R&D servers. Security experts recommend that companies separate production environments from sensitive development systems, employ multi-factor access (e.g. hardware-backed) for all code repositories, and limit employee access to only what’s needed.

Dell Technologies – Alleged Employee Data Leak [7]

Flaw: In September 2024, a hacker known as “grep” posted data claiming to be from Dell: over 10,000 employee records and partner info (identifiers, names, employment status). The attacker also claimed to hold 20 GB of code, credentials, and keys. The exact vulnerability is unconfirmed; it may have been an exposed API, an unsecured server, or a stolen admin credential.
Discovery: The breach was self-reported by the threat actor on a dark-web forum. Dell told the media it was investigating the claims. This was the same group that recently hit Capgemini with a similar claim. There has been no official Dell report on how the data was leaked.
Impact: So far, the posted sample suggests internal employee IDs and status fields were exposed, but not Social Security numbers or payroll data. If verified, Dell’s incident may prompt regulatory and legal scrutiny (as it did with other tech breaches). It serves as a warning about credential safety and API security, since a previous Dell breach (2023) occurred via an abused API that exposed 49 million customer records.
Remediation: Dell immediately engaged incident responders. If confirmed, Dell would likely rotate all exposed keys and audit affected systems. The episode highlights the importance of monitoring for stolen data on hacker forums. Companies are reminded to implement zero-trust principles (no standing admin access), log sensitive data access, and require authorization approvals for employee info.

Key Takeaways

These cases share common themes: attackers often exploit excessive trust (in credentials, tokens, or humans) and lapses in multi-layered controls. In each breach, better access hygiene could have helped. Key lessons across incidents include:

Enforce Least Privilege: Only grant accounts the minimal permissions needed and remove or time-limit admin roles when idle. Avoid “all-powerful” service accounts or hardcoded super-admin credentials that, if stolen, unlock everything.
Harden MFA and Sessions: Use phishing-resistant MFA (hardware tokens, certificate-based or push approvals with context) and monitor for unusual patterns. Limit session duration and bind sessions to IP/geolocation to prevent stolen tokens from replay.
Secure Support and Vendor Access: Treat support portals and third-party access with zero trust. For example, sanitize uploaded logs (HAR files) to strip tokens, require MFA for admin actions, and audit all external vendors who handle your data.
Employee Awareness: Regularly train staff to recognize phishing/vishing. Even strong tech controls (like MFA) can fail under social engineering, as seen at Uber and Salesforce.
Incident Response Preparedness: Have clear plans for rapid credential resets and forensic investigation. In several incidents (Microsoft, Nvidia, Reddit), quick detection and response contained damage.

As these examples show, no organization is immune. However, by rigorously applying modern access-control best practices – zero trust architecture, strict session management, and multi-factor authentication – companies can dramatically reduce the blast radius when breaches inevitably occur.