Obsidian recently analyzed an attack carried out by the well-known adversary group Scattered Spider, which has primarily targeted the airlines, retail, and insurance sectors. This post provides a detailed walkthrough of the attack, reconstructed from SaaS audit logs and mapped to the MITRE ATT&CK framework.
Why it matters:
This attack highlights how quickly adversaries can escalate from initial reconnaissance to full administrative access by exploiting identity workflows, helpdesk processes, and SSO-enabled SaaS environments. Understanding these tactics is critical for detecting, responding to, and preventing similar intrusions.
Key considerations while reading:
- How can common workflows, like self-service password resets or helpdesk authentication, be abused to gain access?
- What signals in SaaS activity might indicate lateral movement or privilege escalation?
- How do temporary access methods and disguised service accounts support persistence?
- Which gaps in administrative protections and MFA could allow attackers to maintain control?
- How might attacks unfold in environments with both SaaS and on-premise dependencies?
These questions frame the attack’s mechanics, relevance, and potential impact across different organizational contexts.
Note: Obsidian researchers only had access to SaaS-related logs, reflecting our platform’s focus on SaaS and AI security. However, we were able to make informed inferences about potential on-premise activity by correlating SaaS logs with publicly available breach data and patterns from similar attacks.
Who Is Scattered Spider?
Calling Scattered Spider a “group” is somewhat misleading. It’s more accurate to describe them as a community, composed of individuals, groups, associates, alliances, and insider threats. Techniques and targets are shared within the community, and actors with specialized skills are often recruited on-the-fly for activities such as SIM swapping, helpdesk social engineering, or ransomware deployment.
Hallmarks that help attribute activity to Scattered Spider include rapid attacks across multiple targets within the same industry, helpdesk social engineering and identity-focused exploitation, and a fluid, cooperative structure that accelerates campaigns.
Attack Breakdown
.png)
Before we dive into the attack details, let’s start with an overview of the techniques the threat actor used, mapped to the MITRE ATT&CK framework.
One of the most alarming aspects of this attack—and of SaaS attacks in general—was the speed: after gaining initial access, the threat actor moved from the SaaS environment to the company network in just four minutes.
With that context, we can now examine what happened, step by step:
Reconnaissance
Reconnaissance, as defined in the MITRE ATT&CK framework, is typically not directly observable. However, the attack path philosophy dictates that some form of information gathering must occur. Organizations can still proactively defend against reconnaissance by monitoring malicious sources for leaked data, or the attack surface for evidence of scanning.
Obsidian observed self-service password reset (SSPR) recon activity on the affected accounts from known-malicious IP addresses, a technique Obsidian detailed in a previous blog.
This would indicate some form of victim identity information gathering (T1589), and can be used by an attacker to validate victim information obtained from another source, and confirm if SSPR is a valid attack vector. If an attacker validates that a phone number is indeed used for SSPR, they may be able to reset the account’s password via social engineering or a sim swap (T1451).
Attackers may also gather information such as employee names, email addresses, and job roles, which can be used when impersonating those users during a helpdesk social engineering attack. Similarly, obtaining a victim org’s business relationships (T1591.002) can be used to target 3rd party support providers, such as outsourced helpdesk or a managed service provider.
In the case of this attack, the victim company used a 3rd party helpdesk for IT support. The following table details the likely reconnaissance techniques that were used during this attack.
Initial Access
The attackers gained initial access to the victim company’s Microsoft 365 tenant using two user accounts, Victim A and Victim B. The SSPR recon activity was shortly followed by an administrator replacing the existing phone number on the account with an attacker-controlled Google Voice VOIP number.
Of note is the fact that Victim B’s account was initially accessed ~30 minutes after Victim A. The initial malicious login to Victim B’s account was from within the company network. Other than SSPR recon activity on the account from a known-malicious IP address, all other activity observed on the account was from within the company network.
After the phone number was replaced, the attackers reset the victim account’s passwords [3] and logged into the accounts. While not typically classified under the Initial Access tactic, this is a form of account manipulation (T1098.001).
Other relevant techniques could include trusted relationship (T1199) and spearphishing voice (T1566.004). It depends on how a company wants to classify its outsourced helpdesk, and what can be put in place for detection and prevention.
Execution
Once the attackers gained access to Victims A & B, and later additional accounts, logins to Azure AD PowerShell were observed. SaaS APIs such as AAD PowerShell, Exchange Online PowerShell, and Graph API can be abused by attackers with or without administrative permissions in order to carry out a variety of malicious activity or exploits which could fall under the tactics Discovery, Collection, Privilege Escalation, and more.
Granular audit activity that details how an attacker utilized a given command framework is often not provided, or may be restricted to customers that pay for advanced auditing capabilities.
Lateral Movement
While access into the victim company’s Microsoft 365 environment had successfully been obtained, this was not the adversary's end goal. 4 minutes after resetting the password to Victim A, the attacker was seen logging into a corporate remote access service with Single Sign-On enabled (T1021). SSO allowed the attacker to easily pivot internally, either via remote desktop access or a VPN connection.
Victim B, as mentioned above, was first accessed from an IP address on the company network. Malicious activity on SaaS services that occurs from trusted networks can cause issues for anomaly detection as these networks may be whitelisted to avoid false positives.
Once the attackers had gained access to Victim B, they again pivoted into various SSO-enabled SaaS services within minutes of gaining access (T1021.001). This included movement into SharePoint and a credential management service.
Privilege Escalation
Both Victim A and B were secured within 2 hours of initial access. Ideally, this is when the incident would end. Instead, the attackers were able to hijack another account and continue their activity.
First, we’ll clear up the timeline. Victim A was compromised at 2:32 UTC. It was secured at 4:21. Victim B was first compromised at 3:01, and secured at 3:44. Victim C comes into play at 21:52. Interestingly, the first malicious activity we see is a sign on to a hybrid-joined device, which was later determined to be a jumpbox.
Once Victim C was compromised, the account was used to reset the credentials for an additional account, Victim D.
Victim D was the service account for Azure Active Directory Sync. Victim D was also assigned the administrator roles Privileged Authentication Administrator and Privileged Role Administrator (T1098.003). Victim E, which was a service account without administrative privileges, was also accessed around this time. The account password was not reset, but the Global Administrator role was assigned to it.
Persistence
.png)
Persistence-related activity occurred throughout the incident timeline. Resetting or adding credentials, or adding an additional MFA device, would fall under persistence. Then, as if taking over several administrative accounts wasn't enough, Victim C created another account (T1136.003), Malicious Admin, disguised as a service account. That account was also assigned administrative roles.
Additionally, Malicious Admin registered Temporary Access Passes (TAP) on several accounts of interest.
This activity allowed the threat actors to log into additional victim accounts without requiring the password, and in such a way that bypasses MFA. Threat actors will maintain access to the additional victim accounts until the TAP is revoked.
Even though TAPs were created for several accounts, only two were observed to have any malicious access occur, which was not notable.
Defense Evasion
This incident demonstrated 4 Defense Evasion techniques.
First, Malicious Admin deleted several conditional access policies (T1556.009), including ones that blocked access from specific IP addresses, required MFA for certain circumstances (administrative actions, security info registration), and one that controlled access via the IdP. This action would have been taken in order to allow the attackers to more easily work within compromised accounts.
Second, Malicious Admin was created with a naming scheme that matches other service accounts. This is a form of masquerading (T1036.010), a technique wherein something malicious is disguised as something benign in order to prolong the lifespan of the malicious artifact.
Next, though it does not traditionally fall under the Defense Evasion tactic, Victim C and Malicious Admin disabled 37 accounts and removed various administrative roles from the disabled accounts and other administrative accounts. This activity is intended to prevent or delay response to malicious activity. Mitre ATT&CK classifies this under the Impact tactic.
Finally, impersonation falls under this tactic. Existing defenses (password, MFA) were bypassed when attackers called the help desk directly in order to change authentication information.
Credential Access
Credential access would have primarily occurred from on-premise systems. Using what artifacts are present within SaaS audit logs does give us some insight into how that credential access may have happened. This section is speculation.
The facts:
- The jump box accessed by Victim C was Hybrid-joined with Entra ID
- The sign in event was targeting the application ‘Windows Sign In’
- On the sign in event, the AuthenticationMethod was ‘Password’ and the AuthenticationMethodDetail was ‘Password Hash Sync’
- There is no evidence within SaaS logs that Victim C’s password was ever reset
- Earlier suspicious sign-in records show possible session compromise and MFA bypass
This points to Victim C’s account having been accessed due to capture of the account’s token or password hash, followed by brute-forcing to obtain a plain-text password. Perhaps the attacker was able to obtain Victim C’s on-prem password hash via Kerberoasting (T1558.003) and crack it offline between when Victims A and B were remediated and the initial access from to C happened. Or, they could have installed a keylogger or infostealer on a company computer in order to capture the typed password or extract it from files or the password store. They may have even called helpdesk and requested to know the password, which may have been stored if the account was used by multiple people.
Regardless of the method used to initially access Victim C, this account was the key to the attacker's most destructive activity.
Discovery
Due to the lack of granular audit data, it can not be known for certain what information was discovered during the incident. We can make some assumptions due to the Lateral Movement activity observed, as well as the attackers’ having pivoted into various accounts.
The movement into additional SSO-enabled SaaS services, as observed from Victim A and one of the TAP victims, is evidence of cloud service discovery, either via CLI or a dashboard. (T1526 & T1538). Login to Azure Portal is a sign of dashboard-based discovery.
Additionally, some form of account discovery must have occurred in order for the attackers to take over additional accounts. Victim D was observed logging into Microsoft_AAD_UsersAndTenants, which would allow the threat actor to view a list of accounts within Entra. The Azure Active Directory PowerShell login observed from Victim C would have also allowed the attackers to list accounts within the tenant via CLI.
Collection
We have limited information on any information that may have been collected during the incident. We were able to observe the malicious actors using Victim B’s account to access IT and infrastructure-related documentation within SharePoint (T1213.002). This documentation likely assisted the attackers with their activity within the corporate network.
Attackers also accessed the Teams accounts of Victim A, B, and the two accounts that had the TAP created. Without granular auditing we cannot see what messages were read, but Scattered Spider is known to search messaging applications for information about incident response activity. We cannot say for certain if that activity occurred during this incident.
Command and Control
Based on audit data, as well as post-incident research, we were able to determine some C2 techniques that were likely used in this incident.
When the attacker was not connected to the corporate VPN, access was observed from an IP address registered to Space Exploration Technologies Corporation, also known as SpaceX. The address type was registered as satellite, making it likely that this IP address was part of the Starlink network. This IP address was most likely used as a proxy (T1090.002) in order to disguise the threat actors’ true IP addresses. Additionally, some access was observed from commercial VPN providers Express VPN and Mullvad VPN, for the same purpose.
A significant point of interest for our research was the connection to the jump box PC. A Jump box (aka jump server or jump host) is a device that can be used to access additional devices within a restricted network. A remote admin could access a jumpbox from their home network to administer servers, avoiding the need for their remote computer to be on that specific restricted network.
We could not determine if connection to the jumpbox required VPN usage, but that does not matter considering that the attackers already had VPN access. Historical records on Shodan for the company’s public IP addresses did show evidence that RD Web or other remote access methods existed at some point.
The Bottom Line
This attack required no zero-day exploits or sophisticated malware. Within 24 hours and just two phone calls, attackers had full administrative access, locking out employees and disrupting operations. The simplicity of the attack underscores a critical truth: prevention begins at the helpdesk.
Key takeaways for prevention and response:
- Train employees to recognize social engineering, strengthen verification controls, and regularly test helpdesk processes to reduce the risk of unauthorized access.
- If attackers gain entry, quickly limit users’ access to only the resources they need, secure administrative accounts, and enforce phishing-resistant MFA to minimize damage.
By focusing on the helpdesk, administrative account security, and proactive verification, organizations can significantly reduce dwell time and exposure in SaaS environments.
Want to learn more? Explore Obsidian’s research on advanced SaaS attacks to learn practical strategies for securing helpdesk workflows, managing app permissions, monitoring unusual activity, and revoking sessions to reduce risk and detect threats early.
.avif)
.avif)
