Midyear Updates
Trends
Adversaries abusing identities
We’re not the first to say it, and we won’t be the last: identity is the new perimeter. This perhaps overused phrase is becoming cliché for a reason–it’s unquestionably true for most organizations, particularly those with a large cloud footprint and which leverage numerous SaaS applications. This sentiment is a driving force behind the burgeoning identity threat detection and response (ITDR) sub-industry. To that point, one sufficiently privileged identity can offer an adversary access to countless cloud systems, SaaS applications, or even the identity product itself. Even a less privileged identity—when it’s not inherently valuable as a target for internal reconnaissance or espionage—can serve as a beachhead for an adversary to conduct internal phishing or otherwise move laterally to a more privileged one.
Compromised identities have been a central component of countless costly breaches this year. Looking purely at Red Canary’s detection data, three of our top 10 techniques from the first six months of 2024 are cloud-native techniques that relate directly to identity: Cloud Accounts, Email Forwarding Rules, and Email Hiding Rules
Identities are arguably among the most important assets for enterprise security teams to secure, and although there are many security solutions are capable of effectively fortifying identities, these can be complex, expensive, and prohibitively difficult to implement.
In this section, we will explore:
- common identity threats and techniques
- organizational and IT problems related to identity
- strategies anyone can follow to harden their identity perimeter
How adversaries compromise identities
Stolen credentials and tokens
There are innumerable ways for an adversary to steal valid credentials that they can then use to gain access to identities and valid accounts. Some common methods include:
- Credential-stealing malware
- Phishing
- Credential stuffing
- Password spraying
- Vulnerability exploitation
Adversaries also frequently target session tokens in order to gain access to identities. Methods of token theft include wide varieties of social engineering like adversary-in-the-middle (AitM) attacks or attacks in which adversaries otherwise leverage malicious applications to gain access to cloud-hosted systems and services (more on this below).
Adversaries can also steal tokens after compromising a cloud account or service. In Amazon Web Services (AWS) particularly, sufficiently privileged adversaries can extract short-term security token service (STS) tokens from Elastic Cloud Compute (EC2) instances by targeting the EC2 Instance Metadata Service (IMDS). This service contains tokens associated with the roles granted to an EC2 instance, which an adversary can steal and potentially leverage to perform actions within the same cloud tenant.
Multi-factor authentication (MFA) abuse
Organizations that enforce MFA across their cloud accounts and SaaS applications significantly complicate adversary attempts to compromise identities. However, there are various methods of overcoming MFA. MFA fatigue attacks—where an adversary obtains legitimate credentials and then bombards their victim with MFA requests—are among the simplest of these.
Adversaries also leverage AitM attacks to bypass MFA, by setting up a website that looks like a legitimate login page and luring the victim into entering their credentials into it. The adversary relays those credentials in real time, often cloning the login details of the captured session and attempting to log into the legitimate account, before presenting the victim with a secondary webpage in which to enter their MFA code. If the victim uses push notifications, then the secondary page may not be necessary. AitM attacks are commonplace and numerous AitM toolkits lower the barrier of entry for adversaries conducting AitM attacks.
Other common tactics for bypassing MFA include adversaries reaching out to help desk technicians or mobile service providers in an effort to conduct SIM swap attacks or even register their own MFA devices. Help desk social engineering, SIM swaps, and other techniques for resetting an MFA device are also crucial for adversaries to establish persistence, since tokens gleaned from an AitM or similar account takeover are short lived, and the adversary will need to bypass MFA again in short order to maintain access to their victim’s account.
Role and application abuse
Adversaries also abuse application access and role assignments to gain access to identities. Application consent phishing and device code phishing are two examples of this. Application consent phishing involves an adversary registering a malicious application and then tricking their victim into granting it permissions that will allow the adversary to access systems and data within their cloud environment and potentially beyond. Device code phishing, on the other hand, abuses the OAuth 2.0 Authorization Framework specification, which allows devices without browsers (such as TVs or internet-of-things devices) to authorize themselves on behalf of users. In this case, the adversary requests a user code from the cloud or identity provider that will offer certain permissions to their own malicious application. They then send that login link to the victim, who may unwittingly login and grant permissions to the adversary-controlled application.
How adversaries leverage compromised identities
Business email compromise (BEC)
BEC remains a clear frontrunner among identity-centric threats—let alone threats in general. In fact, two of the top 10 techniques we detected in the first six months of 2024 are driven largely by BEC-related activity:
- Email Forwarding Rules
- Email Hiding Rules
We discussed both techniques in the Email Forwarding Rules section of the 2024 Threat Detection Report, as the line between these two techniques is blurry and subject to interpretation. Both schemes typically involve an adversary compromising an email account and using it to monitor communications and/or surreptitiously communicate with the victim’s contacts—often a contact that engages in financial transactions with the victim, such as a vendor or a payroll department. Email forwarding incidents may involve routing emails to an external or internal email address. Adversaries often attempt to hide their communication by creating a rule to forward emails from a particular sender to an email folder that the victim is unlikely to open. Alternatively, we also often see adversaries simply marking messages as spam, blocking senders, or otherwise hiding email messages. The ultimate goal of these attacks may be to reroute payments from legit bank accounts to accounts controlled by the adversary, reconnaissance, or espionage.
Other post-compromise activity
Outside of BEC, much of what an adversary does once they compromise an identity is procedural. They’re merely using the identity to support whatever their ultimate objective is, which could range from cryptocurrency mining to ransomware to espionage and include essentially anything in between. Some activity to be aware of includes:
- backdoor and abusing OAuth apps
- additional credential stuffing, password spraying, and brute forcing
- internal phishing
- reconnaissance for passwords or other valuable information
- resetting victim passwords
- adding new MFA devices
- third-party account creation
- adversary service creation
- consenting to new applications
- OAuth Illicit consent grant
- privileged role assignments
- reconnaissance of directory users and applications
Identity challenges
As we noted earlier, many of the prominent threats and risks organizations face in the identity space are mitigatable via controls that are available to most organizations. Unfortunately, these controls can be complex to implement in practice, particularly at scale. As such, we will list some of the challenges that organizations might encounter as they attempt to fortify their identity infrastructure.
MFA adoption
Implementing MFA across an organization presents numerous challenges.
For one, an organization needs dedicated technical staff capable of actually setting up and enforcing MFA. Further, MFA requires third-party devices—often mobile devices or additional IT equipment—to work. As such, an organization either needs to allocate budget to procure these devices or it must assume that employees have access to their own mobile devices that they are willing to use for MFA. This effectively creates a de facto bring-your-own-device (BYOD) policy that can have a wide variety of knock-on consequences that may discourage the adoption of MFA. Further, this doesn’t even account for scenarios where employees may not have personal devices, may be unwilling to use them for work, or may lack the technical savvy required to use MFA.
Additionally, some organizations have multiple workers leveraging shared accounts and devices. Think of a convenience store chain where employees use a shared account to access the point-of-sale terminal. How does an organization set up MFA for this kind of shared account?
Permission sprawl and dangerous role assignments
Permission sprawl is another problem that many organizations may face in the identity space. Maintaining an inventory of users is challenging on its own, but understanding the permissions granted to those users—and the implications of different permissions across different tools—is immensely complex. Similarly, organizations must understand role assignments since it’s easy to assign overly permissive or privileged roles to applications.
Beyond understanding permissions and roles, it’s worth considering the trustworthiness of the applications you grant these roles and permissions to. Taking Microsoft Azure as an example, an application from the Azure Marketplace might be reasonably trustworthy whereas an application from elsewhere might deserve more scrutiny. Similarly but on an individual level, you might be willing to grant full read-write permissions from Microsoft Exchange to the Apple mail client but not to some lesser known calendar orchestration app. Take this simple example and expand it out across all the users and applications in a given organization to understand the scope of this challenge.
Alert overload
Most identity and cloud providers will generate alerts for suspicious login activity. Unfortunately, these alerts can be extremely voluminous, particularly for remote workers, people who are working while traveling, and large enterprises, especially ones with complex internet gateways. The criteria these providers apply in determining that a login is suspicious can be based on anomalous characteristics of the logon as defined by the vendor itself, but an anomaly in a login is not necessarily malicious or even suspicious. As an example, if an alert tells you that a user logged in from an unusual location or IP space (and that’s all it tells you), how do you know whether or not that login was malicious or benign? Many identity providers generate unmanageably high volumes of false positive alerts, discouraging security teams from investigating suspicious logins, even when the logins are successful.
Identity solutions
For all the risks and challenges associated with identity, defenders can choose from a wide array of solutions available for improving identity security.
MFA
Implement and enforce MFA as far and as wide as possible. If feasible, implement phish-resistant MFA, but any MFA is better than none.
Conditional access policies
Conditional access policies effectively allow administrators to permit or deny access to a resource based on attributes of the login. For example, you can use conditional access policies to deny access to resources from unmanaged devices or require that devices use MFA to access a resource. Implementing these to whatever extent is possible across your identity infrastructure can mitigate a wide array of identity risks arising from improper configuration, implementation, and elsewhere.
Passwordless solutions
Passwordless solutions like hardware tokens, hardware-based authentication devices, biometrics, and more that require a user to plug a keycard or USB fob into a device—or prove their identity via a biometric measure—make it extremely difficult for an adversary to compromise an account. Unfortunately, these phish-resistant solutions can be hard to implement and administer. However, implementing them on a smaller scale, for example if you only want them to protect your most secure identities (e.g., your Okta admin accounts), can be much more manageable and significantly shore up the security of your identity infrastructure.
Short-term access
AWS STS and privileged identity management (PIM) for Microsoft Entra ID are great examples of short-term access, although similar technologies likely exist across other cloud and identity providers. Short-term access allows organizations to issue short-lived tokens that grant temporary access to resources in lieu of long-standing permissions or credentials for users or roles. Tokens only last for a matter of minutes or hours, limiting the amount of damage an adversary can do with a stolen token. Further, since these tokens are generated dynamically and not stored by the user, they are phish-resistant and difficult to steal.
Identity threat detection and response (ITDR)
ITDR solutions collect telemetry from your identity, cloud, and other IT infrastructure and perform detection and response specifically for identity-related activity. This can include looking for logins occurring from unusual VPNs but also enriching identity telemetry with related signals from other tools like endpoint detection and response (EDR), user entity behavior analytics (UEBA), certificate information, and more.
The following graphic demonstrates the identity threat detection workflow that we’ve found most effective at detecting threats across our customers’ identities.