Trends

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.

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

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.