Case Study 2: The Uber MFA Fatigue Attack — When Lapsus$ Bypassed Multi-Factor Authentication

Overview

On September 15, 2022, Uber Technologies disclosed a significant security breach that compromised internal systems, including access to the company's Slack workspace, vulnerability reports on HackerOne, internal dashboards, and cloud infrastructure. The attacker — later identified as a teenager associated with the Lapsus$ threat group — did not exploit a zero-day vulnerability, bypass advanced security systems, or deploy sophisticated malware. Instead, the breach hinged on a remarkably simple technique: repeatedly sending multi-factor authentication push notifications to a contractor's phone until they approved one.

This case study examines the full attack chain, from initial credential compromise through MFA bypass to lateral movement and data access, drawing lessons for both offensive security professionals and defensive security teams.

The Attack Timeline

Phase 1: Initial Credential Compromise

The attack began with credentials for an Uber EXT (external contractor) account. According to Uber's post-incident disclosure and subsequent investigations, the attacker likely obtained these credentials through one of two vectors:

1. Credential Purchase: The contractor's personal device was infected with the Raccoon Stealer malware, which exfiltrated credentials that were subsequently sold on dark web marketplaces.
2. Social Engineering: The attacker may have directly contacted the contractor posing as Uber IT support.

The contractor's credentials provided access to Uber's VPN, which required multi-factor authentication — a control that should have stopped the attack at this point.

Phase 2: MFA Fatigue

With valid username and password credentials, the attacker initiated VPN login attempts, each triggering an MFA push notification to the contractor's phone via Duo Security. The attacker adopted a simple but effective strategy: send repeated MFA push notifications over an extended period.

The contractor received dozens of push notification prompts over approximately one hour. According to reports, the contractor initially denied each request. However, the attacker then escalated the social engineering component by contacting the contractor on WhatsApp, posing as Uber's IT department:

"I'm from Uber IT. We've noticed unusual activity on your account. To stop the notifications, you need to accept the next login prompt."

The contractor, exhausted by the persistent notifications and seemingly receiving confirmation from "IT support," approved the next MFA push notification. The attacker was now authenticated to Uber's internal network.

Phase 3: Lateral Movement

Once on the internal network via VPN, the attacker performed reconnaissance by scanning internal network shares. On a shared network drive, the attacker discovered PowerShell scripts containing hardcoded administrative credentials for Uber's Privileged Access Management (PAM) system, Thycotic.

With PAM credentials, the attacker gained access to: - AWS Console: Uber's cloud infrastructure on Amazon Web Services - Google Workspace (GCP): Internal Google Cloud resources - Slack: Uber's internal communications platform - HackerOne: Uber's bug bounty platform, containing unresolved vulnerability reports - SentinelOne: Uber's endpoint detection and response (EDR) platform - Internal Dashboards: Financial and operational data

Phase 4: Discovery and Response

The attacker announced their presence by posting in Uber's internal Slack channel:

"I announce I am a hacker and Uber has suffered a data breach."

The message included a hashtag referencing Uber's compensation practices and a list of compromised internal databases. Many Uber employees initially believed the message was a joke or a prank. It took time for the security team to confirm the breach was real and begin incident response.

Technical Analysis

Why MFA Fatigue Works

MFA fatigue (also called MFA bombing or push notification spam) exploits several human and technical factors:

Human Factors: - Notification Fatigue: Repeated interruptions erode the user's attention and judgment - Desire to Stop Disruption: Users approve prompts to make the notifications cease - Misattribution: Users may assume the prompts are caused by a system glitch rather than an attack - Social Engineering Amplification: A concurrent social engineering call dramatically increases the success rate - Time of Day: Attacks conducted late at night exploit reduced cognitive function

Technical Factors: - No Rate Limiting: Duo Security (at the time) did not limit the number of push notifications within a time window - No Number Matching: The push notification asked only to "approve" or "deny" — it did not require the user to enter a number displayed on the login screen - No Context Information: The push notification did not provide sufficient context (IP address, geographic location, device information) to help the user make an informed decision - Immediate Re-prompt: After a denial, a new prompt could be sent immediately with no cooldown period

The Hardcoded Credentials Problem

The discovery of PAM credentials in PowerShell scripts on network shares represents a separate but critically important vulnerability. This reflects a common pattern in enterprise environments:

• Operations teams create automation scripts that require privileged credentials
• These credentials are hardcoded in scripts for convenience
• Scripts are stored on network shares for team access
• No one reviews or rotates these embedded credentials
• An attacker with any level of internal access can discover them

This "lateral movement via credential discovery" pattern appears in a significant percentage of enterprise breaches and is independent of the MFA bypass that provided initial access.

Lapsus$ Group Profile

Lapsus$ (also stylized as LAPSUS$) is a threat group that gained notoriety in 2022 for breaching numerous high-profile technology companies including Microsoft, Nvidia, Samsung, Okta, and Rockstar Games. The group's notable characteristics include:

• Young Operators: Several identified members were teenagers
• Social Engineering Focus: The group relied heavily on social engineering, SIM swapping, and insider recruitment rather than traditional technical exploitation
• Financial Motivation: The group extorted victims for ransom and sold stolen data
• Public Spectacle: Lapsus$ publicly announced breaches and taunted victims on Telegram

The Uber breach demonstrated that sophisticated technical defenses can be undermined by attackers who target the human element of security systems.

Impact Assessment

Direct Impact

• Data Exposure: Internal tools, vulnerability reports, source code repositories, and employee communications were accessed
• HackerOne Access: Unresolved vulnerability reports potentially exposed security weaknesses to the attacker
• Cloud Infrastructure Access: AWS and GCP access could have enabled data theft, infrastructure manipulation, or persistent backdoor installation
• Operational Disruption: Uber took multiple internal services offline during incident response

Indirect Impact

• Regulatory Scrutiny: The breach attracted attention from regulators, adding to Uber's existing regulatory challenges following the concealed 2016 breach
• Reputational Damage: Public disclosure of the breach and its simplicity undermined confidence in Uber's security posture
• Industry Impact: The breach accelerated industry adoption of phishing-resistant MFA and prompted MFA vendors to implement anti-fatigue controls

Defensive Lessons

MFA Hardening

Following the Uber breach, organizations and MFA vendors implemented several controls to prevent MFA fatigue:

1. Number Matching: Instead of a simple approve/deny prompt, the login screen displays a random number that the user must enter on their phone. This ensures the user is actively participating in the authentication process and can see the login context.

2. Additional Context: Push notifications now include geographic location, IP address, and application name, helping users identify unauthorized login attempts.

3. Rate Limiting: MFA systems now limit the number of push notifications within a time window (e.g., maximum 3 prompts per 10 minutes).

4. Anomaly Detection: Repeated denied MFA prompts trigger security alerts and temporary account lockouts.

5. Phishing-Resistant MFA: FIDO2/WebAuthn security keys are immune to MFA fatigue because they require physical interaction with a hardware device and cryptographically bind to the specific domain.

Broader Security Controls

• Credential Scanning: Automated scanning of network shares, repositories, and scripts for hardcoded credentials
• Privileged Access Management: Enforcing PAM best practices — no hardcoded credentials, session recording, just-in-time access
• Network Segmentation: Limiting what an authenticated VPN user can access on the internal network
• Insider Threat Detection: Monitoring for unusual data access patterns, especially from contractor accounts
• Security Awareness Training: Training users to recognize MFA fatigue attacks and social engineering attempts, with specific guidance to never approve unexpected MFA prompts

Applying to ShopStack Assessment

When assessing ShopStack's MFA implementation, document the following based on the Uber breach lessons:

Discussion Questions

1. The Uber attacker combined technical exploitation (credential theft, network scanning) with social engineering (WhatsApp impersonation). How should organizations defend against attacks that blend these approaches?

2. The contractor approved the MFA prompt after receiving a WhatsApp message claiming to be from Uber IT. What organizational policies and training could have prevented this social engineering from succeeding?

3. Evaluate the statement: "MFA fatigue attacks prove that push-based MFA is fundamentally insecure and should be abandoned in favor of FIDO2/WebAuthn." Do you agree? What practical considerations affect this transition?

4. The hardcoded credentials in PowerShell scripts on network shares were arguably a more severe vulnerability than the MFA bypass. Why do organizations consistently fail to address credential management despite it being a well-known risk?

5. Lapsus$ members were predominantly teenagers without formal training. What does this tell us about the current state of enterprise security? How should this influence how organizations allocate security budgets between technical controls and human-focused defenses?

6. Compare the Uber MFA fatigue attack with a hypothetical adversary-in-the-middle (AitM) attack using a tool like Evilginx2. Which is more scalable? Which is more detectable? Which would FIDO2/WebAuthn prevent?

Timeline Summary

References

• Uber Security Update (September 2022): Official incident disclosure
• Mandiant/Google Threat Intelligence: Lapsus$ Group Analysis
• Duo Security: MFA Fatigue Attack Prevention Guide
• CISA Advisory: Implementing Phishing-Resistant MFA
• KrebsOnSecurity: Lapsus$ Group Profile and Arrest Coverage

Return to Chapter 21: Authentication and Session Attacks