Social Engineering Exposed (1/3): How attackers get in without breaking anything
MGM lost $100M. Odido lost 6.2M records. Uber's systems went dark. None required a technical exploit. Just a phone call. Here's how it works.
In September 2023, a hacker called MGM Resorts’ IT helpdesk, spent ten minutes on the phone pretending to be an employee, and walked away with access to MGM’s entire identity platform. The casinos went dark. ATMs stopped working. Hotel room keys stopped unlocking doors. The total damage: $100 million.
No zero-day exploit. No sophisticated malware. Just a LinkedIn search and a phone call.
The same pattern played out at Odido in 2026 and at Uber in 2022. Three different organisations, three different attack groups, the same result: access gained through a person, not through software. This is part one of three. It covers how these attacks actually work.
How did a ten-minute phone call cost MGM $100 million?
Scattered Spider, the group behind the MGM breach, didn’t start with code. They started with LinkedIn. Before making the call, they identified a real MGM employee who worked in IT support, by browsing public profiles. That gave them a name, a job title, and enough personal detail to sound convincing.
On September 11, 2023, someone from the group called MGM’s IT helpdesk and asked for a password reset on behalf of that employee. The call lasted roughly ten minutes. The helpdesk verified the request and reset the password.
With valid credentials, the attackers accessed MGM’s Okta environment, the identity platform used to manage logins across the organisation. From there they moved into Azure. Within hours, systems across MGM’s Las Vegas properties started failing. Slot machines went offline. ATMs stopped dispensing cash. Hotel guests couldn’t unlock their rooms with digital key cards. The disruption lasted ten days.
MGM didn’t pay the ransom. The attack still cost an estimated $100 million in total disruption costs. In January 2025, MGM reached a $45 million settlement with breach victims.
What made this work: The attacker didn’t need to know anything secret. They needed to sound like someone the helpdesk would help. LinkedIn made that easy. The helpdesk’s job is to be helpful. That’s exactly what attackers count on.
The breach wasn’t a failure of technology. It was a failure of verification. MGM’s helpdesk had no process robust enough to confirm that the person on the phone was who they said they were.
How did Odido’s 6.2 million records get stolen with a phone call?
In February 2026, Dutch telecom operator Odido became the subject of the largest known telecom breach in Dutch history. The attackers took a different approach to MGM, but the result was the same: access gained through a person, not through software.
The attack began with phishing. Attackers sent emails to customer service employees that led to fake login pages. At least one employee entered their credentials. The attacker now had a valid username and password, but not the MFA approval required to log in.
So they called.
Posing as someone from Odido’s IT department, the attacker reached the employee by phone and explained that a security check was in progress. They asked the employee to approve the MFA notification that had just appeared on their phone. The employee did.
The attacker was in. They accessed Odido’s Salesforce environment and used automated scraping to pull 6.2 million customer records: names, addresses, bank account numbers, passport numbers. Data from customers going back nearly a decade, far longer than Odido’s own data retention policies allowed.
This technique is called vishing: voice phishing. Unlike MFA fatigue, where attackers spam push notifications hoping for an accidental approval, vishing targets a specific person at a specific moment with a specific lie. The employee wasn’t careless. They were deceived.
The Odido breach also exposed a second failure: data minimisation. One customer service account had access to records for millions of customers. Even if the vishing had failed, that access scope should never have existed. Social engineering found the door. Excessive permissions made the damage catastrophic.
What brought Uber’s internal systems down?
The Uber breach in September 2022 followed a slightly different pattern, but the same underlying principle. An external contractor, not a full employee, was the entry point.
Lapsus$, the group responsible, obtained the contractor’s credentials, likely through a combination of phishing and purchasing stolen passwords from criminal markets. With valid credentials in hand, they needed to get past MFA.
Their approach: send push notifications. Continuously. For a prolonged period.
This is MFA fatigue, also called MFA bombing. The contractor’s phone kept prompting: approve or deny. Approve or deny. After a prolonged stream of these, the attacker moved to WhatsApp. They messaged the contractor directly, claiming to be from Uber’s IT team, and said the notifications would stop once the contractor approved one.
The contractor approved. The attacker registered their device, gained access to the intranet, and started scanning the network. In a shared drive, they found a PowerShell script containing hardcoded admin credentials for multiple internal systems, including AWS, Duo, and OneLogin. Within hours, they had access to most of Uber’s internal infrastructure.
The breach became public when the attacker posted a message to Uber’s company-wide Slack channel.
Is MFA fatigue still relevant? Microsoft made number matching mandatory in Microsoft Authenticator in May 2023. Number matching requires the user to type a two-digit number shown on their screen. A blind “approve” tap is no longer possible. Pure MFA bombing is therefore much harder against Microsoft Authenticator users today. The Uber breach predates this change. That said, attackers have adapted: they now call the victim during the bombing and ask “what number do you see on your screen?” That is vishing layered on top of MFA fatigue. Organisations using SMS, TOTP apps, or legacy push without number matching remain fully exposed to the original technique.
The combination is the attack: Credential theft plus MFA bombing plus social engineering over WhatsApp. No single technique is the attack. It’s the sequence. Remove any one step and the breach doesn’t happen. That’s important for understanding how defences should work.
What do MGM, Odido, and Uber have in common?
MGM, Odido, Uber. Three different organisations, three different industries, three different attack groups. But the same four-step pattern:
Step 1: Find a valid identity. LinkedIn, phishing, credential markets. The attacker doesn’t create access. They borrow it from someone who already has it.
Step 2: Hit the MFA wall. Standard logins now require a second factor. That’s where the social engineering happens.
Step 3: Manipulate a person into crossing the wall. A helpdesk call, a phone call to an employee, a WhatsApp message. The method varies. The goal is the same: get a human to approve what the attacker can’t.
Step 4: Move and extract. Once inside, the attacker moves laterally, looking for admin credentials, high-privilege accounts, and sensitive data. Overly broad access rights make this faster and more damaging.
The common thread isn’t a software flaw. It’s the gap between how authentication systems work and how people behave under social pressure. MFA blocks automated credential attacks. It doesn’t block a convincing phone call.
That’s not a criticism of the people who were deceived. The MGM helpdesk employee, the Odido customer service representative, the Uber contractor: all of them were doing their job. The attackers studied how to exploit exactly that.
What does this mean for your organisation?
These three breaches show that the entry point in modern attacks is increasingly human, not technical. The attackers researched their targets, chose the right moment, and asked the right person for the right thing. That’s not a bug in your software. It’s a feature of how people work.
In part two of this series, we’ll look at why the standard defences (awareness training, MFA, security policies) aren’t enough on their own, and what gaps attackers consistently find even in organisations that think they’re covered.