How Scattered Spider Moves Through Your Infrastructure

It started with a phone call

Scattered Spider does not start with malware. They start with a conversation.

In this incident, the attacker called the IT helpdesk and impersonated an employee. They had the employee's name, email address, and enough context to pass basic identity verification. They claimed to be locked out of their account. The helpdesk reset the password.

That single phone call gave the attacker valid credentials to an enterprise identity provider. No phishing email. No malicious attachment. No exploit. Just a convincing voice on the phone and a helpdesk following standard procedure.

Within hours, the attacker was inside the network. Within days, they had accessed cloud infrastructure, virtualization platforms, security tools, and email. The investigation, led by a major incident response firm, would eventually catalog 9 days of activity across dozens of systems.

Day 1: credential access and reconnaissance

With the reset password, the attacker signed into the corporate identity provider. No MFA challenge was triggered. They immediately began mapping what the compromised account could reach.

The first target was the cloud. The attacker used the compromised credentials to access the AWS console through the organization's SSO portal. They accessed seven separate AWS accounts using a PowerUserAccess IAM role. None of the accounts required MFA for console access.

Across all seven accounts, the attacker ran enumeration API calls: Get, List, and Describe operations to map every resource, service, and configuration. They were building an inventory of the entire cloud environment.

The same day, they accessed SharePoint and downloaded files. Among them: a file containing stored passwords and a spreadsheet of shared credentials. These files were sitting in shared document libraries, accessible to any authenticated user.

They also deleted verification emails from the identity provider to cover their tracks. Two emails with the subject "One-time verification code" were removed from a compromised mailbox within seconds of arriving.

Days 2-6: vCenter, rootkits, and RMM tools

Using the credentials harvested from SharePoint, the attacker pivoted to the virtualization infrastructure. They accessed vCenter and began creating virtual machines under their control.

On the vCenter server itself, the investigation found:

• A bdvl rootkitinstalled on the hypervisor management server. This rootkit hides files, processes, and network connections from standard system tools. Once installed, the attacker's presence becomes invisible to administrators.
• Three separate RMM tools deployed: Teleport (with a custom workspace endpoint), Level.io, and ngrok. Each tool provides a different remote access channel. If one is discovered and removed, the other two remain.
• Local password dumping for all accounts on the vCenter server.

The attacker also created two new virtual machines within the vSphere environment. One was renamed to look like an existing domain controller. This gave them a machine they fully controlled that appeared legitimate in the VM inventory.

From the rogue VMs, the attacker browsed the organization's vSphere environment, searching for domain controllers, SCCM servers, and Commvault backup infrastructure. They were mapping the path to full domain compromise.

Days 7-9: bastion, Mimikatz, and lateral movement

The attacker gained access to a bastion host in the organization's Oracle Cloud Infrastructure. From this single host, over three days, they:

• Ran Mimikatz to dump credentials from memory
• Used ADExplorer to browse the Active Directory structure
• Launched Advanced Port Scanner to map the internal network
• Installed FileZillaand connected to IBM FlashSystem storage arrays (one attempt used the password "Passw0rd")
• Established SSH connections to 11 different internal hosts using privileged accounts
• Accessed Palo Alto firewalls, Cisco Unified Communications, BIG-IP load balancers, and VMware management consoles through the browser

Eleven RDP sessions were recorded on the bastion host from five different IP addresses. The attacker rotated between IPs to avoid correlation. They used both a named administrative account and a "break glass" emergency account, suggesting they had compromised the organization's emergency access credentials.

On the SCCM SQL server, the attacker created a new local administrator account, downloaded another instance of the Level.io RMM agent, and set up a RunOnce persistence key that would survive reboots. They used a Base64-encoded payload to deploy the agent with a hardcoded access token.

The security platform itself

Perhaps the most alarming finding: the attacker accessed the organization's XDR (Extended Detection and Response) security platform.

From inside the platform, they browsed:

• API keys and security settings
• Agent configurations and prevention policies
• Host inventory and asset management
• Incident scoring rules and automation configurations
• Threat intelligence feeds
• Firewall rules and alerting configurations
• SSO settings and user accounts
• Action Center (the interface for running commands on managed hosts)

They also exported the full user list as a TSV file. With access to the security platform's prevention policies, the attacker could see exactly what detections were active and which endpoints were monitored. They could tailor their tools to avoid triggering alerts.

This is the nightmare scenario for any security team: the attacker is watching your dashboards while you are watching theirs.

What Scattered Spider does differently

Most threat actors exploit technical vulnerabilities. Scattered Spider exploits human processes. Their playbook is consistent across incidents:

• Social engineering over technical exploits. They call helpdesks, impersonate employees, and talk their way into password resets. They use SMS phishing (smishing) and SIM swapping to bypass MFA.
• Living off the land. They use legitimate tools (RMM software, built-in admin utilities, cloud consoles) rather than custom malware. Their activity blends with normal IT operations.
• Redundant persistence. Three RMM tools on one server. A rootkit on the hypervisor. A RunOnce key on the SQL server. A rogue VM in vSphere. Every access path has a backup.
• Counter-surveillance.They check security dashboards. They delete verification emails. They rotate IPs. They access "My Signins" to see if anyone is watching. They actively monitor whether the security team has noticed them.

What would have stopped this earlier

The attacker had 9 days inside the network. The investigation required a major incident response firm, hundreds of analyst hours, and a KRBTGT double-tap (resetting the domain-level Kerberos key twice to invalidate all forged tickets).

The earliest detection opportunities were all in the first hours:

• Helpdesk password reset verification.A callback to the employee's known phone number (not the one the caller provided) would have caught the impersonation immediately.
• Sign-in anomaly detection.The first login after the password reset came from an unfamiliar device, unfamiliar IP, and unfamiliar location. Correlating these against the employee's baseline would have flagged it.
• Email configuration monitoring. The attacker deleted verification emails within seconds. A tool monitoring for inbox rule changes or rapid email deletions would have caught this.
• MFA enforcement on cloud consoles. Seven AWS accounts were accessed without MFA via PowerUserAccess roles. Requiring MFA for console access would have blocked the cloud enumeration entirely.
• Credential hygiene. Password files stored in SharePoint gave the attacker everything they needed to pivot. Detecting and removing shared credential files is a basic but critical control.

The takeaway

Scattered Spider is one of the most active threat groups targeting enterprises today. They do not need zero-days or custom malware. They need a phone number for your helpdesk and a convincing story. Once inside, they move fast, deploy redundant persistence, and actively watch whether anyone is investigating them.

The defenses that matter are not the ones that block malware. They are the ones that verify identity, detect anomalous sign-ins, monitor email configuration changes, and enforce MFA everywhere. The first few hours after a password reset are the highest-risk window. If you are not monitoring sign-in behavior and email activity during that window, you are giving Scattered Spider exactly the time they need.