Attack scenario:
Could a trusted helpdesk process enable a ransomware attack?

Don’t just track threats. Test them.

Security leaders have no shortage of threat intelligence. The harder part is knowing what to do with it. How do you know whether your organization could actually withstand the attacks you’re reading about? We’ve created three practical attack scenarios modeled on current attack techniques observed in the wild. Use them to challenge assumptions, validate controls, and test how your organization would respond if the attack happened tomorrow.

Scenario: Scattered Spider ransomware operation combining helpdesk vishing, VMware vCenter exploitation for large-scale disruption

Scattered Spider – also tracked as UNC3944, Oktapus, Octo Tempest, and Storm-0875 among others – is a financially motivated cybercriminal collective that remained active and highly effective in 2025. Unlike many ransomware operators that rely primarily on exploit chains or malware delivery, the group focuses heavily on social engineering and credential compromise to obtain initial access to enterprise environments. Their operations have targeted sectors including telecommunications, retail, aviation, and financial services, often resulting in large-scale data theft or ransomware deployment.

A defining characteristic of Scattered Spider operations is the systematic abuse of human trust within enterprise identity workflows. Combined with native-level proficiency in English, as well as an understanding of the ways of working of global enterprises in the western world, their operations frequently succeed in obtaining initial access through voice-based phishing (vishing) attacks against support desks through impersonation of legitimate employees.

By convincingly interacting with IT helpdesks, operators manipulate staff into resetting passwords, enrolling new MFA devices, or granting account recovery access. These identity-focused techniques allow the group to bypass many traditional security controls while maintaining a low malware footprint and leveraging legitimate administrative tools already present within the environment.

Following successful identity compromise, Scattered Spider typically escalates privileges and pivots across identity providers, cloud services, and on-premises infrastructure to achieve broad administrative access. Recent campaigns demonstrate a shift toward infrastructure-level compromise, particularly targeting virtualization management platforms such as VMware vCenter within vSphere environments.

By gaining control of centralized virtualization management, the attack can pivot onto the ESXi hypervisors, providing below-OS-level access to critical systems such as Active Directory domain controllers as well as business-critical production workloads. It is through this access – traditionally unmonitored by sophisticated security solutions such as EDR – that credential databases can be skimmed and exfiltrated, and disks encrypted, in what is known as a double-extortion attack.

Indicative high-level scenario

Following the escalation of Scattered Spider’s disruptive operations in 2025 attracting industry attention, Reversec was engaged for numerous exercises of different formats. These exercises all had in common a motivation to proactively assess resilience driven by Scattered Spider’s campaigns, and an intelligence-led approach for the selection of simulated TTPs against applicable attack surfaces.
Two of these exercises present particularly insightful examples:

• A detection-focused Purple Team against the VMware vSphere estate of a global bank.
• A social engineering exercise against the helpdesk of a global financial services provider.

By combining the activities carried out in these two instances, an indicative scenario can be formed for simulating a realistic Scattered Spider campaign end-to-end. The details of such a scenario are laid out below, with TTPs involved organized across several different phases.
Organizations seeking to reproduce this plan end-to-end are advised to design “leg-ups” or pre-agreed provisions that could be used by the red team to progress along each stage, should no viable attack path be found.

Phase 1: Vishing for initial access

In this first stage, Scattered Spider’s helpdesk campaigns can be simulated through a series of social engineering calls against the service/support desk phone numbers advertised publicly, with the aim of getting access as a legitimate employee through a password and/or MFA reset.
Various pretexts can be explored by operators such as:

• New hires calling to get onboarded.
• Users without a cloud workspace calling to be assigned one.
• Contractors from known service suppliers or vendors.
• Device loss or theft combined with distress conditions.

Reversec advises that caller ID spoofing techniques are employed as well, to improve perceived legitimacy prior to the conversation even commencing, while simultaneously testing for potential procedure weaknesses due to trust on spoofable indicators such as calling number.

Phase 2: Identity privilege escalation and pivot to vCenter management interface

If a foothold is achieved, or a leg-up is used to provide initial access, the privilege escalation stage of Scattered Spider’s operations can be simulated through internal activities. The group seeks elevation of privileges as a means to pivot to the virtualised infrastructure control plane, which is typically integrated with identity platforms such as Active Directory. Red teams could perform a subset of common Active Directory attacks or credential hunting activities that align with threat intelligence from documented incidents.

Once administrative access is achieved, manipulation of the relevant security groups would follow (T1098.007), granting Single Sign-On (SSO) access to the web-based VMware vCenter control plane. Alternatively, if a user with such access is successfully compromised (or assumed compromised), irregular logins and UI activities like the following could stress any behavioral detections present:

• Creation of rogue users, adding them to groups, and modification of user privileges (T1136.001, T1098.007).
• VM-related operations such as creating rogue VMs, taking memory dumps, and disk snapshots (T1005).
• Cloning, copying, and hijacking disk images (VMDKs) that could allow subsequent credential extraction (T1552).
• Attempts to compromise VM guests via boot-order manipulation, backdoored ISO media (T1542), reconfiguration of virtual network interfaces (vNICs), and launching of console sessions.
• Data exfiltration techniques involving copy/paste utilities and VMDK downloads from the UI.
• Obtaining shell access to the vCenter appliance through an SSH session (T1021.004).
• And finally, disabling or modifying Lockdown Mode controls for ESXi hosts to facilitate progression to the next stage (T1562).

Phase 3: ESXi execution and persistence

The next phase of the scenario models Scattered Spider’s final attack positioning step: lateral movement to the hypervisor environment through SSH access to the ESXi shell (T1021.004) or web access to the ESXi Host Client UI.

Indicative actions for this phase could be executed using three different means:

• Python execution – Through the native Python interpreter present on ESXi hosts (T1059.006).
• Pre-compiled binaries (C/C++) – Statically compiled binaries for the target architecture, could be used to interface with system APIs allowing custom code to be executed (T1106).
• “Living Off The Land” utilities – Finally, the native utilities already present on the ESXi shell could be used (T1059.012).

These execution methods would allow simulation of the following TTPs. It is noted that these do not strictly adhere to Scattered Spider intelligence, but incorporate techniques observed by other threat actors such as UNC5221³⁶, UNC3886^37, LockBit³⁸, and FireAnt³⁹:

• Downloading (T1105) and running pre-compiled binaries to establish a network tunnel or achieve command and control (C2) (T1572).
• Disabling system security controls such as “execInstalledOnly” and creating rogue VMs outside standard processes to operate unmonitored (T1562).
• Backdooring “rc.local” scripts to execute on boot, achieving persistence (T1037.004).

Suspending VMs on the host in preparation for ransomware deployment (T1489).

Phase 4: NTDS exfiltration and VM encryption

The final phase of the scenario would involve simulation of actions on objectives through the ESXi shell.

• Exfiltration of Active Directory database data (NTDS.dit) from domain controller VMs (T1003.003, T1041).
• Exfiltration of VM snapshots and disk images containing sensitive enterprise data (T1005).
• Mass encryption of VMDK files to render hosted virtual machines unavailable (T1486).

Could attackers move from your helpdesk to your most critical infrastructure? There’s one way to find out.