5 ways to defeat identity-based attacks

What is in an identity?

Like real identities, digital identities are a little hard to define. Formally it’s a mapping of a human into the digital world, but more often this term is used as synonymous with a credential (e.g. a username and password, a Multi-Factor Authentication (MFA) device, or a fingerprint) - the thing you use to prove you own the identity in an authentication process. When people say an identity is breached, they typically mean the credentials have been stolen.

This is a useful simplification, but bear in mind that reality is a bit more complex. For example - identities are typically tied to an account on an application (you want to login to Slack, Slack knows your password), but can also trust a third party (an Identity Provider or IdP) to authenticate an identity on your behalf in what’s known as federation (“login with Google” on Slack).

Surprisingly, it’s very common for modern apps to allow a user to authenticate to the same account using a local credential (a username and password) and a federated identity (e.g. the “login with Google” or “login with Microsoft” buttons) interchangeably.

That’s how you could wind up with multiple identities tied to a single account, or multiple accounts tied to a single federated identity. This is exactly what you see for real users - and every weird in-between case to boot.

The “new perimeter” … from a red-teamer’s perspective

To see how identities are the new thing, it helps to see how we got here.

The good old days

A couple of decades ago, I was just getting started as a red-teamer or penetration tester, or whatever you want to call it. The job is to do what real attackers do so clients could understand the attack techniques and better defend against them. The most stressful part of each project was the first step - getting initial access to the target - getting past their perimeter and into the (usually) soft internals.

A security perimeter is a boundary at which controls can be enforced. From an offensive perspective, a security perimeter is the same as an attack surface: where you can target initial attacks to gain a foothold, from which you can launch further attacks. I use perimeter and attack surface interchangeably going forward.

A perimeter can be physical, like a wall around a house, or virtual like the network boundary between an internal network and the internet where controls are things like firewalls. A couple of decades ago this internet network boundary was the perimeter. As any decent red-teamer during this era, we had a pretty well-oiled process of mapping a client’s external network, scanning it for services, and then identifying and exploiting known vulnerabilities in those services. With this foothold on a target network, we could pivot to other, more sensitive internal systems.

Blue teams started having success with automated vulnerability scanning and patching programs, during this time. Then red teams responded by focusing on finding new vulnerabilities, especially in custom code like web applications. I fondly remember using techniques like xp_cmdshell with SQL injection to get access to breach perimeter systems and get access to internal networks. As DMZs, SDLC, vuln scanning and a dozen other tactics became generally adopted things improved to the point where those standard red-team playbooks weren’t working anymore. 

The shift to targeting users and their endpoints

About a decade ago, attackers realized it was easier to breach the perimeter and gain access to internal networks by simply targeting users with endpoints directly connected to the internal network. At the time the main techniques were email phishing and malicious web pages delivering exploits or straight malware. We put down Burp and our other web app testing tools and started spending our time crafting phishing emails with malicious macro-laden Microsoft Office documents for that initial entrypoint.

Defenders were on the back foot and even back then the “train your employees to spot attacks” advice felt as totally unrealistic as it’s now proved to be. The zeitgeist suggested, "Attackers only need to succeed once; defenders must succeed every time." Defenders were blind and the focus was firmly on detection. Much much better telemetry was needed, which spawned the endpoint detection and response (EDR) revolution. 

EDR required immediate changes to red team tactics, and together with better endpoint security defaults, automatic OS updates (that actually started working) and memory exploit protections (things like DEP and ASLR) the timelines for successful attacks were stretching a lot.

The modern perimeter

Attackers have had to change tactics yet again, due to the rising cost of attacking endpoints and the fact that data has moved off endpoints and internal networks and onto cloud systems or Software as a Service (SaaS) applications.

Identities have always existed as a target for attackers and were a critical part of the kill chain, but they used to be protected by some other perimeter, be that a network perimeter or an endpoint perimeter. 

This has fundamentally changed as modern work applications are now directly exposed to the internet  - and the only thing needed to access these apps are identities. That means identities are now no longer the second or third target but the initial target, the new perimeter.

Securing the (identity) perimeter

To understand how we can protect this new perimeter, I’ll discuss the general approach to securing any perimeter, and then how this applies to the identity attack surface.

1. Map your perimeter

It’s impossible to secure what you don’t know about. Whether your perimeter is made of network services, user endpoints or identities, you must know what they are before you can implement controls to protect them, and crucially, verify those controls are effective.

In a traditional network setting, you might ask IT to inventory public network ranges, domains you own, and internet facing servers and services to get visibility into your attack surface. This is a pretty complex task and lots of the static inventory will quickly become outdated and incomplete. That’s why many orgs will perform network discovery activities to find internet-exposed network services, using anything from basic network scans to find onsite or self-hosted services to querying APIs in cloud infrastructure platforms (like AWS or Azure).

There are parallels in the identity perimeter space, like querying Identity Providers (IdPs like Entra/AzureAD or Okta) for federated identities to map the attack surface. Unfortunately there is no equivalent to scanning your public network ranges for identities, since you can’t scan or query an app to find accounts on your domain (would that we could!). This problem is compounded by the fact that while IT and developers are typically the only ones that can create and expose new network services, most apps allow any employee to create a new identity by signing up to a free account outside your SSO solution.

Knowing your perimeter without a technical solution is going to be a very hit and miss affair. To have confidence that you understand your identity perimeter, you need an inventory solution that can discover SSO identities (the easy part), as well as identities created outside SSO, like local accounts those employees created just by signing up. To secure identities it’s not enough to know that an employee is accessing an app website, you need to know if they are logged in and what identity they are using (is the username a company email or personal gmail?) or you’ll be dealing with endless false positives.

2. Reduce the size of your attack surface

Once you have an idea of what makes up your perimeter, it’s generally a good idea to make it as small as possible. If you halve the number of network services an attacker can target, that means you can spend twice as long per service to secure the ones that remain - the same goes for identities!

To start this process, remove unused or unnecessary targets from the perimeter. 

On a network perimeter that might mean:

• Shutting down unused servers or

• Firewalling services that don’t need to be exposed to the internet.

In the identity space, you might:

• Make sure new accounts use existing federated identities,

• Delete or disable unused SSO identities on your IdP, or 

• Manually delete unnecessary user accounts on work apps.

Manually deleting an unmanaged local identity on an app, e.g. after an employee leaves your org, is a (very) non-trivial task. This is because you often don’t known of the accounts and don't have access to manage the account (the IT or security team aren’t admin on the app tenant where it exists). You might have access to the user’s mailbox and be able to get access to the account by going through an account recovery flow and delete the account that way - but this is very time consuming and even more difficult if the user enabled MFA (which is what you want them to do!).

Given the difficulty of managing these accounts, a better strategy is to make sure they never exist in the first place. If you find you have lots of identities on an app you may decide the risk warrants IT effort and you can take over management of the app and integrate it with your IdP solution - or ask employees to use an alternative app instead. You can also use browser-based technical controls to prevent users from creating local identities in the first place.

3. Harden the perimeter

Once you’ve made the perimeter as small as possible, the next step is to make it more difficult to breach that perimeter. Similar to the other objectives, but especially here, there are two sides to this. First the implementation; you have processes, configuration standards, and tools to make sure network services are updated and securely configured. Virtually no one achieves success simply through implementing good processes, you must continually verify that these processes work and that it continues to work.

To verify network controls are in place and working you do something like vulnerability scanning, where you check the perimeter for known vulnerabilities that an attacker could exploit and gain a foothold on your internal network. You might even have a risk profile that means you are concerned about more targeted attacks and hire pentesters or run a bug-bounty program to find weaknesses that can’t be automatically discovered. Very few organizations with an external network of any significant size perform a vulnerability scan for the first time - even a low-quality automated one - and find no serious issues. 

In the identity space, the status-quo is to be content with making policies and implementing and configuring an SSO system without explicit verification that it works as it should. We should be following the same level of verification processes for the identity perimeter as we do/did for the endpoint and network perimeter. 

In this case, the vulnerabilities we are looking for aren’t unpatched systems or zero-days. Instead, we’re looking for:

• Accounts without MFA, 

• Those using weak MFA methods that make them phish-able,

• Employees re-using the same password across multiple accounts, 

• Passwords that exist in public breach dumps,

• Identities that should be in SSO but aren’t.

It’s not yet standard practice to test or verify that identity controls are in place, but if the past has taught us anything it soon will be. You'd be surprised how many times we find that the MFA policies security teams thought they had in place, actually aren't.

Part of the reason for this lack of verification is due to lack of awareness. While identities used to be an internal thing that we protected with the network perimeter, online identities today are external and have slowly become the perimeter, almost without anyone noticing. While online identities are external, they are absolutely part of your attack surface and must be controlled and hardened to some extent.

Verifying controls is also really difficult, which is another reason we may not be making it a crucial step in the process. Customers feel that SSO solutions are security solutions and using security tools on security tools feel wrong. But it’s no different to vuln-scanning to ensure your firewalls are patched and don’t have default passwords. 

Verification can also be legally challenging because it’s not yet clear whether pentesters or red teamers are allowed to target online identities during assessments. Often these assets aren’t considered in scope during client assessments. This means these vulnerabilities rarely end up in pentest reports and therefore don’t enter many organization’s security or risk management processes. Since you own the identities (even on a third party identity solution or app) and are allowed to grant permission to the red team to use these identities, it seems to me that adding identities to the scope is distinct from bug hunting or vulnerability research on these apps (which is the legally challenging aspect). I would strongly recommend that you discuss including online identities with the red team as part of your next pentest.

4. Limit breach impact

The unfortunate reality is that regardless of what we do to harden a perimeter, there will always be a chance that breaches occur. The goal is to reduce that risk by minimizing the attack surface and hardening identities. 

When an attacker does get a foothold (by compromising an identity, for instance) you need to to restrict their further actions. Risk involves both the likelihood and the impact of an event. Previously, we focused on reducing the likelihood of breaches. Now, we're also aiming to lessen the impact if they do occur.

In our network perimeter story, we might think of using a DMZ network to restrict network access for systems exposed to the internet. A common example of a failure to limit impact on a Windows endpoint breach is having service accounts on all endpoints with Domain Administrator permission - which effectively turns a breach of any endpoint very quickly into a breach of every endpoint.

In an identity context, we need to think not only of the direct effect of an identity compromise (e.g. what data can this account read), but also of further lateral movement attacks. Consider this Oktajacking case study where a breached identity with admin permissions on an otherwise low-risk app which is connected to SSO can be used to perform a SAMLjacking attack that compromises SSO credentials for all other users of the same low-risk app.

In contrast to traditional network or endpoint breaches, identity breaches are scoped to the permissions that the compromised account has. If an identity is compromised, whatever that identity is authorized to do is the scope of the breach. For example:

• If an identity with read access to a code repository was breached you might consider that all the source code (hopefully no secrets!) they had read access to was taken unless you can prove otherwise. This is often more difficult than you expect - last time I checked Github (by far the world's most popular source code repository app) logs didn’t include, for example, zipped repo downloads. 

• If an identity with write permission was compromised, you would also need to check all commits/changes to ensure no code was backdoored. The same applies for other apps - think of an identity with write access to a wiki being used to drop links to phishing pages.

For primary cloud collaboration platforms with complex data types (think O365 or Google Workspace) your IT team is likely already managing policies to limit the data that a user can read. For primary cloud hosting platforms your DevOps teams are likely maintaining policies to manage privileged access to production systems. The situation is typically very different for the few dozen high risk “core apps” beyond the 2 or 3 apps that receive a lot of attention and have dedicated teams.

Starting to review roles and permissions across the few dozen or so high-risk apps that are not as actively managed (or more likely self-managed by the teams using them) is a good way to start addressing the residual risk. The good news here is that most modern work apps use a much simpler permission model based largely around predefined roles like Owner, Admin, or Employee or similar variations. This means less flexibility, but also makes it a lot easier to manage permissions for identities on these apps - on balance, a good trade!

Consider this as part of your identity and access management review process. Something that used to be scoped around Active Directory group membership, but in a modern online identity context, now must be applied across many different work apps. 

Unless you want to try to get access to each tenant of each app and normalize this data into a mega-spreadsheet, you need access to this data in your identity inventory. This is an especially big challenge as teams find many of the apps they care about support authentication through SSO, but not authorization.

5. Detect and respond to attacks

Your last line of defense in protecting a perimeter is to monitor for attacks. It’s typically when controls and detections fail that breaches end in the news. 

Telemetry is the core building block of attack detection. Typically, you might ingest audit or event logs into a SIEM system. To detect attacks against identities, you’ll typically want to start with telemetry from SSO or IdP logs. These will provide some minimal coverage of many of the IT managed apps, but unfortunately attacks are more likely to happen on apps that aren’t SSO integrated, so we need a strategy to cover these as well. An identity inventory is a critical starting point to identify non-SSO apps from which you can collect event logs, as well as giving you visibility of the identities that are not covered.

Monitoring breaches for hosted work apps is different from other domains, largely because you are almost totally reliant on the app vendor to produce the telemetry. Unfortunately (I suspect primarily due to lack of customer demand), many apps don’t offer any centralized logging functionality at all, and those that do offer limited audit logs, or only do so on the top tier “enterprise” license plans. 

In the network or endpoint world, when you need more telemetry you have all the access you need to install software or hardware to generate that additional telemetry. You could put a network monitoring appliance in-line with your internet gateways or install an endpoint (EDR) agent to generate more telemetry than your router or endpoint OS will generate. You can add a proxy in front of an app for your users, but (except for a very small number of highly configurable apps) you can’t make attackers go through your proxy.

What you can do, however, is generate additional telemetry on what happens to your employee’s identities in the browser. This is possible through browser extensions which can be managed through the enterprise management features available for all mainstream browsers (Chrome, Edge, Firefox, Safari, Brave etc. etc.). This is incredibly powerful, and useful in directly detecting a range of identity attacks like phishing (is an employee trying to enter an SSO password into an app that isn’t the SSO login page?), but also through correlations with existing application or IdP logs that indicate account takeover (e.g. has there been a login event that wasn’t observed through the employee’s browser as well).

Same, but different

Whether we’re looking at the Verizon DBIR or just keeping up with security news, it’s clear that identity-based attacks are already responsible for a significant number of breaches. Attackers have started shifting their focus and security teams need to recognize this shift and adapt.

This doesn’t require that we fundamentally rethink security or anything that radical, just that we apply what we’ve learned over the last couple of decades to this new domain. There are some new technologies and protocols to understand, new tools are needed, but the fundamentals like authentication and authorization are already familiar to any security professional. 

If you follow what I’ve outlined here, a lot of the decisions we’ve made with building Push will make perfect sense. For example, you can’t make API integrations with apps to find identities when you don’t know about the apps or identities yet, so we needed a unique new data source. We use our own custom-built browser extension that’s force-deployed to your workforce, so we can observe employee identities as they are used in the browser. This gives us some pretty unique capabilities. If you found this interesting, follow us on Linkedin for more detailed blogs as we unpack this topic.