Uber Breach Key Takeaways: Why MFA, Service Account Protection & PAM Must Work Together to Protect Against Compromised Credentials

The recent Uber breach should be a wake-up call in rethinking about how identity protection is implemented and practiced in today’s enterprise environments. Because the most striking aspect of this breach is not just the role compromised credentials played but the failure of the identity protection measures that were in place to prevent the malicious use of those credentials.

This attack, in fact, is a perfect illustration of why identity threats are the most prominent attack vector today because of inherent gaps in current MFA and PAM solutions. In this article, we examine these gaps and discuss Silverfort’s unified approach to identity protection via a purpose-built platform that can thwart those exact threats.

Attack Flow: Compromised Credential all Along the Way

1. Attackers obtained VPN credentials from a third-party contractor. Uber posted that “It is likely that the attacker purchased the contractor’s Uber corporate password on the dark web, after the contractor’s personal device had been infected with malware, exposing those credentials.”
2. With these credentials in hand, the attackers then carried out an MFA bombing attack followed by a direct call to contractor where they impersonated support staff. This resulted in the contractor approving the MFA notification thus granting the attackers access to Uber’s internal environment.
3. Once inside, the attacker scanned the network until finding a network share which, according to the attacker’s tweet, contained some Powershell scripts. One of the Powershell scripts contained the username and password for an admin user in PAM’.  Using this, he was then able access the PAM and extract data from various systems, including DA, Duo, OneLogin, AWS, and Google Workspace.
   Important note: being embedded in a script, this ‘domain user’ was most probably a service account was created to enable the script to perform the authentications it required to fulfill its task. It’s a common practice to hardcode such credentials into a script, but it means that they can’t be vaulted and subject to PAM password rotation, making them vulnerable to attack.
4. From there, they accessed multiple resources at will, including posting an explicit photo on an internal message board.
   
   

Gaps That Enabled the Attack

Analyzing the security measures in place, we see a variety of weaknesses across the MFA and PAM solutions as well as the service account protection that enabled this attack to be successful. Let’s examine each one:

MFA: Limited Protection and Partial Coverage

• Inability to Detect Risky Authentication: The MFA solution in place didn’t have the ability to identify continuously denied access attempts as a risk indicator, resulting in the contractor being prompted over and over.
• Inability to Protect Access to Network Shares: Despite its straightforward user experience, accessing a network share (either via UI or command line) triggers an authentication process in the background over the CIFS protocol. Since this service  doesn’t natively support MFA, there was no protection on accessing the network share.

PAM: Single Point of Failure when Deployed as a Standalone Protection

• Unprotected Access: There was no security control for the initial login to the PAM interface. Requiring MFA for this access would have eliminated the attackers’ ability to utilize the compromised credentials for malicious access.
• Single Point of Failure: Even after an attacker breached the PAM and began accessing data, it didn’t have to go further. A sound security architecture should place multilayered protections for privileged access so that even if the PAM layer is breached there are still other security controls to stop the attackers’ advance.

Service Accounts: Lack of Monitoring and Protection

• Inability to Vault and Rotate Passwords: As explained before, credentials for service accounts that are hard coded in a script cannot be subject to password rotation and vaulting, since this will likely result in breaking the processes the script performs. However, the result in this case was critical since the exposure of these credentials enabled the attackers direct access to the PAM.

The Silverfort Way: Adaptive MFA, Service Account Protection and PAM Hardening

Silverfort’s Unified Identity Protection platform extends MFA to any user, system, or resource (including those that could never be protected before) and enforces adaptive MFA policies that can efficiently respond to detected risks. In addition, Silverfort places a virtual fence across service accounts to prevent misuse by threat actors.

In tandem with a PAM solution, Silverfort can prevent Uber-like breaches via the following capabilities:

• MFA Bombing Mitigation: Silverfort policies can be configured to suppress the sending of MFA prompts to the user after a sequence of denied access attempts. While the access attempts are logged and visible in Silverfort console for the security team to investigate, the actual user doesn’t see them and thus won’t be tempted to allow access. Read more on Silverfort’s MFA bombing mitigation in this blog.
• MFA Protection for Network Shares: Silverfort can apply MFA protection on network share access. This is achieved by Silverfort’s integration with Active Directory, which allows every access attempt to be analyzed, regardless of authentication protocol or service used. This adds another layer of protection and prevents attackers from accessing such folders even when they have compromised credentials in hand.
• Dedicated Service Account Protection: Silverfort automates the discovery, activity monitoring, risk analysis, and access policy creation for all service accounts within the environment. This means that any deviation of the service account from its standard activity can trigger a policy that would block its access to the targeted resource.
• MFA Protection for PAM Access: Silverfort can enforce an MFA policy on the access to the PAM console itself, safeguarding it from malicious access like the one in the Uber breach.
• MFA or Block Access for Privileged Accounts That Access from a Non-PAM Source: Silverfort can enforce a policy that would either require MFA or block access altogether from any privileged account (i.e., the ones stored in the PAM vault) that attempts to access resource from any source other than the PAM machine itself. Such a policy is a direct mitigation against scenarios where PAM content has been maliciously extracted by attackers who then attempt to use these newly compromised privileged credentials to access sensitive resources.

The following diagram shows the flow of the attack and the various stages where Silverfort would have prevented it:

Conclusion

The realistic assumption security stakeholders must make is that credentials eventually will get compromised. Considering that, the ultimate benchmark to measure the identity protection part in the enterprise security stack is how resilient it is to such a scenario. As we’ve established in this article, traditional MFA solutions and standalone PAM deployment fail to provide the level of protection enterprises need today.  

Silverfort’s Unified Identity Protection platform is the first solution to introduce a holistic solution that combines adaptive MFA, automated service account protection and PAM hardening that can confront today’s identity threat landscape. Click here to learn more.