Attackers are increasingly making use of “networkless” attack techniques targeting cloud apps and identities. Here’s how attackers can (and are) compromising organizations – without ever needing to touch the endpoint or conventional networked systems and services.
Before getting into the details of the attack techniques being used, let’s discuss why these attacks are becoming more prevalent.
SaaS adoption is changing the make-up of company IT
The SaaS revolution and product-led growth have had a huge impact on the structure of company networks, and where core business systems and data reside.
Most organizations today are using tens to hundreds of SaaS applications across business functions. Some are entirely SaaS-native, with no traditional network to speak of, but most have adopted a hybrid model with a mixture of on-premise, cloud, and SaaS services forming the backbone of business applications being used.
The bulk of SaaS adoption is user-driven, as opposed to centrally managed by IT, as bottom-up adoption is inherent to product-led growth. The latest data from Push Security indicates that only 1 in 5 SaaS apps have been sanctioned by the business. The majority is simply unknown and, therefore, has not been reviewed at all.
Cloud and SaaS apps are designed to be interconnected, functioning like the closed networks of internal business applications you might have used in the past. The vehicle for this interconnectedness is identity.
Digital identities are increasingly complicated and hard to secure
The most basic form of identity is a user account created for services you sign up to with a username/email and password. To reduce the risk of account takeover and complexity of managing an ever-increasing number of accounts, organizations are using the services of identity providers (IdPs) to centralize access to apps within a single platform and identity, using protocols like single sign on (SSO) and OAuth to manage authentication and authorization respectively.
The particular make-up of an identity can vary a lot. Depending on the app, it’s possible to have multiple authentication mechanisms for the same account – for example, via SAML, social logins (OIDC), and username and password. Whilst SAML requires that admins set it up in advance for a given app tenant, users can sign up for an app using OIDC simply by using the “sign in with Google” feature.
In effect this creates multiple identities tied to a single account, which can introduce a lot of confusion and complexity – for example, just because an IdP admin deletes that account, doesn’t mean the app/account can’t then be accessed by using one of the other login methods that’s been created. This can make it hard to know what apps are in use, and what identities exist in the organization.
So, in practice, it’s possible to end up with a combination of the following:
- Identity providers (typically 3 per organization on average) (e.g., Okta, Entra/Microsoft, Google)
- Apps acting as an SSO platform for connected apps (e.g., Atlassian Access, Adobe Creative Cloud)
- SaaS apps using different authentication (SAML, OIDC) and authorization (OAuth) protocols
- SaaS apps with a local username and password
- Credentials and secrets stored in password manager and authenticator apps (which can be in browsers, on local OS, and in 3rd party apps)
It can get pretty complicated – with most organizations having 100+ apps in their inventory, resulting in thousands of sprawled identities.
Then, depending on the OAuth scopes approved for a given app, permissions and workflows in one app can impact other apps where approval is granted for them to talk to one another.
Identity is the glue that holds this ecosystem together. However, the controls that exist to secure identity have serious limitations. Companies often think that all their apps and identities have MFA rolled out or all apps are behind SSO. But the reality is that only 1/3 of apps actually support SSO (and many of these only at the premium tier, with a hefty price increase). Further, around 60% of unique identities (i.e., not using SSO) do not have MFA registered.
So in reality, there are significant gaps in the security controls protecting cloud identities, while identities and cloud apps are becoming more prevalent.
Attackers are targeting cloud identity vulnerabilities
Attackers are taking note of this. According to Verizon’s 2024 DBIR, 74% of all breaches involved the human element, targeting compromised user accounts via human error, privilege misuse, use of compromised credentials, or social engineering.
While this is nothing new (some description of identity/phishing attacks have been the top attack vector since at least 2013), Crowdstrike’s latest global threat report goes further, noting that 75% of attacks to gain access were malware-free, and that “cloud-conscious” attacks (deliberate rather than opportunistic targeting of cloud services to compromise specific functionality) increased 110%. Microsoft also notes around 4,000 password attacks per second specifically targeting cloud identities, while there are suggestions from Google employees that attacks looking to steal session cookies (and therefore bypass MFA) happen at roughly the same order of magnitude as password-based attacks.
Looking beyond the numbers, evidence from breaches in the public eye tells the same story. Threat groups like APT29/Cozy Bear/The Dukes and Scattered Spider/0ktapus show how attackers are actively targeting IdP services, SaaS apps, and SSO/OAuth to carry out high-profile attacks against companies like Microsoft and Okta.
If you want to read more about this, you can check out this blog post tracking identity attacks seen in the wild.
Cloud apps and identities are the new land of opportunity for attackers. Because of the shift to cloud services, they offer the same value as a traditional attack designed to breach a network perimeter via the endpoint. In many ways, identity itself is the new attack surface. Contrary to other security boundaries like the network or endpoint, it also presents much less of an obstacle in terms of the controls that currently exist to defend this new perimeter.
Identity-based attacks used to be localized to the endpoint or adjacent “identity systems” like Active Directory. The goal for the attacker was to breach this perimeter and move within the organization. Now, identity is much more dispersed – the gateway to an ecosystem of interconnected cloud apps and services, all accessed over the internet. This has significantly shifted the magnitude of the challenge facing security teams. After all, it’s much harder to stop credential-stuffing attacks against 100 SaaS apps than the single centralized external VPN/webmail endpoint of yesteryear.
Cloud identities are the new perimeter
It seems pretty clear that cloud identities are the new digital perimeter. This isn’t the future, it’s now. The only piece that is still to be determined is what offensive techniques and tradecraft will emerge, and what the industry response will be in order to stop them.
| Security era | Techniques of the day | Industry response |
| 2000s Traditional perimeter hacking | Port scanners, vuln scanners, buffer overflows, web app attacks, WiFi hacking, client/server backdoors | Firewalls, DMZs, patch management, secure coding, WPA, penetration testing |
| 2010s Endpoint is the new perimeter | Phishing, office macros, file format bugs, browser exploits, memory resident implants, C2 frameworks | Endpoint hardening, EDR, SIEMS, red teaming, threat hunting |
| 2020s Cloud identities are the new perimeter | ??? | ??? |
Last year, Push Security released a matrix of SaaS attack techniques on GitHub (inspired by the more endpoint-focused MITRE ATT&CK Framework) that demonstrates how attackers can target a business without touching traditional surfaces such as the network or endpoints.
When chained together, these techniques enable an attacker to complete an end-to-end attack in the cloud.
Push has also released a number of blog posts covering how these techniques can be used – the most popular techniques are summarized below:
| Technique | Overview |
| AiTM phishing | 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. By proxying in real-time to the target login portal, the adversary is given access to both a valid password and valid session cookies they can steal and use to hijack the session. Once logged-in, a victim user will see all the real data they would expect to see ordinarily (e.g. their own emails/files etc) as it is a proxy of the real application. This reduces their chances of realizing they have been compromised due to the authentic working nature of the proxied application. |
| IM phishing | IM apps like Teams and Slack are a great way for attackers to evade more stringent email-based phishing protections around malicious links and attachments. The immediacy and real-time nature of IM makes it a useful vector for phishing attacks as users are less familiar with these apps as delivery vectors for phishing attacks. Using IM, it is possible to spoof/impersonate users, use bot accounts to create believable dialogue, abuse link preview functionality, and retrospectively edit messages and accounts to clean up your tracks. |
| SAMLjacking | SAMLjacking is where an attacker makes use of SAML SSO configuration settings for a SaaS tenant they control in order to redirect users to a malicious link of their choosing during the authentication process. This can be highly effective for phishing as the original URL will be a legitimate SaaS URL and users are expecting to provide credentials. It can also be used for lateral movement if an admin account for a SaaS app is compromised, by modifying or enabling SAML, pointing the URL to a credential phishing page that looks like or proxies a legitimate authentication service (e.g. Google or Microsoft). The adversary can then target users by sending seemingly legitimate links to the app login page to the tenant, which then functions in the manner of a watering hole attack. |
| Oktajacking | An attacker can set-up their own Okta tenant to be used in highly convincing phishing attacks. This attack works because Okta forwards credentials from logins for accounts tied to AD to its own AD agent that runs on the target network. Then, Okta allows the agent to report back to them about whether the login should be successful or not. This enables an attacker who has compromised an AD agent, or is able to emulate one, to both monitor login credentials for Okta users and provide skeleton key-like functionality to authenticate to Okta as any user they like. It can also be used similarly to SAMLjacking for lateral movement – except you don’t need to redirect to a separate malicious domain. |
| Shadow workflows | A shadow workflow is a technique for using SaaS automation apps to provide a code execution-like method for conducting malicious actions from a legitimate source using OAuth integrations. This could be a daily export of files from shared cloud drives, automatic forwarding and deleting of emails, cloning instant messages, exporting user directories — basically anything that is possible using the target app’s API. |
Networkless attack techniques in action
But there’s nothing quite like seeing them in action to understand just how impactful these techniques can be. So check out the clip below from Luke Jennings, VP of R&D at Push. In this video, he covers:
- Initial access via AiTM phishing using EvilNoVNC, a Browser in the Browser (BitB) phishing framework, to hijack a user Okta session
- Stealing credentials from the browser session and accessing further apps via Okta SSO, configuring those apps to create persistent access and backdoor the apps
- Performing further credential theft for other users of those apps within the corporate tenant by abusing SAML and SWA logins
- Directly accessing sensitive data and functionality within compromised apps
Could you detect and respond to this attack?
After seeing what’s possible, it’s important to ask – could you detect and respond to this attack scenario?
- Would you detect the initial AiTM phish?
- How many users would be compromised via the SAMLjacking attack?
- Would you find all the different backdoors in multiple SaaS apps?
- …or just reset the password and MFA tokens for the Okta account?
- …and what about the passwords for all the non-SAML apps?
Most organizations have a security gap when it comes to identity-based attacks. This is in large part because the controls around identity security are typically focused on securing central identity systems (think Active Directory/Entra ID) as opposed to the larger identity infrastructure as it relates to cloud apps and services.
Equally, the controls that organizations have invested in are largely bypassed by these attacks. EDR tools used to secure underlying operating systems have minimal presence here because these apps are accessed in the browser – increasingly touted as the new operating system. As discussed here, securing the identity is absolutely vital to protecting services in the cloud. And a significant portion of the attack chain – for example, phishing attempts in general, including AiTM and BitB techniques designed to bypass MFA, or password sharing across apps and services, are simply not covered by endpoint security tools, IdP logs, or SaaS logs from individual apps and services.
These types of attacks are a real challenge for many organizations right now because they fall through the cracks of existing security tools and services.
Interested in learning more?
If you want to find out more about identity attacks in the cloud and how to stop them, check out Push Security – you can try out their browser-based agent for free!
