Uber disclosed on the 16th of September that the company had experienced a security incident in which an attacker — apparently a Lapsus$-affiliated individual — gained access to Uber's internal systems through social engineering of an Uber contractor (Uber security update, September 19). The attack pattern, on Uber's subsequent disclosure and the parallel reporting from Mandiant and other security-research firms, used MFA-fatigue (sometimes called MFA-bombing) as the principal social-engineering vector — repeated MFA push-notification requests against the contractor's account to produce notification-fatigue that ultimately resulted in approval of an attacker-initiated authentication. From the contractor's account, the attacker discovered hardcoded credentials in PowerShell scripts that provided privileged access to Uber's PAM (privileged access management) infrastructure, and from there obtained credentials for several major internal systems including AWS administrative access, GCP administrative access, and various internal-tooling administrative interfaces.
The MFA-fatigue technique is the part of the attack pattern that has the broader operational implications. The attack is not technically sophisticated — push-notification-based MFA is structurally vulnerable to fatigue-based exploitation, and the attacker pattern has been documented in various forms for several years. The defensive countermeasure is move to phishing-resistant MFA (FIDO2 hardware tokens, or push-notification-with-number-matching where the user must verify a number presented in the authentication context against the number shown in the push-notification dialog). The customer-portfolio MFA migration work that I have been writing about for several years has been moving in this direction; the Uber case has accelerated the conversations across the portfolio.
The hardcoded-credentials-in-scripts finding is the second part of the attack that the customer-organisation briefings have been working through. The presence of administrative credentials in shared scripts on internal file-shares is a class of finding that pen-testing engagements have been producing for years and that has been a recurring theme in customer-organisation programme work. The Uber case demonstrates the operational consequence — when the credentials in question provide access to PAM infrastructure that controls credentials for many other systems, the blast radius of the original-credential exposure is substantial.
For the customer-portfolio response, the Uber case has produced two specific waves of work. First, the MFA-posture review across the customer organisations to identify push-notification-only MFA deployments and migrate them to phishing-resistant alternatives. The work continues through Q4 and into 2023. Second, the credential-discovery sweep across customer-organisation file-shares, source-code repositories, and configuration-management systems to identify hardcoded credentials and bring them under proper secret-management. This is the kind of programme work that customer organisations have, on the running pattern, deferred for years; the Uber case has produced the catalysing conversation that several customer organisations have agreed to invest substantively in addressing it.
The wider strategic point is that the Lapsus$-cluster pattern continues to demonstrate that operationally-consequential intrusions can be executed with relatively unsophisticated technical tradecraft when the social-engineering-and-credential-discovery components are competently executed. The defensive disciplines that respond to this — phishing-resistant MFA, employee-and-contractor security awareness against MFA-fatigue specifically, secret-management discipline that prevents credential discovery in the post-compromise environment — are operationally tractable and are now the substantive theme of the post-Uber customer-organisation programme work.
I will return to this. The Lapsus$-affiliated activity continues.