It seems every week there is a new story about LAPSUS$. Not only is it impressive to see one group – if, indeed, they are one group – to constantly have so many major organizations on the backfoot. We have seen Nvidia, Samsung, Microsoft, Vodafone, Okta, and EA face attacks from the hacking groups, and Uber is just another battle trophy for them.
But unless you want to end up on that list, you will need to prepare against the common tactics used by LAPSUS$! How often have I had to say that? Because we are quickly moving towards a world where hackers are becoming more flexible and resourceful, we need to have our own flexibility and resourcefulness. This includes a greater emphasis on pentesting with common tools and understanding how easy “foot in the door” techniques completely circumvent many of the more developed cybersecurity systems.
LAPSUS$ and Uber – what happened?
In case you missed last week’s secpro or you haven’t kept up with the news, here’s a quick recap:
- A social engineering campaign was run by LAPSUS$ against a member of the Uber development team.
- When credentials were leaked, the attackers quickly turned to Uber’s VPN.
- After gaining access to the sensitive underbelly of the Uber network, LAPSUS% exfiltrated data from internal systems, the email dashboard, the Slack server, security software, the Windows domain, the AWS console, VMware ESXi virtual machiens, and the email administrator Google Workspace dashboard.
- After having downloaded all vulnerability reports from Uber’s bug bounty program, the hackers stole data concerning vulnerabilities in the application, presumably to sell them on.
- LAPSUS$ was kicked off the Uber servers, but not before all that information was already lost and quickly making its way onto dark web seller sites.
A tale as old as time – social engineering to gain access to the backend of a major company! Now that we know the broad strokes of how they gained access, let’s investigate the unique but mundane tools they used this time around.
LAPSUS$ and WhatsApp
Here’s a new one for me – the hacking team has turned to using WhatsApp to dupe unsuspecting victims!
Having attempted to gain access to an Uber contractor’s accounts directly and failing, the LAPSUS$ team turned to tricking the poor worker with WhatsApp. Having changed tack to target the contractor’s WhatsApp number, the LAPSUS$ hackers said that they were IT support and that the contractor should accept the MFA request. That’s when all hell broke loose.
How do I stop that from happening?
Obviously, we find a case where MFA doesn’t actually protect the individual against the sneaky tactics of the adversary. In this case, there are two plans: education! Education! Education! and more robust authentication options such as identity cards or hardware keys. Of course, improved technology is only as intelligent as the person using it, so education has to come first – never accept MFA requests unless you know exactly why you are receiving them and can verify the source of the request.
Exfiltrating the data
As you can imagine, that hack had serious implications for Uber. In the interest of not being prosecuted, Uber released this message on Twitter:
While our investigation and response efforts are ongoing, here is a further update on yesterday’s incident:
- We have no evidence that the incident involved access to sensitive user data (like trip history).
- All of our services including Uber, Uber Eats, Uber Freight, and the Uber Driver app are operational.
- As we shared yesterday, we have notified law enforcement.
- Internal software tools that we took down as a precaution yesterday are coming back online this morning.
The Uber security team sounds like the heroes of the day, as quick thinking shut down the hacking attempt. Obviously, this came after the data had already been exfiltrated, but we’re yet to see any information dumps online as of today.
How did Uber respond to the LAPSUS$ attack?
In an six part response, Uber quickly stopped the hackers from stealing even more information than had already been leaked.
- Identify compromised accounts and block access to Uber assets.
- Disable affected tools.
- Rotate all keys where relevant.
- Lock the codebase and check for any changes.
- Slowly restore access to internal tools with new MFA defenses.
- Engage in on-going monitoring to find any extra attacks.
As you can tell, this is a fairly simplistic roundup of the Uber security team’s response. But it’s key to understand that playbooks for these kinds of attacks – even ones set off by simple social engineering attacks – are so important.
