5 reasons why Push Security shouldn’t exist

If you caught our CEO Adam’s recent appearance on the Defense in Depth podcast you’ll have heard some top-tier banter between Geoff and David on the problem of identity security – and how, in Geoff’s words, “way too many people” think they’ve got it covered when it comes to identity attacks.

At Push, we’re completely focused on identity security. We’re constantly exploring the limits of controls against the latest threats. But naturally, security teams with hundreds of priorities can’t afford to dedicate the same amount of research time to this problem that we can. This means we come across a lot of common misconceptions about how controls like MFA, SSO and EDR perform against current identity attack techniques. 

These common misconceptions are severely impacting the ability of security teams to plan for, and defend against, identity-based attacks – giving attackers the window of opportunity they need to continue exploiting people and businesses. 

So, we hope that this allows you a clearer perspective when building your identity security strategy, with a realistic view of what a particular control will give you – and what it won’t. That isn’t to say you should discard any of these controls; they all have an important part to play! But, it’s important to be aware of their limitations to be able to build a resilient security model, with strategic defense in depth to compensate for known weaknesses. 

Without further ado, here are the top reasons why Push Security shouldn’t exist. 

Reason 1: “Identity attacks aren’t a priority”

Particularly in the current economic climate, with many security teams feeling the squeeze, organizations often haven’t budgeted (mentally or financially) for the rising threat of identity attacks. Or, there’s an assumption that it’s more of a security hygiene issue, and already adequately covered by other security investments (it isn’t).  

We get it, now isn’t a great time to be tackling a new problem. Getting the budget to do the same as last year is difficult enough, never mind adding something new. 

But, there’s clear evidence that identity attacks are now the #1 cyber threat facing organizations in both frequency and impact, and therefore should be prioritized. 

• Stolen creds are the #1 breach vector in 79% of web app attacks (Verizon).  

• 147,000 token replay attacks in 2023, 111% increase year-over-year (Microsoft). 

• 80% of attacks involve identity and compromised credentials (Crowdstrike).  

• 4,000 password-based attacks per second observed (Microsoft).

It’s telling that the cyber crime ecosystem itself seems to be leaning toward the theft, sale, and use of stolen credentials (not just emails and passwords, but session tokens too).

• According to the 2024 DBIR, more than 1000 credentials appear on criminal forums and marketplaces every day, with the majority (65%) appearing less than a day after first being discovered.

• In June, Troy Hunt at Have I Been Pwned (HIBP) wrote about the impact of channels like Telegram and the sale of combolists (username, password, login portal URL), after being sent 122GB of data scraped out of thousands of Telegram channels, containing 361M unique email addresses (of which 151M had never been seen in HIBP before).

• In July, 10 billion passwords were leaked in the RockYou2024 compilation. 

• And ultimately, high-profile breaches of Snowflake customers, Microsoft, Okta, and others reinforce the threat behind the numbers, all of which are the result of identity attacks. 

So, if a business uses any third-party provided web applications or services, then its workforce identities are the lowest-hanging fruit for attackers to pick, and the risk of account takeover should be high up on the risk register. 

Yes, it’s tough to redo budgets on the fly or rip up a five year plan. But, asymmetrical cyber TTPs have always sought to undermine the best laid plans of CISOs – attackers usually look in the places that defenders aren't.

When looking at the evidence, is securing the identity attack surface really a lower priority than adding a CASB, CSPM, or shiny new AI tool? Even when we look at historical recurring spend on things like EDR or vulnerability management, it’s arguable that the risk of identity attacks has overtaken software-based exploits for many organizations whose traditional networks are shrinking, while their cloud app estate grows. 

It’s important to consider what’s right for your business, but the evidence shows us that securing the identity attack surface promises real risk reduction in the face of a genuine threat. 

Reason 2: “Our business apps are all behind SSO”

SSO is often seen as a utopia where each employee has a single, secure digital identity that is used to access all of their work applications. When businesses are using SSO, we usually hear:

“Everything is behind SSO, there are no apps outside of it.”

Unfortunately, organizations are always using more apps than they realize. The impact of product-led growth on the self adoption of cloud services is well documented, and we see that even SMEs typically have 100+ apps in their estate, and the number of apps per business continues to grow year on year. 

So, while every known app might be behind SSO, this still leaves tens or hundreds of unknown apps, with thousands of associated identities. 

But even if you did know about every app, the fact of the matter is that fewer than 1 in 3 apps actually support SAML SSO, and many of those only at the premium tier. Our data shows that the proportion of apps actually behind SSO is even lower, at 1 in 5. So getting everything behind SSO just isn’t a realistic goal for any organization. 

“Everything important is behind SSO, and the apps that aren’t don’t pose a risk.” 

There’s often a view that if it wasn’t centrally procured, IT wasn’t involved, and it’s not behind SSO, then it’s just not a concern. But apps can have complex integrations and permissions that increase the potential blast radius of an app compromise. 

We’ve published extensive research on SaaS-native attack techniques and documented many of the scenarios in which attackers can expand from hijacking a single SaaS app with a small number of users into a larger-scale compromise, for example through SAMLjacking: Modifying SAML for a compromised app to redirect users to a malicious domain during the authentication process that proxies a legitimate authentication service (e.g. Google, Okta or Microsoft) – effectively acting as a watering hole for further credential harvesting. 

Also, the value of an app is not necessarily tied to the number of users it has in the business. A sales and marketing app can contain huge amounts of sensitive data, as can developer apps – just look at Snowflake! It only takes a single account to be created, a single integration to be set up, to result in a major data breach down the line. 

You can check out our blog page or watch one of our videos for more information.   

Ghost logins: A nightmare for SSO, dreamy for attackers

You might already be feeling a bit deflated that SSO isn’t going to give you everything you wanted, and we’re sorry to be the bearer of bad news. Unfortunately, even if you are using SSO, additional login methods can still exist alongside SSO. We call these ghost logins. 

Ghost logins are effectively any alternative login method. In addition to SSO, you could have a local username and password, a social login (e.g., login with Google, Facebook, etc.). You can also have things like backup emails or API-based login methods. 

Multiple methods are often enabled by default and need to be explicitly disabled at the app level. Further, migrating an existing app to SSO doesn’t automatically remove local accounts, but effectively adds an SSO layer on top. 

The final problem here is that because MFA is applied separately at the app level and SSO level, you can have local logins without MFA simultaneously with SSO logins with MFA. This was acutely felt during the recent Snowflake breaches, where in-app identification and disabling of non-SSO logins proved to be particularly error-prone.  

The result here is that credential stuffing attacks can still prove successful against your SSO-joined apps if local logins exist, and MFA hasn’t been specifically set at the app level. And unless you’ve specifically disabled them and unset every non-SSO login for every app, they probably do. 

The verdict: SSO is great, but it can't solve identity security on its own

While SSO is invariably a beneficial security control, attackers can also naturally exploit it to gain access to a large number of downstream applications. If you compromise an IdP account like Okta, you can then access any connected app, often without requiring any further authentication.

We’ve seen this recently, with an unprecedented spike in credential stuffing attacks reported by Okta, as well as attacks looking to exploit Okta’s CORS feature. 

Ultimately, the promised land of a 1:1 employee to identity ratio just isn’t realistic. So while SSO is a big part of the solution to identity attacks, it’s not a silver bullet.   

Reason 3: “We’ve got MFA deployed everywhere”

Microsoft famously stated that MFA reduces the risk of compromise by 99.2%. But this doesn’t mean that it stops 99% of attacks. Or, that it should make up 99% of your defense. 

MFA unarguably raises the bar for attackers, even if that bar is still pretty low. Naturally, accounts without MFA are an easier target. But the problem is that MFA isn’t an enterprise-wide castle wall. It’s more like a row of hurdles with gaps in-between. 

MFA is usually handled separately at the SSO level and app level. For apps that are self-adopted by end users, they can't be relied on to add in a security control that will introduce friction to their user experience. Building on the aforementioned ghost logins, even if MFA is adopted at the SSO level, local logins can exist without MFA unless also applied at the app level. The recent Snowflake breach is a perfect example of this problem. 

Because of this, we find that only around 1 in 3 identities actually have MFA enabled. 

"MFA protects us against phishing attacks"

Even where MFA is deployed, most MFA methods are proven to be phishable or otherwise bypassable. SMS and push-based MFA are susceptible to well known bypasses including SIM swapping and MFA fatigue attacks. TOTP is a little better, but still vulnerable. 

Many attacks are simply cutting out the middleman and focusing on using stolen session tokens to bypass MFA. The most common method for this is via infostealers, which typically scrape all credentials (e.g. usernames, passwords, login pages, session tokens) as well as other information stored in the browser of an infected device. Infostealers played a major role in the recent Snowflake breach. 

Additionally, modern phishing techniques like adversary-in-the-middle (AitM) and browser-in-the-middle (BitM) see the attacker steal the live session and associated tokens from the victim, with the victim prompted to complete the MFA process as part of the attack. 

“We’re using passkeys”

Great! Passkey users are in a better position than 99% of other businesses. Passkeys are widely accepted to be phishing resistant – at least for now, although as more businesses use them, new ways of getting around them will no doubt be discovered by attackers. 

But, MFA downgrade attacks are possible. There are often backup MFA methods set that can be selected by canceling the authentication prompt and selecting a different method. Even when these aren’t selectable, researchers have demonstrated ways of downgrading authentication to use a phishable method. 

Most apps are designed primarily for user flexibility, not security. And backup methods have a legitimate use-case – what if the authenticator device is lost or stops working? If passkeys are the only authentication method, you just got locked out of all of your accounts. But at least no hackers can access them either, right?

Like SSO, unless backup MFA methods are disabled for all identities and apps, and all users have enabled MFA across all their accounts and login methods, this isn’t a silver bullet either.  

Reason 4: “We’ve got anti-phishing controls already”

Identity attacks have evolved significantly in recent years, as have the environments being targeted by attackers with the shift to cloud services and decentralized business IT. Unfortunately, traditional anti-phishing controls weren’t designed for this reality. 

• Credential stuffing attacks used to be focused on a single VPN/webmail endpoint that was naturally easier to protect than 100+ SaaS apps (especially if the security team isn’t even aware of them). Attackers now have 1000s of sprawled identities to target per enterprise, increasing the chance that weak or reused passwords will be found. 

• Likewise, security teams only needed to care about a small set of credentials relating to user directory accounts and VPN/remote access tooling used to tunnel into the corporate network. Now, business functions and data are dispersed across cloud apps rather than being neatly contained in on-prem apps and databases.

Now, attackers have more platforms on which to phish your users, more credentials to choose from, and more apps to spray them across, while security teams have a much larger surface to defend.

“Our email and content filtering controls stop phishing attacks”

Existing phishing prevention solutions have tried to solve the problem by protecting the inbox, a common (but not the only) attack vector, or by blocking lists of known-bad domains. 

But, these approaches have major shortcomings:

• Incomplete coverage: Email-based phishing prevention tools can catch general spray-and-pray email phishing campaigns, but it only takes a small amount of tailoring to fly under their radar. The use of LLM tools to tailor phishing emails for their intended victims already makes this possible at scale. Email-based tools also fail to cover phishing attacks beyond the inbox, such as Slack and Teams phishing.

• Expired intel: Tools that rely on known-bad domains always have an incomplete picture because a domain must be reported as malicious in order to get added to a blocklist. Meanwhile, attackers can spin up new sites or host phishing pages on existing sites by exploiting vulnerabilities in them, bypassing rules around preventing visits to newly registered domains. It’s like trying to hit a moving target.

• Web-based obfuscation: Attacker tools and malicious implants running on webpages are constantly evolving to evade fingerprinting, and attackers are using techniques like HTML smuggling to get around web-based controls put in place by developers. 

Even if these controls are sometimes successful, attackers have reliably demonstrated ways to get around them, it really is a cat-and-mouse game at this point. There usually needs to be a compromise before the attacker's infrastructure or tooling can be tagged and blocked, but they evolve so rapidly that defenders are always one step behind. 

“All our employees use a password manager”

Password managers are increasingly necessary due to the large number of credentials that users now have to juggle. Since the majority of apps don’t support SAML SSO, the need for separate credentials per app isn’t going away any time soon. 

We often find 2 or more password managers in use per organization (not exactly optimal), but despite increased password manager adoption we see consistently high levels of password reuse, with 1 in 3 users reusing passwords – including their sensitive IdP credentials. 

High levels of password reuse shows us that password managers don’t automatically result in secure employee behaviors, while widespread credential reuse significantly increases exposure to credential stuffing attacks where attackers spray known username and password combinations across a range of app login pages.  

Generally, businesses have very limited visibility into employee password data to be able to enforce good practice or accurately respond to data breaches involving credential dumps, even if employees are using a password manager (or several, as the case may be).  

Reason 5: “We’ve got all the security data we need”

Organizations looking to protect themselves from modern identity attacks suffer from a pretty substantial telemetry gap. 

• Endpoint logs won’t show anything meaningful because most identity attacks don’t need to target the endpoint – no malware is deployed, everything happens in the browser, over the internet. 

• Application logs are limited in availability, scope, and ease of ingestion, with most app vendors providing substandard logging, and requiring complex custom integrations to get what little data is available. 

• Network logs (such as via web proxy) struggle to gather and piece together identity data points at-scale, across different apps, due to the sheer volume and broken format of the data post-TLS-termination. 

• Identity provider logs naturally only cover SSO integrated apps (and therefore don’t cover ⅔ of your business apps) and look exclusively at authentication, and so are blind to client side attacks like phishing. 

Unless you’re ingesting data from a browser-based solution like Push, it’s unlikely you have a full monitoring visibility of your identity attack surface. Read more on the value of browser telemetry here. 

Maybe there’s a reason for Push to exist after all!

The key takeaway here is that there are no quick fixes or silver bullets. Things like SSO, MFA, and password managers are all part of the solution, but aren’t set-and-forget controls. They need to be continually monitored and maintained to ensure they remain effective.

Push stops identity attacks by continually finding and fixing identity vulnerabilities, providing deep context to manage the identity attack surface without looking through blinkers at the IdP or individual apps. 

Push helps businesses to get the most out of their identity controls (and bridge the gaps they leave) by:

• Locating all business apps, not just those plugged into your IdP, so they can be put behind SSO (where possible) or at least securely managed and configured.

• Identifying all workforce identities, associated login types, and MFA methods to more clearly pinpoint gaps, harden identities, and remediate vulnerabilities like ghost logins.

• Stopping account takeover attempts by detecting and blocking AitM and BitM phishing toolkits running on webpages, blocking sensitive credential reuse to prevent credential phishing, and identifying stolen sessions running in attacker browsers. 

• Preventing password-based attacks by detecting the use of weak, reused, and breached passwords across the app estate.  

• Providing unique telemetry in the browser to build both proactive and reactive security operations workflows, or add missing context to other data sources, such as IdP, application, or endpoint logs.