MFA Fatigue (aka MFA Bombing/Push Spam) is a social engineering attack where the attacker repeatedly triggers MFA push notifications until the victim approves one out of frustration or confusion.

* The attack has a stolen password already; the pushes plus a fake "IT support" nudge wear the victim down into tapping Approve. *

The Uber Breach (September 2022):

• Attacker (Lapsus$ group) obtained an Uber contractor's credentials (likely from the dark web after a prior breach)
• Bombarded the contractor with MFA push notifications repeatedly
• Eventually contacted the victim on WhatsApp, posing as Uber IT support, saying they needed to approve the notification to stop the spam
• The contractor approved → attacker gained access to Uber's internal network

Why it works:

• Exploits human fatigue and annoyance rather than technical flaws
• MFA itself isn't broken — the human factor is the weak point
• Push-based MFA is particularly vulnerable (approve/deny is just a tap)

Defenses:

• Use number-matching MFA (user must type a code displayed on the login screen)
• Implement rate limiting on MFA prompts
• Use FIDO2/hardware keys instead of push notifications
• Train users to report unsolicited MFA prompts immediately

Go deeper:

• MFA fatigue attack (Wikipedia) — push-bombing, the Lapsus$ Uber breach, and the number-matching mitigation.

A nation-state supply chain attack (attributed to Russian SVR/APT29) that compromised ~18,000 organizations through a trojanized software update.

* Because the malicious code is injected before signing, the update ships trusted — then blends into normal Orion traffic, staying hidden for months. *

How it worked:

1. Attackers compromised SolarWinds' build environment for the Orion IT monitoring platform
2. Injected malicious code called the SUNBURST backdoor — pushed to customers unknowingly as part of three separate patches
3. The malicious code was inserted during compilation at SolarWinds, so the trojanized update was digitally signed by SolarWinds and distributed as a legitimate update
4. ~18,000 customers worldwide installed the compromised update
5. The backdoor let attackers intercept communications and steal data, blending in with normal Orion traffic

Timeline:

• Jan 2020: Attack period begins
• Dec 2020: Breach made public; security vendor FireEye was first to discover it
• The attack ran January–December 2020 and went undetected for 8 months

Why it was devastating:

• ~18,000 organizations affected worldwide, including Google and the US government
• The attack exploited trust in the software supply chain — customers trusted SolarWinds' signed updates
• Traditional perimeter security was useless since the malware came from inside a trusted tool
• Professional tradecraft: the malware was de-compiled and re-compiled before deployment to obscure clues about its origin, and the injection was a minimal change — in the build process a file was simply renamed, with no extra process running on the system, making it nearly invisible

Key lesson: Supply chain attacks bypass all traditional defenses because they compromise trusted software before it reaches the customer. Zero Trust architecture and software supply chain verification (e.g., SBOMs, build attestation) are essential countermeasures.

Go deeper:

• Wikipedia: 2020 United States federal government data breach — overview of scope, attribution (APT29/SVR), and the ~18,000 affected organizations.
• CrowdStrike: SUNSPOT — An Implant in the Build Process — technical analysis of the SUNSPOT tool that watched the compiler and swapped in the SUNBURST source file during the Orion build.
• TechTarget: SolarWinds response team recounts early days of attack — incident responders (CrowdStrike, KPMG, SolarWinds) on how the breach was found, including the powered-off VM that held the compiled bad code.