How Push controls stop attackers from using identity attack tools and techniques to compromise your employee user accounts.
How Push controls stop attackers from using identity attack tools and techniques to compromise your employee user accounts.
The last time “hacking” topped the attacker actions chart in a Verizon DBIR, Gamestop was being saved by Redditors, ChatGPT didn’t exist, and Will Smith was welcome at the Oscars.
That’s right, it was back in the 2021 DBIR that good old-fashioned hacking was the thing hackers did the most.
In every report since, stolen credentials have been the most common “select way-in” (weird term, I know). In this year’s DBIR, stolen credentials accounted for roughly half of the breaches recorded.
These stats, along with others like CrowdStrike’s widely cited “80% of attacks involve identity and compromised credentials,” continue to prove that “hackers don’t hack in, they log in.”
In the last year, more stories behind those statistics have started to emerge with a series of high profile “no-hack” identity attacks hitting the headlines – the most recent being the Snowflake incident. You can read more about that breach and others in our repository of identity attacks in the wild where we take a deep dive into the techniques attackers have been using.
Why should they go to the effort of targeting hardened and well-monitored attack surfaces like networks and endpoints with 0-day exploits or EDR-evading malware, when they can instead simply take a set of stolen credentials and fire them at popular business apps to see which pop open?
Taking over an account is the equivalent of compromising an endpoint or getting a foothold on a web-facing server. From this point, an attacker can move laterally, escalate their privileges, and achieve their objective of deploying ransomware, stealing data or disrupting business-critical systems.
The data shows that account takeover, whether it’s using stolen credentials or session tokens, is now the route of least resistance for attackers, and the #1 attack vector for security teams to defend against.
I’m sure you already use a number of tools to secure your workforce identities – MFA, SSO, EDR, etc., and all of them have an important role to play. That said, they also have limitations that attackers are exploiting. We’ve laid out some of the typical misconceptions that can undermine an identity security strategy so you can avoid the common pitfalls and achieve defense in depth.
Push vs. account takeover techniques
In this article, we’re going to show you how to use Push to bolster your identity security strategy and prevent account takeover. More specifically, we’ll cover how Push prevents, detects, and blocks some of the common attack techniques seen in this account takeover attack chain:
Push uses browser data collected by our browser agent to either detect the attack techniques directly, or identify the vulnerabilities being exploited. Upon making a detection, the browser agent enforces a relevant security control to either block the attack or prevent the user from introducing a vulnerability.
If you’re wondering why we’ve opted to build our tool in the browser, the short answer is that being in the browser gives us:
The broadest visibility across all workforce identities, including unmanaged identities outside your IdP.
The best telemetry for detecting identity attack TTPs and tools.
The perfect enforcement point for stopping attacker actions or risky employee actions in real time.
If you want a more detailed technical explanation, you can read this article by Dan on why browser data is a better source of telemetry for detecting identity attacks than network, IdP and app logs.
Now we’ve cleared that up, let's look at some account takeover techniques.
Part 1: Phishing (including AitM and BitM toolkits)
Phishing has been around since forever and there’s a mature category of solutions that are designed to detect and prevent it. But despite solutions like security awareness training, phishing domain detection services and email filtering tools, phishing is still one of the top breach vectors.
We’ve all been conditioned to think about phishing as something that happens over email, but it’s actually the browser where most of the action happens, regardless of the initial delivery channel. Push’s position in the browser gives you the ideal vantage point for detecting and stopping phishing attacks.
The Push browser agent performs both passive observation and active interrogation in order to detect employees having their passwords harvested or visiting cloned app login pages or pages using AitM/BitM toolkits. Phishing attacks are detected in real time so Push blocks them before your employees can enter their credentials.
Detecting phishing through user behavior
Rather than trying to detect phishing websites and domains that constantly change, Push detects and blocks phishing attempts based on observing user behavior in the browser.
Push does this by observing all logins and generating a fingerprint (or technically a k-anonymized salted partial hash) of the user’s password. This fingerprint is then stored locally to allow Push to perform comparisons.
To detect potential phishing attacks, the browser agent compares the observed password fingerprint to known fingerprints for passwords that already exist in local storage.
This means that it works even if that employee was the first person to get phished using a new attacker site: Push still detects it and blocks it before your employee can submit their credentials. It also works regardless of the delivery vector used to get the phishing link to the intended victim.
Once you’ve discovered a malicious site, you can use Push’s companion feature, URL blocking, to add the domain to a blocklist and prevent your other end-users from even visiting the site.
You can programmatically manage URL blocking as part of responding to an attempted phishing incident by using the Push REST API to automatically add URLs to the blocklist or to sync with other threat intelligence sources of known-bad sites.
You can find out more about this control in this deep-dive article.
Detecting cloned login pages
It’s now very easy for attackers to create cloned login pages that appear to be legitimate, tricking users into providing their credentials.
There’s a number of phishing kits that allow the attacker to simply copy the HTML code from a legitimate website and duplicate it on the malicious site, creating a virtually identical interface that tricks users into entering their credentials. A final sprinkle of typosquatting techniques completes the illusion of legitimacy. The Federal Communications Commission (FCC) was a recent target of this kind of attack.
Push’s cloned app detection feature detects fraudulent login pages by inspecting the resources and structure of pages users log into and fingerprinting them so they can be used to detect when that action occurs on the wrong domain.
You can read more about this feature here.
Detecting AitM and BitM toolkits
Adversary-in-the-Middle (AitM) phishing is a technique that uses dedicated tooling to act as a proxy between the target and a legitimate login portal for an application, principally to bypass MFA. As it’s a proxy to the real application, the page will appear exactly as the user expects, making this technique difficult to spot. Popular AitM toolkits include Modlishka, Muraena, Evilginx and Evilproxy.
Browser-in-the-Middle (BitM) toolkits are different to AitM toolkits because they don’t act as a reverse proxy. Instead, they trick their victim into directly controlling the attacker’s own browser using remote desktop screen sharing and control approaches — think of this like VNC or RDP but using the browser as a client. This is the virtual equivalent of an attacker handing their laptop to their victim, asking them to log in to an app for them, and then taking their laptop back afterwards.
We’ve conducted a lot of research into AitM and BitM toolkits recently. If you want to learn more about how they work and see a demo of them in action, head over here.
Push gives you a preconfigured set of detections for AitM and BitM toolkits, informed by our threat detection team’s research into their behavior. This phishing tool detection feature will automatically prevent users from accessing a site that’s running one of these malicious tools, and display a custom warning message to your end-users.
Administrators can also consume phishing tool detection events via the Push REST API into their SIEM or use Push’s webhooks to alert when a warn or block event has occurred.
You can read a full write-up of this feature if you want to learn more.
Part 2: Infostealer malware
The recent Snowflake breach highlighted how infostealer malware is becoming a serious issue for security teams. As well as being able to steal credentials for account takeover, infostealers can also be used to steal session tokens which then allow the attacker to assume an already authorized session without needing to bypass MFA.
Nearly half of the malware detected last year by Sophos targeted victims’ data specifically, and the majority of that malware was classified as infostealers.
Infostealers are primarily being used by Initial Access Brokers to harvest credentials and session tokens that they then sell to other threat actors intent on executing more penetrating attacks (e.g. ransomware).
EDR is seen as the go-to solution for defending against infostealer malware. However, attackers are always looking for ways to get around security controls by obfuscating malicious behavior and evading signature-based checks. For example, a flaw in Microsoft Defender SmartScreen was recently exploited to deliver infostealer malware.
Getting total coverage across your endpoint estate is notoriously difficult, if not totally unrealistic. Unless the malware is stopped on execution, then data will inevitably be stolen, and will continue to be taken until stopped (or it self-terminates). And once an attacker has stolen employee credentials or sessions, the credential stuffing and session hijacking attacks that come next won’t touch the endpoint.
For those reasons, you can’t rely on EDR as a single line of defense against infostealers. Push gives you those extra layers of defense to stop account takeover attempts that use stolen credentials and sessions.
Detecting stolen sessions
Push uses its browser agent to inject a unique marker into the user agent string of sessions that occur in browsers enrolled in Push. You then add the list of domains where you wish to inject the marker into sessions, such as an identity provider like Okta or Microsoft.
By analyzing logs from the IdP, you can identify activity from the same session that both has the Push marker and that lacks the marker. This can only ever happen when a session is extracted from a browser and maliciously imported into a different browser.
This is a high-fidelity signal that a stolen session token is being used by an attacker. It’s certainly a lot cleaner than relying on IP-based or geolocation-based signals, which result in frequent false positives.
Detecting stolen credentials being sold on the dark web
Push integrates stolen credential threat intelligence and alerts you when your employees’ credentials are being sold on the dark web.
Commercial TI feeds of stolen credentials have been available for some time. But what we’ve found is that the false-positive rate is incredibly high and the vast majority of credentials are no longer in use.
Push validates that leaked credentials match those that are currently being used by your employees to authenticate on any apps they are using in the browser. That means that any alerts or automated actions generated by Push are actionable true positives, cutting out a huge amount of noise and saving your security team time.
Part 3: Credential stuffing
The previous sections looked at how Push detects and stops common techniques used for stealing and acquiring credentials. We’re now going to cover how Push stops stolen credentials from being used to access and take over employee accounts.
Credential stuffing is when attackers use tools that automate the process of taking a list of stolen passwords and retargeting those credentials against different apps.
Closely related to credential stuffing is password spraying. Instead of using stolen credentials, an attacker uses a list of commonly used usernames and passwords to attempt to compromise accounts.
Both credential stuffing and password spraying are high-volume, automated attacks, and they are an unrelenting problem for most businesses. Microsoft observes 4,000 of them every second and nearly half of all login requests Auth0 receive each day are attempts at credential stuffing.
The true scale of the problem is hard to grasp, as neither app vendors nor users have effective means of monitoring for unauthorized access. Typically these breaches are only detected when:
The attacker leaks the data they’ve stolen, like in the Snowflake breach.
The attacker deploys ransomware that results in business disruption, like that suffered by MGM resorts.
The attackers use a compromised account to do something deliberately in the public eye. For example, when the SEC’s X (formerly Twitter) account was compromised and sent out a message announcing the approval of Bitcoin ETF.
Push gives you a number of controls to combat attacks using stolen and guessed passwords, both to prevent them from occurring, and detect them when they do.
Prevent employees using credentials that have already been stolen and leaked
First, let's stop your employees from using any credentials that have already been stolen and are available to attackers for use in a credential-stuffing attack.
Push monitors stolen credential threat intelligence and compares it to the credentials employees are currently using to access their apps.
You might be wondering, “Does that mean Push sees all our employees’ passwords!?” No. Rather, we use a fingerprint of each password and it's checked locally in the users’ browser and never leaves it.
When we get a match – a stolen password that could successfully be used in a credential-stuffing attack – Push alerts you.
Enforce MFA on all employee accounts
Next step is to secure the accounts most vulnerable to a credential stuffing attack – those that only use a password for single-factor authentication.
If you’re using SSO to access apps, then it’s easy to overlook instances where local accounts (e.g. username and password logins) are missing MFA – particularly if you’re relying on an IdP solution to audit and enforce MFA. You can read more about this problem in our blog post on ghost logins.
Push observes every login made by your employees (both inside and outside SSO) and inspects the authentication protocols used. Accounts that are missing MFA are identified and presented to you in the Push platform.
You can then use Push to enforce MFA on employee accounts, or present them with in-browser guidance requesting that they enable it themselves.
Prevent multiple accounts being compromised by credential stuffing due to password reuse
The credential stuffing tools that attackers use will target a long list of popular business apps. If a password is reused across multiple apps and is breached, the blast radius is naturally increased – the attacker will be able to hijack multiple accounts, across numerous business applications.
Push detects when employees are trying to use the same password across multiple apps. When this happens, you can request that they change their password.
Prevent password spraying breaches
To stop your employees’ accounts from being breached by password spraying attacks, Push checks every password to see if it is easily guessable for attackers.
To determine if a password is easily guessable, the Push browser agent automatically checks the password against:
A list of top 10,000 weak base passwords.
Number and special character variations on these weak base passwords, for example: Password1! or January2022.
Variations on these weak base passwords that replace letters with numerals (1337), for example: P455w0rd.
You can also add your own custom word list that employees and attackers will predictably try and use. Push will then stop those words being used as part of passwords.
Detect unauthorized sessions
Once you have enabled all the Push controls that prevent employees from creating and using accounts that can be easily compromised by credential stuffing and password spraying attacks, the next line of defense is to detect when accounts are taken over.
Push uses its browser agent to inject a unique marker into the user agent string of sessions that occur in browsers enrolled in Push. You then add the list of domains that you want to have injected with the session marker.
By analyzing logs from the IdP, you can identify activity from the same session that both has the Push marker and that lacks the marker. This indicates that the session is not being used by the legitimate user (your employees) in their usual work browser, and could be an attacker using their account.
Reduce your identity attack surface
Finally, you’ll likely want to reduce your attack surface that can be targeted by credential stuffing. In other words, reduce the number of username and password accounts your employees have.
There are a few ways that Push can help you do this.
Block access to unapproved apps. Using Push, you can create a block list of apps that you don’t want your users to create accounts and identities on.
Use app banners to stop users from creating local accounts. When an employee goes to sign up to an app, Push will present an app banner that tells them to use their SSO identity and not to create a username and password account.
Get existing accounts and apps behind SSO. Push shows you how your employees are logging in to every account on every app, including whether they’re using SAML or OIDC SSO. Armed with this data, you can get your employees to use your preferred SSO solution on the apps where it’s already available, and look into whether other popular apps being used in the business offer SSO.
Stop account takeover at the push of a button
We’ve described a lot of controls in this article. The good news is that they’re all pre-configured on the the Controls page in the Push platform. When you get started with Push, you can simply turn on all the controls you want, and decide whether you want them to work in monitor, warn mode or block mode.
Try it for yourself
You can try Push by creating a free account on pushsecurity.com. You can also book a demo. We’ll be happy to show you these features, along with how we discover all the apps your employees are using, even the ones not behind SSO.
