To help organizations to keep track of how identity attacks are evolving, we’ve put together this helpful index of recent breaches. In particular we’re focused on tracking attacks in the public domain that demonstrate the very latest techniques being used in the wild, such as those targeting identity infrastructure itself.
To help organizations to keep track of how identity attacks are evolving, we’ve put together this helpful index of recent breaches. In particular we’re focused on tracking attacks in the public domain that demonstrate the very latest techniques being used in the wild, such as those targeting identity infrastructure itself.
Identity attacks on the rise?
Identity has been recorded as the #1 cyber attack vector since forever. You don’t have to look particularly hard to find statistics to support this. In 2023, one source reports that 4/5 breaches involved identity and compromised credentials, while another suggests that 75% of breaches are caused by mismanaged identity, access, or privileges.
Phishing, social engineering, credential stuffing, and business email compromise have morphed into a homogenous understanding of identity threats that are generally tackled through a combination of email security tooling, content access controls, and user awareness.
The fact that such attacks have been reported as the top security threat for so long probably means that people pay less attention to identity threats. Ransomware grabs the headlines, and rightly so in many cases, but phishing feels like a “known known” that we have a plan for (even if the plan often fails).
In fact, there’s a problem with messaging generally. The 2015 Verizon DBIR contains plenty of stats that still ring largely true today. For example:
In the 2013 DBIR, phishing was associated with over 95% of incidents attributed to state sponsored actors, and for two years running, more than two-thirds of incidents have featured phishing
In 60% of cases, attackers are able to compromise an organization within minutes
Remove the dates and a lot of the report still stands up.
Bad then, worse now
But identity attacks are worse than they used to be. Yes, credential stuffing, phishing, and SIM swapping may not be the most sophisticated attacks, but they remain as effective as ever. As the saying goes, if it ain’t broke — don’t fix it.
Recent attacks have moved toward a broader targeting of the identity infrastructure. While phishing and social engineering was once primarily a delivery mechanism for malicious payloads to be executed on endpoint, it is now used to harvest credentials and secrets for identity-based attacks against cloud apps and services.
And because businesses have migrated to more cloud-based services and infrastructure, the compromise of an identity now has different consequences.
The data and functionality that attackers seek has moved off endpoints and internal networks and onto cloud systems and SaaS applications, which organizations are using in large numbers (tens to hundreds). The modern way of working means that applications are more often than not directly exposed to the internet — and the only thing needed to access these apps are identities. Naturally, it's much harder to stop credential stuffing attacks against 100 SaaS apps than the single centralized external VPN/webmail endpoint of yesteryear.
It’s clear that stats alone don’t adequately capture the identity threat. So we have to look beyond the numbers to find out why.
Using this resource
To cut through some of the noise, we’ve compiled this list of reported attacks and explored what they mean for the identity threat landscape.
This is not intended to be an exhaustive list of all attacks involving the compromise of digital identities (the list would be endless!). Nor is it something you should read all in one go (unless you really want to, we won’t stop you). We want it to be a resource that you can refer back to, that we will continue to update as new attacks are recorded.
In this context we define identity attacks as attacks targeting cloud identities and their associated identity management systems, protocols, applications, and infrastructure.
The attacks recorded below are high profile examples of identity attacks that demonstrate how threat actors are leveraging the cloud identity plane to evade established cyber defenses and traverse new attack paths to achieve their goals. We’ve focused on attacks targeting identity infrastructure itself that are notable for their bypassing of traditional environments and established controls (e.g. Networkless or SaaS-to-SaaS attack paths).
As with all publicly disclosed breaches, the level of detail and transparency we see varies. Where possible, we’ve mapped the threat actor Tactics, Techniques and Procedures to our SaaS Attack Matrix. To learn more about SaaS attack techniques read the blog.
Snowflake – June 2024
The threat group known as ShinyHunters (also tracked as UNC5537) has claimed responsibility for breaching multiple organizations using Snowflake, a cloud-based data warehousing and analytics platform. The breach stems from the historical compromise of credentials used to access customer-specific Snowflake tenants, via infostealer infections. These credentials were used as part of a targeted campaign against Snowflake customers, which was exacerbated by the widespread absence of MFA due to the lack of MFA enforcement by default. At the time of writing, approximately 165 customers have been impacted globally according to a report by Mandiant.
How did Snowflake get breached?
It’s worth noting that customers/users of Snowflake were breached via their Snowflake tenants, and no central breach of Snowflake's own systems occurred.
Snowflake users were infected with infostealer malware that harvested credentials from user devices over an extended period. The threat actor used Snowflake customer credentials that were previously exposed via several infostealer malware variants, including; VIDAR, RISEPRO, REDLINE, RACOON STEALER, LUMMA and METASTEALER.
Credentials appeared on criminal marketplaces e.g. dark web forums and Telegram channels as combolists (username, password, and login portal combinations).
Criminal groups (either ShinyHunters or another organization) saw the potential in targeting Snowflake users, based on the availability of credentials, number of customer organizations, and the value of the data that can be accessed in Snowflake.
ShinyHunters embarked on a large-scale campaign targeting Snowflake customer accounts using previously breached credentials.
ShinyHunters accessed user accounts that lacked MFA, belonging to approximately 165 Snowflake customers.
ShinyHunters used SQL-based reconnaissance, staging, and data exfiltration techniques, expedited by custom hacker tooling developed specifically for Snowflake, to conduct attacks at scale.
ShinyHunters acquired massive quantities of Snowflake data based on the information that each customer stored in Snowflake or connected apps. The most sensitive data declared so far pertains to end-customers of each victim, for example PII, bank account and card information, etc.
ShinyHunters began attempts to extort Snowflake and end-customers using the data acquired.
What was the impact of the Snowflake breach?
Approximately 165 victims were identified by Mandiant. Organizations are gradually coming forward to declare the breach and release customer communications accordingly, but not all victims have been named.
Based on the figures being suggested so far, the impact upon end-customers is huge, with the data of hundreds of millions of people exposed, and has been touted by some news outlets as ‘one of the biggest breaches ever’.
The impact on the affected businesses is largely unknown at this stage. It’s clear that the victims will suffer reputational damage based on the extent of their individual breaches, and possibly face other penalties and sanctions if they are found to be at fault by their respective regulators and/or national information security authorities.
The impact upon individuals will be significant, with high potential for further targeting in terms of identity theft, blackmail, financial crime, etc.
It is unclear what data has been exposed in addition to personal data affecting end-customers. If other sensitive commercial or business data pertaining to Intellectual Property has been exposed then this data may also be sold on via other nefarious channels, with a potential future impact.
Given the lack of MFA for the compromised accounts, there has been a general criticism of the ‘opt-in’ nature of MFA for SaaS services, with many security professionals suggesting that Snowflake should enforce MFA by default given the critical nature of the service.
What stands out in the Snowflake breach?
The breach was achieved by using stolen credentials dating back as far as 2020, that had not been rotated or changed. This indicates that many of the credentials used were not necessarily the result of any recent data sharing. This highlights the potential risk of breached credentials already in the public domain; particularly in the case of cloud services that may not be subject to the same levels of credential hygiene as other traditional network logins.
Much of the industry response has focused on ensuring that accounts are using SSO (and therefore are protected by MFA at the IdP level). However, due to the existence of ghost logins, local logins without MFA can exist simultaneously with the SSO login unless expressly disabled. Organizations using Snowflake that are looking to lock down their accounts can watch our recent demo of how to effectively remediate this vulnerability in Snowflake.
80% of the credentials were gathered through infostealer malware. Typically, this occurs when unmanaged devices are used to access company resources, or personal browser profiles are synchronized on both work and personal devices. Malware deployed to an insecure personal device can then access and steal credentials for company resources. This situation usually occurs when working with third-party contractors on a BYOD basis; a recent article indicates that Ukraine-based EPAM Systems, an engineering and digital service provider and “Elite Tier Partner” of Snowflake, was one such organization breached in this way. Organizations consuming Snowlake-related services from EPAM were then subsequently affected, as the compromise of EPAM users granted access to a large number of Snowflake credentials for various company tenants.
While attacker activity has focused on Snowflake to date, the success of this attack will signal the potential for further credential based attacks against similar apps. There may already be a 'Snowflake 2.0' among the credentials already available online. Further, credentials can be used against a wide range of apps to capitalize on potential password reuse (which we see for 1 in 3 employees), so the exact creds for a particular app don’t have to be explicitly breached, so long as the domain for the login portal can be guessed or has been exposed elsewhere.
SaaS attack matrix mapping
For more information on each TTP please navigate to the GitHub entries linked in the table below.
ID | Name | Stage | Description |
|---|---|---|---|
Initial Access; Persistence; Defense Evasion | Abusing non-SSO additional login methods such as password-based authentication (local to the SaaS app), social logins, API access, etc. | ||
Lateral Movement; Defense Evasion | Session cookies are used to pivot from an endpoint compromise and laterally move to downstream SaaS applications. |
Related breaches
Named victims are listed below:
Ticketmaster
Santander
Neiman Marcus
Cyclance
Los Angeles Unified
Pure Storage
Advance Auto Parts
Triust Bank
Lending Tree
Microsoft — January 2024
The threat group known as APT29 (also known as “The Dukes”, “Cozy Bear”, and labeled “Midnight Blizzard” by Microsoft) executed a cleverly executed password-guessing attack to compromise test cloud identities that were also lacking MFA. Attackers then leveraged this access to compromise some OAuth applications that allowed lateral movement to Microsoft’s corporate environment and the creation of other malicious OAuth applications to achieve persistence.
How did Microsoft get breached?
APT29 utilized password spraying / credential stuffing attacks to compromise test cloud identities that were also lacking MFA, attached to a non-production test tenant.
APT29 leveraged their initial access to the test tenant to identify and compromise a test OAuth application that had access to the Microsoft corporate environment by leveraging permissive Entra ID roles in the test tenant.
APT29 used the existing configurations to access the Microsoft corporate Entra ID tenant whereupon the app registration from the test tenant was installed as a service principal in the corporate tenant, granting the equivalent of global admin rights.
Using these new permissions, APT29 registered additional malicious OAuth applications in the Microsoft corporate environment, and created a new user in the Microsoft corporate tenant to grant consent to the new malicious OAuth apps, thereby achieving persistent access to the environment.
APT29 leveraged the elevated (maximum) privileges assigned to the ‘test’ app service principal to grant app roles to other newly created app service principals, granting them the Office 365 Exchange Online full_access_as_app role in the corporate tenant, which allows access to mailboxes.
APT29 leveraged these malicious OAuth applications to authenticate to Microsoft Exchange Online and target Microsoft corporate email accounts.
What was the impact of the Microsoft breach?
APT29 had access to Microsoft corporate email accounts, including members of the senior leadership team and employees in the cybersecurity, legal, and other functions, resulting in sensitive data leakage.
Microsoft has not disclosed any further impacts at this time, but it is likely that the adversary had complete, unmitigated control of the Microsoft corporate tenant for a period of time, with global administrator level access.
Since the initial attack there has been evidence of continued targeting, with password spraying attacks reportedly increasing tenfold, likely informed by stolen information.
What stands out in the Microsoft breach?
The attack was covert and targeted, with APT29 tailoring the attack to a limited number of accounts and using a low number of attempts to evade detection and avoid account blocks based on the volume of failures.
APT29 used residential proxy networks when interacting with the compromised tenant and, subsequently, with Exchange Online to obfuscate the source of their attack and avoid impossible travel detections.
APT29 demonstrated mature and in-depth understanding of cloud infrastructure, protocols, and workflows, particularly in terms of privilege escalation and lateral movement.
If even Microsoft (an organization with pretty much unrivaled security resources) can’t ensure that all their accounts are protected by MFA and that there are no weak links between test/dev and prod systems, this should be a wake-up call for any company that thinks their MFA implementation is flawless.
SaaS Attack Matrix mapping
For more information on each TTP please navigate to the GitHub entries linked in the table below.
ID | Technique | Stage | Description |
|---|---|---|---|
Initial Access | Attempt to authenticate to a SaaS account by guessing a large number of passwords | ||
Execution; Persistence; Defense Evasion | Use a malicious OAuth app to create an OAuth token, using arbitrary permissions to maintain long-term programmatic access to a compromised user account. | ||
Privilege Escalation; Lateral Movement | If an adversary compromises a SaaS account integrated with other apps, they can escalate privileges and move laterally to other apps. |
Related breaches
Hewlett Packard Enterprise (HPE) — May 2023
At the time of the Microsoft breach becoming public knowledge, HPE disclosed that they had become aware of a historical incident in Dec 2023, involving unauthorized access to and exfiltration of a limited number of SharePoint files as early as May 2023. Hackers accessed and exfiltrated data from HPE mailboxes belonging to individuals in the cybersecurity, go-to-market, business segments, and other functions. No further information is available on the techniques used or impact of the breach.
Okta — October 2023
An unknown threat group compromised an Okta employee's personal Google account that was being used on a company-managed device, granting the threat actor access to a service account for Okta’s customer support system, that included session tokens for 134 customers. This was then used to hijack the legitimate Okta sessions of five customers.
How did Okta get breached?
The threat actor compromised a personal Google account that the user had accessed from their Okta-managed work device by signing into their personal profile from the Chrome browser.
The personal account credentials are likely to have been compromised in a historical data breach and did not have MFA enabled.
The username and password of a service account for Okta’s customer support system had been saved into the employee’s personal Google account and was therefore compromised.
The threat actor was able to access the service account by logging in using the stolen credentials, which again likely did not have MFA deployed as a service account.
The threat actor was able to use session tokens in the HAR files to impersonate staff and hijack the legitimate Okta sessions of five customers, including 1Password, BeyondTrust, and Cloudflare.
What was the impact of the Okta breach?
The threat actor gained unauthorized access to files inside Okta’s customer support system associated with 134 Okta customers.
The threat actor was able to use these session tokens to hijack the legitimate Okta sessions of 5 (publicly disclosed) customers.
Okta originally claimed the breach had impacted only 1% of customers, but later found that a report run and downloaded by the threat actor contained the names and email addresses of all 18,400 Okta customer support users, as well as some Okta employee information, meaning 100% of customer support users were impacted.
Okta users are at higher risk of phishing and credential stuffing attacks based on the data stolen by the threat actor, increasing the importance of robust MFA implementation.
What stands out in the Okta breach?
This attack demonstrates the risk associated with cloud Identity Providers and the potential goldmine that they are to attackers. Much in the same way that the manufacturers of physical and virtual network appliances are continuously probed for software vulnerabilities, cloud IdPs like Okta present a huge potential opportunity, both in terms of targeting specific organizational instances as well as the Okta organization. This attack showcases the possibility of third-party supply chain attacks to target downstream organizations using IdP services.
Similar to the Microsoft breach, gaps were discovered and exploited in Okta’s MFA coverage and implementation, highlighting that there are gaps in even the most mature organizations.
The subsequent attack on Cloudflare (see below) and the scale of the recovery effort demonstrates the significant operational overhead in responding to and recovering from a breach of identity infrastructure, with a similar or greater scale than a traditional Active Directory compromise. While addressing the incident, Cloudflare's staff rotated all production credentials (over 5,000 unique ones), physically segmented test and staging systems, performed forensic triage on 4,893 systems, reimaged and rebooted all systems on the company's global network, including all Atlassian servers (Jira, Confluence, and Bitbucket) and machines accessed by the threat actor. All equipment in Cloudflare's Brazil data center, which was unsuccessfully targeted by the threat actor, was later returned to the manufacturers to ensure that the data center was secure.
SaaS Attack Matrix mapping
For more information on each TTP please navigate to the GitHub entries linked in the table below.
ID | Technique | Stage | Description |
|---|---|---|---|
Initial Access | Attempt to authenticate to a SaaS account by guessing a large number of passwords | ||
Credential Access | Collection of credentials and secrets from repositories e.g. password managers, SaaS file stores, etc. |
Related breaches
Cloudflare — November 2023
The threat actor used tokens and credentials that had not been rotated to breach Cloudflare’s internal Atlassian server and access its Confluence wiki, Jira bug database, and Bitbucket source code management system. The threat actor first gained access to Cloudflare's self-hosted Atlassian server and then accessed the company's Confluence and Jira systems following a reconnaissance stage. Cloudflare says that this breach did not impact customer data or systems or the provision of services.
1Password — October 2023
1Password reported unsolicited activity in their Okta environment which was traced to a suspicious IP address. Later it was confirmed that an threat actor had accessed 1Password’s Okta environment using administrative privileges. They attempted to access the IT team member’s user dashboard, but that attempt was blocked by Okta. They also requested a report of administrative users, which was identified as suspicious and triggered an investigation. 1Password says it terminated the activity, investigated, and found no compromise of user data or other sensitive systems, either employee-facing or user-facing.
BeyondTrust - October 2023
BeyondTrust security teams detected an identity-centric attack on an in-house Okta administrator account. BeyondTrust blocked all access to the threat actor, and verified that they did not gain access to any systems. BeyondTrust has confirmed that there was no additional exposure to our internal systems or BeyondTrust’s customers.
MGM Resorts — September 2023
The threat group known as Scattered Spider socially engineered MGM help desk personnel to grant ‘super admin’ access to the Okta tenant, which was then used to steal data and deploy ransomware, resulting in significant business disruption.
How did MGM get breached?
Scattered Spider researched MGM employees on LinkedIn to identify individuals likely to have privileged Okta access, specifically Super Administrator privileges.
Scattered Spider contacted the IT help desk impersonating an employee with a privileged account asking for an authentication reset (password and MFA).
With privileged access, the compromised Super Administrator accounts were used to assign higher privileges to other accounts, circumventing MFA by removing enrolled authenticators and/or removing MFA from authentication policies.
Scattered Spider registered a second, attacker-controlled IdP via Org2Org using inbound federation, granting the ability to impersonate users and access applications on their behalf. By matching the username of target accounts in the second IdP to the original, the attacker was able to SSO into target applications.
Through inbound federation, Scattered Spider obtained global admin rights in Azure, effectively granting full control over connected systems and granting domain admin privileges in target environments.
Scattered Spider deployed encryption software to around 100 ESXi servers and exfiltrated data, disrupting core business operations.
What was the impact of the MGM breach?
Led to a 36-hour outage of multiple MGM IT systems and affected a number of its casinos on the Las Vegas strip, including the Bellagio, Excalibur, Luxor, Mandalay Bay and New York New York.
Personal data compromise of an unspecified number of customers including various contact information, dates of births, genders, driver’s license numbers, social security numbers, and passport information.
MGM reported that the attack would cause a $100 million hit to its third-quarter results, including $10 million in one-time cyber security consulting fees.
What stands out in the MGM breach?
The MGM breach demonstrates how financially motivated organized criminal groups are specifically targeting the identity infrastructure of an organization (e.g. the chosen IdP solution) and leveraging cloud-native functionality.
The MGM breach is notable for being a hybrid attack that ended in what has become a typical “actions on objective” for ransomware operators and their affiliates - the propagation of malware and encryption of core business servers. In this way attackers are leveraging the newer functionality that cloud services provide them to target non-cloud/on-premise resources. This potentially indicates that attackers see cloud applications and services as the path of least resistance to achieving their goals, exploiting more limited security team visibility and understanding of these services compared to more traditional (now well protected) targets.
While attackers were focused on taking control of the cloud IdP, the initial access vector was notable for being a more traditional method (vishing) to bypass the need to acquire credentials (password and MFA token). This type of technique remains consistently effective, regardless of the technology landscape and whether MFA is correctly implemented or not.
SaaS Attack Matrix mapping
For more information on each TTP please navigate to the GitHub entries linked in the table below.
ID | Technique | Stage | Description |
|---|---|---|---|
Persistence; Lateral Movement | Inbound federation allows users to login to a target identity provider by authenticating with a source identity provider |
Retool — August 2023
Software development company Retool disclosed that the accounts of 27 of its cloud customers were compromised following a targeted SMS-based social engineering attack, which was enabled by Google Authenticator’s default synchronization of MFA tokens with the associated Google account.
How did Retool get breached?
The threat actor launched a targeted SMS-based phishing campaign against Retool employees with a custom lure relating to their workplace healthcare coverage.
The timing coincided with a recently announced migration of logins to Okta, and the message contained a url disguised to look like their internal identity portal.
After logging into the fake portal – which included an MFA form – the threat actor called the employee impersonating an IT team member, deepfaking the IT employee’s real voice and using real information about the company to build trust.
The phished employee shared an MFA OTP token which allowed the threat actor to add their own personal device to the employee’s Okta account and enabled their own Okta MFA from that point forward.
Due to the Google Authenticator synchronization feature that syncs MFA codes to the cloud by default, meaning that access to a Google account immediately gave access to all MFA tokens held within that account.
This enabled the threat actor to take over a number of identities associated with a range of target apps and change the credentials.
What was the impact of the Retool breach?
A total of 27 customers were impacted, with the threat actor specifically targeting customers in the Crypto industry.
After taking over the accounts, the threat actor was observed gathering information and exploring the Retool apps.
After learning of the attack, Retool revoked all internal authenticated sessions (Okta, GSuite, etc.) for employees, locked down access to the affected accounts, notified the affected customers, and restored their accounts to their original state.
What stands out in the Retool breach?
Like the MGM breach, the Retool breach demonstrates how financially motivated organized criminal groups are specifically targeting the identity infrastructure of an organization (e.g. the chosen IdP solution) and leveraging cloud-native functionality.
A further similarity with the MGM breach, while attackers were focused on taking control of the cloud IdP, the initial access vector was notable for being a more traditional method (SMS phishing in this case) to bypass the need to acquire credentials (password and MFA token). This type of technique remains consistently effective, regardless of the technology landscape and whether MFA is correctly implemented or not.
In this case, the attacker abused inherent weaknesses in Google Authenticator, which came under fire following the breach for its default synchronization of MFA codes to the cloud when connected to an account, in order to move laterally and compromise other target apps.
SaaS Attack Matrix mapping
For more information on each TTP please navigate to the GitHub entries linked in the table below.
ID | Technique | Stage | Description |
|---|---|---|---|
Initial Access | Attacker-in-the-Middle (AiTM) phishing uses dedicated tooling to act as a web proxy between the victim and a legitimate login portal for an application the victim has access to, principally to make it easier to defeat MFA protection. | ||
Initial Access; Persistence | Enrollment of a new MFA device in order to allow an adversary to complete MFA challenges for future authentication. |
GitHub / Heroku / Travis-CI / npm — April 2022
An unknown threat actor used stolen OAuth user tokens (issued to Heroku and Travis-CI) to download data from private repositories. The threat actor then compromised an internal Heroku customer database as well as accessed and stole data from dozens of downstream organizations using Heroku and Travis-CI-maintained OAuth apps.
How did they get breached?
The threat actor obtained access to two third-party OAuth integrators, Heroku and Travis-CI, accessing databases and downloading stored customer GitHub integration OAuth tokens. These tokens had earlier been used by Travis-CI and Heroku OAuth applications to integrate with GitHub to deploy applications.
Access to the environment was gained by leveraging a compromised token for a Heroku machine account, but it is not disclosed how the threat actor achieved this.
The threat actor authenticated to the GitHub API using the stolen OAuth tokens issued to Heroku and Travis CI.
For users who had the affected Heroku or Travis CI OAuth apps authorized in their GitHub accounts, the threat actor listed all the user's organizations.
The threat actor then selected targets based on the listed organizations.
The threat actor listed the private repositories for user accounts of interest and proceeded to clone private repositories of interest.
GitHub identified unauthorized access to their npm production infrastructure using a compromised AWS API key, obtained by the threat actor when they downloaded a set of private npm repositories using a stolen OAuth token from one of the two affected third-party OAuth applications.
What was the impact?
By stealing these OAuth tokens, the threat actor could access and download data from GitHub repositories belonging to those who authorized the compromised Heroku or Travis CI OAuth apps with their accounts.
The threat actor was able to mine the downloaded private repositories for secrets that could be used to pivot to other infrastructure, stealing data from dozens of organizations.
In addition to user repo’s downstream, the compromised token for a Heroku machine account obtained by threat actors also allowed unauthorized access into Heroku's internal database of customer accounts, enabling the threat actor to extract the hashed and salted passwords.
What stands out in the Github breach?
Similar to the Okta breach, this attack showcases the possibility of third-party supply chain attacks to target downstream organizations using cloud SaaS services. In this case, targeting OAuth integrators as opposed to IdP providers, but with a similar goal and impact of compromising the real target organizations downstream.
Applications like Github are an obvious target for attackers due to their widespread adoption. There have been numerous attacks leveraging Github as the vehicle for attacks by compromising repo’s to insert malicious code, or registering malicious copycat repo’s to dupe users into using them.
Unlike the attacks abusing the functionality of Github (repo poisoning) which target the legitimate developer processes when using the app, this attack could have been prevented at the identity layer before the attacker was able to breach the Heroku/Travis-CI accounts.
SaaS Attack Matrix mapping
For more information on each TTP please navigate to the GitHub entries linked in the table below.
ID | Technique | Stage | Description |
|---|---|---|---|
Privilege Escalation; Lateral Movement | If an adversary compromises a SaaS account integrated with other apps, they can escalate privileges and move laterally to other apps. | ||
Persistence; Defense Evasion | An adversary that has compromised an account could then read existing API keys from the app settings, if the app allows this, or create a new API key. | ||
Discovery | An adversary who has gained a foothold via a SaaS app could download the list of users accessible to them in order to better target attacks against other users. |
Other notable attacks
SEC X hack — January 2024
The X account for the U.S. Securities and Exchange Commission was victim to a SIM swapping attack, whereupon the attacker used the social media platform to issue a fake announcement on the approval of Bitcoin ETFs on security exchanges.
Once the threat actors controlled the number, they reset the password for the @SECGov account, and created the fake announcement. The SEC also confirmed that multi-factor authentication was not enabled on the account, as they had asked X support to disable it when they encountered problems logging into the account.
Mandiant X hack — January 2024
The X account for Mandiant was hacked by a Drainer-as-a-Service (DaaS) gang in a brute force attack. MFA was not enabled on the account. The threat actor used the social media account to share links redirecting to a phishing page to steal cryptocurrency.
The attacker used a wallet drainer dubbed CLINKSINK. This same drainer has been used since December to steal funds and tokens from users of Solana cryptocurrency as part of a large-scale campaign involving at least 35 affiliate IDs linked to a shared DaaS.
23andMe data breach — April 2023
Genetic testing provider 23andMe confirmed that hackers downloaded the data of 6.9 million people of the existing 14 million customers after breaching around 14,000 user accounts.
The attacker stole health reports and raw genotype data of customers affected by a credential stuffing attack that went unnoticed for five months, from April 29 to September 27.
The credentials used by the attackers to breach the customers' accounts were stolen in other data breaches or used on previously compromised online platforms, and targeted accounts without MFA.
