How real-world attacks and research drove Push’s most popular features of 2024

From massive breaches like the Snowflake incident to novel phishing techniques documented by Push researchers, 2024 was the year that identity attacks left their mark. Looking back over what we saw in the wild and what we found through Push’s own research, three key themes stand out:

• Account takeover techniques on cloud apps are fundamentally different from traditional network-based attacks. To have the best chance of preventing account takeover, defenders need to  disrupt attacks before they’re successful.

• It’s not easy or practical to maintain 100 percent compliance on identity posture standards in a world where employees are using and signing up to apps outside of IT oversight — but it is possible to make this work a lot easier by using tools that help you scale your remediation activities.

• Despite another year where cybersecurity spend increased (now up to almost $1,100 per user, according to Forrester), existing approaches are not successfully preventing account takeovers. Security teams need to be able to detect and respond to these attacks where they happen: The browser.

In this article, we’ll take a look back at how these themes influenced key features we delivered for Push customers in 2024.

Defending against modern phishing attacks

Phishing techniques that bypass MFA are now the norm, and few organizations have successfully achieved full coverage of phishing-resistant MFA methods. 

Equally, while phishing attacks via email remain the most commonly reported vector, phishing attacks increasingly target users outside of email. For example, phishing links are often encountered through normal internet use — such as in malicious Google ads — and attackers frequently conduct their campaigns over IM platforms like Slack and Teams. Late last year there was a rise in attackers inundating users with spam via Teams, combined with phone scams posing as IT admins. Since anti-phishing controls are usually email-based, they fail to protect users from attacks taking place elsewhere. 

At Push, we’ve built a suite of anti-phishing features over the last year that act as a defense-in-depth approach to the types of modern phishing techniques we’ve been observing in the wild. Here’s what we built and why.

Protecting passwords used for SSO

What happened?

Attackers explicitly targeted Okta, Entra, and Google Workspace accounts in 2023 and 2024, so we knew a top priority would be protecting identity provider accounts. These IdP accounts are a key target because they allow attackers to move laterally to other valuable apps and data via SSO following the initial account takeover.

It’s not just the typical IdPs you need to watch out for, either: Apps like GitHub, Slack, Salesforce, Facebook, X, and others all provide SSO functionality, increasing the blast radius of a compromise. And as we reported in our research on cross-IdP impersonation, apps can be accessed using multiple SSO methods simultaneously — and 3 in 5 apps that we tested recently did not require re-verification by default when adding a new login method.

Phishing is a problem that would be significantly reduced in a world without passwords. But while the ideal case is that organizations can put in place phishing-resistant authentication methods like passkeys or other WebAuthn-based methods, the reality is that it’s not a perfect solution right now — widespread passkey implementation is hard to achieve.

One of the key advantages of passkeys is that they are domain-bound: Meaning they can’t be used on a site with the wrong domain. So, we started thinking: What if it were possible to essentially domain-bind a password? 

What we built

In the first half of 2024, we delivered our SSO password protection feature, which allows Push administrators to block employees from entering their IdP password into any site that’s not the identity provider — in effect domain-binding SSO credentials. 

Push accomplishes this via the Push browser agent, which observes and fingerprints the user’s SSO password and legitimate SSO login pages, and then enforces in-browser controls to prevent an SSO password from being submitted on any URL that doesn’t match the legitimate provider, an extremely strong anti-phishing protection. Separately, Push also verifies that passwords it observes are not easily guessable.

The idea behind this approach is to gain some similar benefits to passkeys — by ensuring that passwords used for SSO access to your apps cannot be phished and are unique and strong — but in a way that “just works” with existing password-based authentication. 

Organizations that monitor for SSO password reuse will find that the practice turns out to be incredibly widespread, so being able to detect and prevent password reuse — even outside of actual phishing attempts — is an asset to security teams. (Our research shows that 10% of IdP accounts are using a password that is shared with another app — where it is much more likely to be compromised.) 

By streaming events to your SIEM and setting up a simple automation, you can also use Push-supplied intelligence on SSO password reuse to automatically reset potentially compromised passwords — this provides instant response to successful phishing and gets rid of password re-use of your most sensitive credentials in one move - the kind of combo we love!

Blocking AitM phishing and cloned login pages

What happened?

When you’re able to detect SSO passwords being used in all the wrong places, it’s not surprising that one of the main offenders is phishing attacks. 

In 2024, we wrote extensively about the rise in modern phishing attacks that use adversary-in-the middle toolkits (AiTM), including EvilNoVNC, Evilginx, and others.

AiTM phishing is a newer variant of phishing that allows attackers to bypass MFA protection by using tools that act as a proxy between the end-user and a legitimate login portal. AitM attacks increased 146% in 2023 (Microsoft).

This trend in tradecraft was reflected in our own customer base last year, but what’s interesting is that we observed a lot of phish kits and tactics that were new — meaning traditional detections failed to find them before Push did. 

In particular, we saw newer web-based obfuscation techniques that allowed attackers to get past the features of email security tools like web gateways and email scanning appliances, such as bypassing web sandbox analysis, and deter other forms of automated investigation by using Cloudflare Turnstile and other tactics — similar to the approaches legit websites use to protect against automated bots (this is essentially the same problem for both).

The gap in existing controls was obvious: When all phishing routes eventually lead to the browser, security teams need to be able to detect and respond in the browser. To do this well they need to observe what the employee sees, not what loads in a sandbox.

What we built

To address this gap, we released new capabilities for the Push browser agent to be able to detect and block when a site is running AiTM phishing toolkits. 

Push does this via a set of readymade detections for common AiTM tools. By dynamically analyzing the behavior of malware in the browser, the Push browser agent can find indicators of compromise beyond just domains, file names, IP addresses, etc., focusing instead on behavioral attributes, such as Javascript calls being made or data structures saved to local storage.

This approach of focusing on the top of the Pyramid of Pain — e.g. building detections for attributes of an attack that are the hardest for attackers to change, and therefore the most reliably accurate — is core to Push’s design philosophy. 

Finally, toward the second half of the year, we released cloned login page detection, a natural extension of our layered approach to preventing phishing attacks in the browser. With this security control, you can identify malicious webpages that are masquerading as legitimate IdP login portals. 

When a cloned login page is detected, you can add the URL to your blocklist in Push and prevent any other employees from being targeted. 

By layering multiple anti-phishing controls that all prevent account takeover, defenders have the best chance at thwarting the short, fast attack chains that are emblematic of today’s identity attacks.

Defending against stolen sessions and stolen credentials

With as little as $10 to buy a stolen password and a little skill, attackers capitalized on the use of stolen credentials last year. Stolen creds were the No. 1 attacker action in 2023 and 2024, according to Verizon.

Nowhere was this more plain than in the attacks on Snowflake customers, one of the biggest breaches of last year. In this incident, cyber criminals targeted around 165 customers of the cloud-based data warehouse tool Snowflake by taking over accounts using credentials harvested from infostealer infections dating as far back as 2020.

The Snowflake incident underscored the challenges of control and visibility that security teams face when attempting to secure identities on a patchwork of managed and unmanaged apps:

• Do I know all the workforce accounts my employees use?

• Do those accounts have a strong security posture?

• Do those accounts use MFA? The most phishing-resistant methods?

• Do I have tools to detect, respond, and remediate after an account takeover or breach of a critical software vendor?

• Do I know when a session has been stolen, pointing to a device compromised by infostealer malware?

Here’s what we delivered last year to make it easier for security teams to protect their organizations from the threat of stolen sessions and stolen creds.

Detecting stolen sessions

What happened?

Infostealer malware — a type of malware designed to collect user credentials, including session cookies, from end-user devices — had a very successful 2024, accounting for nearly 10 percent of activity that Red Canary was able to associate with named threats, and the majority of all detected malware that Sophos threat researchers documented last year.

While the use of stolen credentials is rampant, often facilitated by successful infostealer campaigns, a related attack type also jumped in prevalence last year: session token theft attacks.

Using stolen tokens, adversaries don’t need to bypass MFA directly. They can simply import the tokens into their browser and assume an already authorized session. 

What we built

In order to detect a stolen session in use, you need telemetry that allows you to tie activity to a trusted endpoint. This didn’t previously exist, and you have to be in the browser to do it. So that’s what we built. 

Push’s session theft detection capability uses the power of the Push browser extension to inject a unique marker into the user-agent string of sessions that occur in browsers enrolled in Push. 

By analyzing logs from your IdP in your SIEM, you can then identify activity from the same session that both has and that lacks the Push marker, indicating that a session has been extracted from the browser and maliciously imported into a different browser that is not enrolled in Push.

This is a reliable signal that a stolen session token is being used and an endpoint has been compromised.

Detecting compromised credentials

What happened?

Alongside stolen session cookies, stolen credentials made a lot of headlines last year. The 2024 Verizon DBIR found that 79% of web application compromises were the result of breached creds, and researchers at IBM found a 71% year-over-year increase in cyberattacks using stolen or compromised credentials.

In Push’s own research, we counted 30 public identity-related breaches in 2024 where the breach and the breach vector were disclosed. Of those, nearly three-quarters were the result of compromised credentials, including notable breaches such as Microsoft, Change Healthcare, and the attacks on Snowflake customers.

The influx of compromised credentials has been amplified by the rise of infostealers, which contribute the vast majority of valid stolen credentials, alongside mass credential phishing campaigns and third-party data breach dumps. 

And while there’s no shortage of threat intelligence about stolen credentials for sale on the web, security teams struggle to separate the needle from the haystack because a large portion of TI on stolen creds is out of date.

In evaluating TI data here at Push, we reviewed 5,763 username and password combos that matched domains in use by Push customers. We found that less than 1% of the creds in a multi-vendor dataset were true positives. In other words, 99.5% of the stolen creds we checked were false positives at the time of review — illustrating the challenge security teams face when trying to extract actionable intelligence from this kind of data. 

What we built

Using its browser agent, Push assesses the strength of end-user passwords by creating and analyzing a truncated, salted SHA256 hash of the password for a given account. (These k-anonymized fingerprints are never seen by Push’s back-end and exist only in local browser extension storage.) 

These fingerprints give Push a directly observable source of truth for corporate creds, which allowed us to build a verified stolen credential detection capability last year that removes all false positives from TI sources to pinpoint only those stolen creds still actively in use by employees.

Reducing and securing shadow IT and account sprawl

You can think of this last part of the story as the ground from which the attack trends we’ve been talking about emerged: The shift to doing business almost entirely in the browser, and the resulting sprawl in accounts and unmanaged apps, leading to an explosion of internet-facing identities for threat actors to target.

Even in organizations with mature security practices, the challenge of getting 100% compliance with identity posture best practices is evident. Last year, Push researchers analyzed a data set of 300,000 accounts from our customer base and found that:

• Organizations have more apps and identities than they thought — an average of ~15 identities per employee and ~220 apps per organization.

• Many accounts lack basic security protections, with 37% of accounts lacking any form of MFA and ~9% of accounts using a password that is leaked, weak, or reused, making them especially susceptible to account takeover. On accounts where password is the only login method in use (e.g. not using SSO or any other federated login like OIDC), there was no MFA in use in 4 out of 5 cases.

• Security gaps persist even with SSO accounts — with 10% of SSO-using accounts also having a local password, a risk for ghost logins; and 1 in 5 IdP accounts themselves missing MFA.

From our perspective, organizations need scalable controls, and they need easy-to-deploy tools that get them visibility of all their workforce identities, apps, and accounts alongside telemetry that makes the information actionable.

Push already provides a real-time inventory of all your accounts and apps, including internal corporate apps, and analyzes the security posture, login methods, and MFA status of those accounts to offer a comprehensive picture of your identity attack surface. 

To help customers enforce their security policies even more seamlessly, here’s what we built last year:

1. App banners

With a range of modes from informing to blocking, app banners allow security teams to communicate best practices and policies with end-users directly in their browser. It works by displaying a banner with your custom message on the login and signup pages for workplace apps. 

Using configuration rules, you can set conditions for how banner controls get applied. Common use cases include: Restricting use of GenAI software; carving out an exception for admins on a specific app; reminding users to log in with SSO instead of a password, and others. 

2. Password manager identification

We also expanded Push’s capability to observe employees’ account security posture by adding an identification of which password manager (if any) they’re using. 

We’ve heard from many security teams that they’re concerned about corporate credentials being stored in unapproved password managers — not to mention the ROI from ensuring employees are all using the corporate password manager you already pay for. This feature helps them achieve both objectives.

3. MFA enforcement

Finally, we rounded out 2024 with a new security control called MFA enforcement that builds on the popular app banners concept by detecting when users lack MFA and then prompting them to register for MFA. 

Admins choose which apps they wish to enforce MFA on, and the Push extension does the rest. 

Security teams we work with are especially eager to use this feature to close MFA coverage gaps on non-SSO and otherwise unmanaged applications.

Want to see more?

There’s a lot we didn’t touch on here that Push can help you achieve. If you’d like to learn more, set up a demo with our team or sign up yourself to have a look at the platform.