Uber, Rockstar fall to social engineering attacks; and you?

Security pros often talk of security being a process and a system, not a destination, and the recent news from Uber and Rockstar Games is just another example. Details are still emerging, but we can still analyze these breaches at a high level and apply these lessons to our own information security programs.

Similar to the Lapsus$ attack against Electronic Arts in July of 2021, it appears attackers purchased their stolen credentials from Initial Access Brokers (IABs). IABs usually gather credentials en masse through email phishing attacks and by infecting devices with information-stealing Trojans using various methods. They use the malware to gather any stored passwords, session cookies, and even cryptocurrency wallets they can find on the victim’s PC and put the lot up for sale on the dark web.

In a statement, Uber claimed the attack began when a contractor’s credentials for Uber’s internal network were purchased by Lapsus$ from an IAB. The attackers then proceeded to attempt to use the credentials repeatedly, triggering multiple Duo Security multi-factor push notifications to the contractor’s phone until the targeted contractor finally succumbed to the deluge and accepted one of them — granting the intruders a foothold.

Uber simply says that the intruders elevated their privileges, but in a conversation on Telegram, the intruders claimed to have found a PowerShell script containing an administrative password for Uber’s privileged access management (PAM) tool. This password trove gave them “uber” access to Uber’s corporate network.

This level of access enabled the intruders to run roughshod through the network grabbing screenshots of internal tools, cloud service dashboards, security dashboards, and even gaining access to the security bug bounty program management system.

What sorts of things could one do to try to stop similar attacks from proceeding against their own systems? Let’s look at a few of the specifics that enabled this attack to succeed, to see if the rest of us can’t glean some lessons to improve our own security postures.

Multifactor may not be enough

As organizations continue to adopt multi-factor authentication, attackers are getting better at learning how to bypass it. Uber had deployed Duo, a push notification service from Cisco, to protect their VPN remote access service, which is great. The problem is that criminals have learned that if they repeatedly spam a target with alerts, more often than not the target may just relent and press Accept.

What can be done? Well, in a perfect world we would all be using FIDO2 authentication which requires a hardware token or smartphone that must be physically proximate to the device authenticating.

Not everyone is ready to adopt this technology though, so multi-factor services like Duo also offer a hybrid approach to push, where the application asking you to authenticate gives YOU the 6-digit code and, instead of tapping Accept on your device, you must enter the secret code. This would require the criminal to interact with the victim and convince them to enter the code on their behalf. Not impossible, but a much higher barrier than simply pressing the big, shiny, green button.

Privilege escalation: Slowing their roll (through your network)

Given enough time, there is nearly always a way for an authorized user to gain privileges to an account they shouldn’t have access to. The key to defending against this type of attack is to make it take enough time that you can detect their footprints and evict them before they succeed.

The attacker alleges they found the administrator password for Uber’s Privileged Access Management solution in a PowerShell file on a user-accessible file share. This is clearly not ideal, but it does beg the question: How should that have been sufficient to wreak this much havoc?

Without yet knowing the specifics of Uber’s affected system, most of us would ask why multifactor authentication wasn’t in place. Turning the question around, do you require multifactor authentication to log on to internal systems? For functions as critical as privilege management, source code, HR, or financials you should be applying the same amount of caution you exercise when authenticating users for access to the network itself — and you should never assume that anyone on the network is authorized for access to sensitive systems just because they have authenticated to the network at large.

Just like conducting an external penetration test on a semi-annual basis, it is also a good practice to do an audit of your internal environment for just this type of thing. It might have been a temporary workaround or a legacy practice that had been forgotten, but these things crop up in almost any reasonably complex network.

Once is not enough and there is no “inside”

The idea behind zero-trust network access (ZTNA) is that you should only have access to precisely what you need, when you need it, and I should never trust that you are who you say you are. Authenticate each user’s permissions at time of access to be sure everything is in order, just like you would for an externally facing application.

In fact, one of the benefits of this approach is that you can, in fact, eliminate the perimeter entirely – or at least you can stop relying on VPN-type solutions, paring down the broad-brush protection layers for assets living behind the firewall and WAF. Your assets will, yes, be less swaddled in layers of “protection,” but strongly and carefully verifying that every access request is authenticated and authorized is, in fact, better asset stewardship – and it’s easier to spot trouble when it comes.

Your network should not resemble a candy bar with a hard outer shell and a soft gooey center. As I mentioned to Paul Ducklin in our brief podcast when the Uber news first aired publicly, the best-managed networks have an assumption of breach. Nothing dangerous should be laying around that, when in the hands of someone with malicious intent, could harm you.

Conclusion

I find it a good practice, whenever there are security news headlines, to try to take away some lessons and imagine how my own team might fare when faced with a similar adversary. Successful network defense is hard, but by using these lessons to sharpen your tools, it gets a little easier each time.

The purpose of our layers of defense shouldn’t be with the expectation that one of those layers is going to magically stop a determined attacker; rather, each should be viewed as one more opportunity to buy yourself time.

That time allows the team that is monitoring your systems to take note of the anomaly and start investigating. The goal is to have those layers buy you enough time that you’re able to find the point of entry, close it, and evict the attackers before they reach their goals.

When the attacker’s goal is to plant malware, steal specific intellectual property, or even trigger a ransomware/extortion attack, it usually takes a few days and that should be enough to stop them in their tracks.

Unfortunately, as is the case with Uber, Rockstar and other victims of Lapsus$, the attacker is after anything and everything, simply to make headlines and cause embarrassment to the victims. This takes frighteningly little time on the attacker’s behalf and requires the network and monitoring to be in tip-top shape to prevent.

The pain from these incidents will be temporary, and I hope that in the end we can all benefit by using them to improve our own processes and architectures. Security is an evolving field and the best we can hope for is to work together, learn from our mistakes, and continue raising the bar for criminals.