SolarWinds, Uber, Okta, and far more than there is room to list here.
All of these organizations have been the target of identity-based attacks in recent years as adversaries shift their focus to targeting the identity layer as their preferred route to a fast and beneficial pay day.
Securing identity, and the assets that those identities have privileges to access, is increasingly difficult.
But why?
The Identity Security Challenge
Each service they use, whether it be AWS, Azure, Salesforce, GitHub, or one of the literally hundreds of other business critical apps and services in use by modern organizations, has its own proprietary identity management configuration.
The lack of standardization and sheer complexity of the identity and access management (IAM) space means that security teams are finding it next to impossible to gain clear visibility over who has what kind of access to which assets, and perhaps even more importantly, what actions they are taking with their access.
The massive proliferation of cloud and hybrid apps and services across the organization has only served to make a painful problem worse. According to the independent Identity Defined Security Alliance’s (IDSA) 2023 Trends in Securing Digital Identities report, 52% of respondents reported that the adoption of more cloud applications was responsible for the increase in identities, beating out remote work (50%) and additional mobile devices (44%).
More apps and services means more identities, which in turn equals an ever expanding threat surface filled with opportunities for attackers to gain a foothold in your organization with control over legitimate credentials.
Once they can leverage those credentials to gain additional access, it’s not a far jump to escalate privileges and reach even more sensitive, valuable assets.
And identity-based attacks are a problem for organizations across the board. Last year, 84% of organizations reported having experienced an identity-related breach over the course of the last 12 months according to the IDSA in their 2022 Trends in Securing Digital Identities report.
The Costs of Identity-based Attacks
The impact of this disturbing state of affairs is apparent in the numbers.
In IBM’s Cost of a Data Breach Report for 2023, we see the cost to organizations in dollars and cents. Take the two most common, though hardly the only, identity-related issues to get a sense of the impact.
Incidents of Stolen/Compromised Credentials comprise 15% of data breaches, costing an average $4.62M per case. Only phishing hits orgs more, with a slim margin of 16%. While less frequent at 6%, Malicious Insider cases are the most costly at an average of $4.9M.
These can equal up to sizable losses for an organization as it spends time responding, recovering, and restoring its reputation after an incident.
So given all these obstacles and negative outcomes, what are security teams supposed to do to keep from being a victim of an identity-based attack?
Identity Risks Explained
As G.I. Joe taught us, knowing is half the battle.
Protecting your organization against these attacks starts with understanding the risks and threats facing your identities.
To this end, we have here below 12 of the most common identity-based risks and threats that you should be aware of in 2023. You can find here explanations of
- What the issues are
- Best practices for remediation
You can skip to any of the risks here:
- Compromised Credentials
- Excessive Privileges
- Partially Offboarded Former Employees
- Contractors Retaining Access
- MFA Bombing/Fatigue Attacks
- Corporate Account Takeovers
- Privilege Escalation Paths
- Machine Identities / Service Accounts
- Access via Nested Groups in Azure
- Misconfigurations in IdPs
Compromised Credentials
What is the Issue?
Credentials are how we log in to our apps and services, usually in the form of a username and password. Our credentials can be stolen by methods like stealing databases, credential harvesting malware, or phishing.
The 2023 IDSA report found that brute force attacks like credential stuffing and password spraying were behind 31% of identity-related incidents, coming in second behind phishing. Add to this that 28% of breaches came from compromised privileged identities, and the problem really comes into focus.
Best Practices
- Use MFA to add an additional layer of protection, making the hackers work harder to breach your systems. Ideally use an app or FIDO-based MFA and not SMS, though SMS is better than nothing at all.
- Use threat intelligence to detect when your credentials pop up on a dark web marketplace or forum
- Alert impacted users to the need to change their passwords
- Log them out of sessions to avoid hijacking
- Consider passwordless as part of a future strategy
Excessive Privileges
What is the Issue?
An identity without privileges is not all that interesting. It is once that identity has access to assets and the ability to impact them that they become valuable.
This violates the Principle of Least Privilege which calls for identities to have just the privileges they need to fulfill their functions. No more, no less.
Every privilege is another opportunity for mischief and malice. They widen our threat surface and open more doors to bad actors to access our assets.
Best Practices
- Mitigate our risk by minimizing our identities’ reach in line with the Principle of Least Privilege
- Monitor usage and remove privileges that have not been used after 30/60/90 days
- Perform periodic user access reviews to assess validity of privileges, revoking where possible
Partially Offboarded Former Employees
What is the Issue?
When an employee leaves the organization, their identity may still retain some of their privileges to your assets.
This can happen because we often do not have the full picture of the identity and their assets. A common example is that they may be offboarded via Okta, but still have access to M365 or have privileges granted via Entra ID (formerly known as Azure AD).
Best Practices
If you lack a solution like Authomize with comprehensive security visibility over all your identities, access privileges, assets, and access privilege activity, then you’re going to have significant difficulties here.
Some steps that you can take are to:
- Avoid using local users
- Perform user access reviews
Contractors Retaining Access
What is the Issue?
Modern organizations rely heavily on external parties, and as such grant them access to various resources and assets.
This is all fine and good, but the challenge is that contractors’ identities are not managed by your organization. This can cause significant visibility challenges that make it hard to know if they retain access to specific assets just by looking at your Otka or Entra ID.
Moreover, you run additional risk if the 3rd-party contractor is hacked and then someone uses that unmonitored access to attack your organization.
Best Practices
- Use solutions that can monitor not only identities and access privileges in your own IdP, but also detect all access pertaining to your assets. Think about it as “Not just who can access what, but what is accessible by who.”
- By following the access privileges and their usage, you can detect external access, even if you lack the direct control over their identities.
MFA Bombing/Fatigue Attacks
What is the Issue?
In a case of “it’s not stupid if it works”, some hackers have taken to overcoming Multi-factor Authentication (MFA) by simply annoying the person whose account they are attempting to take over into approving the request.
Usually this happens after the attacker already has their target’s credentials. When faced with the MFA challenge, which should be enabled, they need to either take control of the users’ MFA with a SIM swap for low level authentication, or get them to approve by bombarding them with a stream of requests.
This worked in the Uber hack where the Lapsus$ crew hit the contractor, making their way over to the company’s VPN and forward to glorious infamy.
These attacks highlight some of the inherent weaknesses of MFA, reminding us that it is far from infallible. Strong authentication is a good start, but securing your environments means adding layers of protection post-auth with powerful control over your authorizations.
Best Practices
- Turn MFA on for all users
- Monitor for attempts to bombard users with requests
- Monitor for massive failed attempts to login to your cloud apps
Corporate Account Takeover
What is the Issue?
If an attacker compromises credentials and gets past your MFA, not a difficult feat as we have seen over and over again, then they can successfully takeover the targeted account in your organization.
They can use these privileges to directly access their targeted data and systems, or work their way laterally and try to escalate to higher privileges.
Best Practices
- Reduce privileges to mitigate risk when an account takeover happens
- Monitor for threat intel on compromised credentials
- Use automated responses to close the window of opportunity for attackers, ie. alert users to change passwords and log them out of sessions
- Push identity contextual data insights to conditional access products to add appropriate levels of friction for logging into applications
Privilege Escalation Paths
What is the Issue?
Sometimes the access privileges associated with an identity are not enough for a malicious actor to get where they want to go.
Privilege escalation paths are the variety of ways, often unintentional misconfigurations or provisioning of privileges, to allow them to reach assets that would otherwise be out of reach.
A classic example here is role chaining. In your Okta, you can see that an identity can assume “Role A” in AWS. But what you cannot see is all the roles that Role A can assume. You do not know what Roles B, C, and D can later assume and what they can access.
Best Practices
- Attain visibility of an identity’s blast radius (effective access of what they can access) across environments
- With a full mapping of effective access, including for access gained via groups, revoke all additional access paths
- Monitor for shadow admins that can pose unidentified risks
Machine Identities / Service Accounts
What is the Issue?
Estimates put the ratio of human to machine identities somewhere in the vicinity of 1:10, making them increasingly concerning for many organizations as they work to figure out how to protect these identities.
These accounts are a favorite of hackers because they while useful, they have a number of different challenges, including:
- Organizations often lose visibility over these identities
- They do not have MFA
- Often over-privileged
Add to this the fact that these identities are generally used in infrastructure (IaaS) where they can cause significant damage to sensitive areas like production environments or databases if compromised.
Best Practices
- Detect all machine identities in your environments
- Right-size their privileges in line with PoLP
- Monitor them for signs of compromise (suspicious activity)
Access via Nested Groups in Azure
What is the Issue?
Groups are the correct way for managing privileges, granting the privileges to the groups and then moving the identities to the proper groups to gain the right privileges.
The problem is that often identities can gain additional, unintentional privileges by their group being a part of another group, granting them potentially excessive and risky access.
This access can be hidden from view and not obvious in Entra ID or Active Directory, adding to the risk.
If you do not understand the blast radius/effective access of an identity, then you are likely going to miss this access.
Best Practices
- Get a handle on identities’ effective access
- Remove identities from groups that pose additional security risks
- Adjust groups accordingly, de-nesting as needed
- Monitor for suspicious activity
Misconfigurations in Identity Providers
What is the Issue?
We are only recently starting to think about identity as its own type of infrastructure that needs to be defended.
This is because attackers like in the cases of SolarWinds and Lapsus$’s attack on Okta show that smart money goes after the systems that control the identities and access, granting them access to all of the downstream applications managed by the Identity Providers like Okta or Entra ID.
And like all other kinds of infrastructures, Identity Providers (IdPs) can be misconfigured. Examples include settings that allow for:
- Clear text credential dumping in Okta
- User impersonation in downstream applications
- More that you can read about in our blog
Best Practices
- Use an Identity Threat Detection and Response (ITDR) solution, the only solution for effectively monitoring your identity infrastructure for misconfigurations and active threats
- Monitor for suspicious activity in the IdP like changes to privileges, creation of new admins, or other IoCs
- Stay tuned for more research into IdP misconfigurations
What Did We Miss?
Did we miss a top-level identity security issue here that should be included in the next blog?
Better yet, reach out and have a chat with us about your organization’s identity security challenges.