Protecting Against Scattered Spider Attacks in UAE

What Scattered Spider actually is

Scattered Spider is not a single group with a fixed roster. It is a loose, mostly English-speaking network of individuals, some still teenagers when first identified, who specialise in social engineering and then hand the access they gain to ransomware affiliate operations to monetise. Several members have been arrested in the US and UK, and the collective keeps operating because the skill set, not any one person, is what matters. Their 2023 intrusions at MGM Resorts and Caesars Entertainment are the most widely documented examples and are worth reading in the public post-incident reporting, because the sequence there, help desk call, MFA reset, domain admin, hypervisor, ransomware, is close to a template.

What makes them different from a typical ransomware affiliate is patience and fluency. They research a target's org chart, IT vendor relationships, and helpdesk scripts before making contact, and they sound like they belong on the call. That is a harder problem to filter than a phishing email, because the entire point of a help desk is to help people who sound like they need it.

How the initial access actually happens

The most common entry point is a call or chat to the IT help desk, impersonating an employee who needs a password reset or a new MFA device enrolled. The attacker arrives with enough real detail, employee ID, manager's name, recent projects, to pass whatever identity check the help desk normally applies. Most of that detail comes from LinkedIn, corporate directories, data broker sites, and prior breach data, not from anything sophisticated. If the help desk's verification amounts to "can you confirm your date of birth and employee number," it is not verification, it is a shared secret that is already public.

SIM swapping and phishing pages

A second, related technique is SIM swapping: convincing a mobile carrier to port a target's number to a SIM the attacker controls, which defeats SMS-based MFA and any account recovery flow that trusts a phone number. The third is credential phishing through adversary-in-the-middle kits that clone a real single sign-on portal, Okta and Microsoft 365 logins are common templates, and relay the session token in real time, which defeats normal MFA prompts because the victim genuinely completes the login on what looks like the real page.

All three routes share a target: they are not trying to guess a password, they are trying to become a trusted identity inside the identity provider.

Why identity systems are the actual weak point

Once inside, the group goes after the identity plane directly, not file servers. Typical moves include enrolling a new MFA factor on a compromised account so the legitimate reset does not lock them out, searching internal wikis and ticketing systems for VPN and privileged access documentation, and registering OAuth applications that keep working even after the original password is changed. A conditional access policy built around "password plus any MFA push" does not stop this, because the attacker is inside the authentication flow, not guessing at it from outside.

This is also where legacy authentication does real damage. Protocols that predate modern MFA, POP, IMAP, older SMTP auth, legacy Exchange Web Services, are frequently still enabled for compatibility reasons and simply do not ask for a second factor. An identity provider like Microsoft Entra ID can block those protocols and enforce number-matching or certificate-based sign-in, but only if someone has gone through and actually disabled the legacy paths rather than leaving them on by default.

What happens after the foothold

Once they hold a working identity, Scattered Spider tends to move with tools that are already trusted on the network: AnyDesk, ScreenConnect, TeamViewer, and similar remote access software, often installed under the cover of a live support session. Endpoint detection tuned to flag malware has nothing to alert on here, because none of this is malware. It is legitimate software running with legitimate-looking credentials. The one place they do turn to a genuine software vulnerability rather than a person is BYOVD (bring your own vulnerable driver): loading a legitimately signed but exploitable kernel driver to kill EDR processes outright.

The group has also repeatedly gone after VMware vCenter and ESXi directly, using stolen credentials to disable or uninstall endpoint agents at the hypervisor level before deploying ransomware to every virtual machine on the host at once. That single step explains why so many of their incidents look like a full-environment outage within hours of the first sign of compromise: they are not encrypting one server, they are encrypting the hosts underneath dozens of them. Data theft for double extortion usually happens in the same window, before the ransomware payload lands, which is why the exfiltration is often missed until the ransom note references specific stolen files.

Why UAE and GCC organisations are a plausible target

Nothing about this playbook is UAE-specific, but a few regional patterns make the group's approach fit well here. Financial institutions regulated by CBUAE, DIFC firms regulated by the DFSA, and ADGM firms regulated by the FSRA all run help desks and IT operations that are frequently outsourced or shared across a regional group structure, which means the person answering a support call may not personally know the caller and has to rely on documented verification steps, exactly the process Scattered Spider is built to defeat. English-language, service-oriented help desk culture, which the UAE market generally does well, is also precisely the environment their approach was built for. None of that means UAE entities are uniquely exposed; it means the control gaps that let this group succeed elsewhere are not unusual here either.

Controls that actually close these gaps

Awareness training helps at the margins but will not fix a help desk process that trusts caller-supplied information. The changes that matter operationally are structural:

• Redesign help desk identity verification so no credential or MFA reset happens from information the caller supplies over the phone. Call back a number already on file, or require a manager's approval through a separate channel, for any reset touching a privileged or executive account.
• Move away from SMS and voice MFA toward phishing-resistant methods, FIDO2 security keys or platform passkeys, for any account with administrative rights. Number-matching push MFA is a reasonable interim step, not an end state, since prompt bombing still works against plain approve/deny push.
• Disable legacy authentication protocols across the identity provider. This is usually a policy change, not a project, and it closes an entry point that plain MFA does not cover.
• Remove standing administrative access. A help desk account that can reset any user's credentials, including domain admins, turns one social engineering call into a full compromise. Privileged access management with just-in-time elevation and session recording means a compromised support credential cannot reach a hypervisor or domain controller directly, and any attempt to try shows up immediately.
• Inventory and restrict remote access tooling. If AnyDesk or ScreenConnect are legitimate parts of the support workflow, alert on any installation outside the approved list rather than trying to blanket-block a whole category of software your own IT team depends on. This is a detection engineering exercise as much as a policy one, and it is the kind of tuning work vendors like CrowdStrike have published extensively on for this specific actor.
• Segment hypervisor management from the general network and require its own MFA-protected access path, separate from domain credentials, so a compromised Active Directory account cannot walk straight into vCenter.

What a red team engagement against this threat model actually tests

An assessment built around this playbook does not stop at a phishing simulation. It typically includes a vishing exercise against the actual help desk, attempting a credential or MFA reset using only information available from public sources, a review of conditional access and legacy auth settings in the identity provider, and a check of whether help desk or support accounts can reach systems, like the hypervisor layer, that have nothing to do with resetting a password. If a red team engagement cannot get an assessor a live reset attempt against the help desk, it has not actually tested this threat model, it has tested email filtering. Incident response plans should be checked against the same scenario: does the plan name who can isolate an identity provider tenant and who can pull a hypervisor host offline, and has anyone rehearsed it. A documented incident response plan that has never been walked through against an identity compromise scenario is a document, not a capability.

The one control to fix first

If only one thing changes after reading this, make it the help desk reset process. Every other control on this list reduces the odds Scattered Spider gets in or slows them down once they are inside. Fixing how credential and MFA resets are verified removes the step the entire rest of their playbook depends on.