The Third-Party Security Gap: A Look at Uber
Uber Technologies, Inc. (Uber) develops and operates technology applications and is mostly recognized for its mobility segment that connect consumers with mobility drivers who provide rides in a variety of vehicles, such as cars, auto rickshaws, motorbikes, minibuses, or taxis. Uber’s current market cap is $60.33B so it gains attention when such a company is victim to a data breach or ransomware attack.
News spread rapidly when it was announced Uber has the become the victim a data breach by a relatively speaking “new” cyber threat actor, the LAPSUS$ Group. LAPSUS$ became famous in March of 2022 when Microsoft and Okta both announced data breaches by the group. Okta was a particularly worrisome event as they are a third-party digital identity management provider used by many important corporations and government offices.
What makes LAPSUS$ interesting is that although they have extorted ransoms from some victims in two particular regions, what really makes them stand out is that in these “bigger” breaches, they only published that they were successful but didn’t demand a ransom. What’s more interesting is their tactics and methods. They present a common concern that is often overlooked due to high levels of effort around phishing attacks and DDoS attacks.
Social engineering is the preferred attack vector
In a day and age when phishing email dominates the cyber attack landscape as a preferred method for initial access, LAPSUS$ chooses a different approach. Instead of elaborate schemes to set up Cobalt Strike or similar beacons and C2 infrastructure, LAPSUS$ creatively finds ways to social engineer and trick victims into granting them access into victim networks.
This includes such tactics as simply bribing corporate users with promises of as much as $20,000 for valid credentials. At one point and maybe still, analysts say this is how they gained access to a third party service provider contracted to Okta, the ID management service used by Microsoft, other large organizations and some US government entities.
Generally speaking, social engineering is about tricking victims into believing attackers are legitimate personas who have a need for legitimate, credentialed access to corporate IT resources. This may include calling users based on available phone numbers from a company’s website and impersonating corporate system administrators. The attacker then convinces the victim to give up their credentials so they can “help” them or “solve” an issue with the victim’s account (although there is no real problem). Once the attacker has the credentials, they continue the mission of accessing the network, now impersonating the actual legitimate victim user.
However, there should be something detectable in this scenario: Suddenly the victim is logging in from an usual IP and this should be noticed. If not by system or network admins, then by SIEM and EDR/XDR detection solutions.
How LAPSUS$ made their way in
One of the key pillars of a Zero Trust network is multi-factor authentication for users to gain access in the first place. But what happens when hackers learn how to exploit that as well? (this is exactly why we created Shield Endpoint) Such is the case with an MFA Fatigue attack where threat actors (who gain or buy credentials from those who steal them), push out repeated MFA notifications, and then contact the target through multiple means convincing them they are IT support and that they (the victim) should accept the MFA prompt.
By saying “repeated notifications” we mean enough (quantity) notifications in a time span to fatigue the victim into complying. Experts say this is a tactic LAPSUS$ used in bigger hacks against larger corporations like Microsoft and most recently Uber.
Again, they didn’t attack Microsoft or Uber directly, but instead went after one of their third-party suppliers, which then provided LAPSUS$ limited access to corporate and customer data. The idea of combining or using the MFA Fatigue technique in a Social Engineering vector is so far very effective. The idea of researching and identifying large corporations’ smaller partners & suppliers and using them as initial access towards the larger target is pretty novel.
It’s much like a supply chain attack where service is the thing being supplied. You could parallel the idea of attacking Microsoft via Okta with targeting Solar Winds customers via their Solar Winds Orion product. But still, there are things to watch out for indicating this activity is occurring to and on your enterprise.
A few indicators to watch for…
Unusual general behavior. Assuming a simple posture that most employees are eight hour, Monday-Friday, dayshift, onsite employees, it should stand out immediately when there is a logon from outside the domain during off hours. But we all know that is no longer the norm since the pandemic, especially in regards to remote work. Not only does this eliminate the assumption that employees are within a certain geographic area, but they’re also all using different internet service providers for their internet access. So now you’d have successful logons from many domains outside your enterprise. Of course there are still many what ifs.
Unusual user-specific behavior. Let’s say an employee works in the Finance Department and for the last year their account while logged in has only accessed directories and shares local to the finance group. Suddenly, that same account starts accessing and copying files from the R&D Department to a newly created folder in the Finance Group. Again, a simple phone call to the employee asking if this is them or are they starting a new project with R&D would tell you what you need to know. Let’s assume an even more complex but dead give away: The employ has never logged in remotely from outside the corporate domain, or after hours, and has never accessed R&Ds shares, but suddenly they do. We think you understand the red flag this presents.
Time. Undoubtedly there is always someone working after hours on work projects, but that is not the norm. When someone who has never logged on after hours begins do so, just one phone call to that employee could help solve, avert, or alarm you to a potential crisis.
The common thread in compromise indicators
Whether it’s LAPSUS$ using remote access via successful social engineering operations, or Conti setting up a Cobalt Strike beacon-C2 architecture on your enterprise, they’re not doing it from inside your corporate domain. Whether they’re coming directly at you, or via one of your third-party service providers, at some point their connections to the initial victim machine is recorded in a traffic log somewhere. And by now we should understand that not all connections to the AWS, AZURE, Google or iCloud clouds should be trusted. There is always a connection in the traffic logs that is suspicious and should not have been allowed to connect.
You need a tool and threat intelligence that can painlessly detect these connections in your inbound/outbound traffic and make decisions to block these malicious connections. We can show you how.