A pivotal shift from perimeter-based security measures is being witnessed in the rapidly shifting landscape of cybersecurity. Identity management is becoming more complex with the move to the cloud, calling for a thorough re-evaluation and fortification of existing security frameworks. Threat detection and response mechanisms must be recalibrated as the narrative of identity compromise unravels at an alarming pace.
Here is your guide to identity-centric security challenges, showcasing real-life breach examples and introducing innovative frameworks that will allow you to:
- Examine recent high-profile breaches where compromised identities are the common denominator.
- Recognize how identity-related security challenges increase with the shift to cloud environments, moving away from traditional centralized identity management.
- Highlight the limitations of traditional detection methods.
- Transform threat detection by applying tactic, technique, and procedure (TTP) mappings to cloud and Identity and Access Management (IAM) infrastructures.
- Reveal a framework that acknowledges and prepares for identity threats across various clouds, establishing a foundation for a strong identity-centric security paradigm.
100% of Breaches Involve Compromised Identities
User and machine identities, access privileges, trust relations, and credentials have been threat actors’ prime targets for over a decade. A brief overview of the Verizon 2023 Data Breach Investigation Report (DBIR) and all previous ones is enough to determine that identities are the number one target for security breaches. This problem has quadrupled with organizations’ transition to the cloud.
If you’ve read the security news in the past 12 months, you probably noticed high-profile breaches at MGM Casinos, Uber, Sony, Okta, Microsoft, and many other organizations that were not published to the public. The root cause of all those incidents is compromised identities.
In the on-premise world, most identities were managed in a single directory, such as the “Active Directory,” allowing for more straightforward and less complex management despite higher risk as a “single point of failure.” In the on-prem world, threat actors tried to compromise and steal identities and their credentials through the Endpoints and through targeting the Active Directory itself.
Well-known tactics, techniques, and procedures (TTPs), such as the usage of variations of the Mimikatz tool, as well as novel methods to execute pass-the-ticket (PtT) and pass-the-hash (PtH) techniques were researched and investigated by security professionals worldwide. Other detection techniques included incrimination of outbound network traffic to well-known malicious addresses (IPs and Domains) to identify a potential Identity breach.
As we evolve to the next phase of identity evolution, we need to be able to answer the following:
- How do we prevent identities from being breached?
- How do we detect and respond fast enough when identity credentials are lost or compromised?
- How do we make sure identity privileges won’t be abused?
- How do we ensure that the complex trust relations between the various platforms will not be taken as a vantage point by hackers?
Once you hack this, you hack it all.
The Cloud Changed Everything
When organizations transition to the cloud, it most notably impacts the identity architecture. Transitioning from a centralized Identity management to decentralized identity management. From a “single source of truth” to multiple sources of truth, some have trust (or federated access) between them, and others are completely managed separately.
An average organization has more than three Identity management platforms across SaaS, Identity Providers, and Cloud Infrastructure providers. In addition to the distributed management and complex architecture, the cloud also made everything publicly accessible – in the past, organizations trusted their perimeter and had some idea of which interfaces and “login screens” were internet-facing. For cloud-first organizations, everything is publicly accessible.
Every login interface is open for everyone to try and log in to SaaS applications such as Salesforce, M365, GitHub, and Snowflake; Cloud providers (IaaS) such as AWS, Azure, or GCP; and identity providers (IdPs) such as Okta, Azure AD or Google workspace.
The perimeter is dead, there are no boundaries, and the barrier to identifying a specific organization’s login interface in Okta, Azure AD, or Google is pretty low and depends on how well someone can search the internet.
In addition, the authentication and authorization methods changed drastically, and no longer rely on protocols such as NTLM or Kerberos, but are REST API based and fully documented so that every threat actor could try and abuse those APIs.
Looking for malware or tool signatures is no longer relevant, and the detection and prevention techniques must change.
A quick example that showcases that the traditional threat detection approach is insufficient is the recent MGM Resorts data breach, which allegedly started on September 7, 2023, and was detected by MGM Resorts on September 29, 2023. The breach involved:
- A complex series of events.
- Leading to significant data exposure and operational disruptions.
- Causing a financial impact estimated at around $100 million.
Potential attack flow of the MGM Resorts breach
“Hackers don’t hack, they mostly login”
Identities in cloud environments are the connective tissue between different systems, and the “connection” between those systems is done via APIs and trust between different IAM platforms.
Most of those systems and APIs require authentication (if not, that is a significant problem that needs to be addressed ASAP). This leaves attackers focused on identity takeover with two options to breach an organization:
- Try to abuse \ exploit those APIs and bypass their authentication
- Steal an identity’s credentials and leverage those credentials for further lateral movement and privilege escalation
Option #1 requires high sophistication unless there are known vulnerabilities that were not patched. In that case, the initial access through the vulnerable asset shouldn’t be too complex. Either way, getting from the exploited asset to the asset the threat actor desires (the crown jewel) will still (most likely) require a stolen identity to get there.
Option #2, on the other hand, doesn’t require high sophistication but more consistency and access to stolen credentials DBs or relevant people like Admins or users of the targeted companies (as demonstrated in the past by Lapsus$ and SCATTERED SPIDER\ Roasted 0ktapus\ UNC3944). Once a threat actor can access legitimate, stolen credentials, they have a “Golden ticket” (pun intended) and paved road to critical assets and sensitive information. With legitimate identity being stolen, detecting malicious activity is becoming increasingly challenging and near impossible.
The new paradigm is that the defenders’ life is getting much more complicated and requires very strong technical skills across many technologies, while the skills required to breach an identity is some “Tor” magic, some spare cash, or just consistent brute forcing \ Password spraying & Email scraping from Linkedin coupled with an organization’s Okta or Azure AD login interface.
A Complex IAM Landscape Requires a New Detection Approach
Due to the increasing complexity of cloud IAM (Identity and Access Management) platforms and the relationships between them and different authentication and authorization protocols, a new approach to detecting malicious activity vs. benign activity is needed.
In the on-premise Endpoint world, many detection engines relied on atomic indicators (IOCs) such as IP addresses, File hashes, Domain names, specific strings in a command line, or file metadata (e.g., string analysis).
There are even more advanced techniques. Some might call Behavioral indicators (IOBs) looking to inspect specific OS-level API calls or process execution tree analysis to determine if the executed program is malicious or not.
Those methods are not enough in a “multi-threaded” API world. Using one or even both of those methods isn’t enough, as one identity can generate millions of API calls daily across multiple cloud & SaaS services.
The new approach needs to include the following detection building blocks
- TTP mapping & adjustment to cloud infrastructure, SaaS Apps, and IAM infrastructure
- Statistical analysis of identity activities (e.g., UEBA) & profiling
- Blast radius analysis and access map calculating the access trusts between different IAM infrastructures
- Exposure of an identity (how susceptible it is to be exploited \ compromised)
- Known IP & Domain block lists \ TI
Note: It is crucial to correlate and aggregate 3rd party vendor indicators (such as Okta, AWS, and AAD) to reduce friction and redundant alerts.
Market Maturity
We’ve gone a long way in researching and investigating various tools and techniques for stealing credentials and bypassing authentication mechanisms on-premises.
Frameworks like the MITRE ATT&CK have been developed to help map the different TTPs used in the attack lifecycle.
Unfortunately, we are not as close to having that level of understanding and knowledge of the cloud. The cloud and its trust relationships are entirely different from the on-prem world and require a different approach to prevent, detect, and respond to Identity threats.
Rezonate has developed an equivalent to MITRE ATT&CK framework to address Identity-related threats in the cross-cloud world. The goal of this framework is to help organizations to understand better and prepare for identity threats.
Most of those TTPs rely on legitimate actions and events across the different platforms.
MITRE Framework For ITDR
Frameworks like MITRE ATT&CK have been invaluable for understanding on-premise threats. However, the cloud presents a different set of challenges that are not fully addressed by existing frameworks.
Rezonate Identity ATT&CK Framework
Rezonate has developed a framework specifically designed to address identity-related threats in a multi-cloud environment. This framework aims to help organizations better understand and prepare for the evolving landscape of identity threats. It covers various TTPs that rely on legitimate actions and events across different providers, offering a comprehensive view of potential vulnerabilities.
Rezonate is proud to share this framework with the security community and embrace an identity-first approach to threat detection and response:
The Rezonate Approach
At Rezonate, we practice what we preach, and we are committed to developing a cutting-edge ITDR Platform that will reduce the mean time to detect (MTTD) and mean time to respond (MTTR) to identity threats in real time.
Have you ever wondered how a breach starting from an Identity provider (e.g., Okta or Azure AD) could progress into business-critical assets such as production cloud infrastructure (AWS) or Data warehouses (Snowflake) containing PII?
How can you stitch it all together into a single attack flow in real-time?
Track which configuration changes happened when a compromised identity changed the access policy of a blob or a bucket. Or maybe a compute resource?
How about a compromised identity reading significant amounts of data from various databases all at once and doing it from a completely foreign location to where this identity usually resides?
How about a compromised identity accessing a business-critical SaaS application (Salesforce, Hubspot) containing all of your revenue information and customer data?
Those scenarios and the threat detection approach that is outlined in this blog have been developed for several months by Rezonate labs, and we are proud to present what a cross-correlated, behavioral & profiling based, access and privileges risk-based cloud identity threat looks like in one shot or 200 words:
1. The attack was initiated by a “Malicious Actor.” The attacker is trying to gain initial access through brute force vectors. The attacker has targeted Barb W, an employee at Trexony.com who owns the Email address “barb.w@trexony.com.”
2. Initially, the “Malicious Actor” has several unsuccessful attempts at a brute force attack.
3. A few minutes later, the attacker successfully gains initial access using brute force methods.
4. After achieving initial access, the attacker seems to move laterally, trying different avenues:
- SSO Azure AD to Snowflake: The attacker gains access to Snowflake using Single Sign-On (SSO) credentials from Azure Active Directory (AD).
- SSO Azure AD to AWS: Another lateral movement involves utilizing the Azure AD SSO credentials to access AWS resources.
5. Data Exfiltration:
- Within Snowflake, the attacker is querying large amounts of data.
- Data is exfiltrated (or stolen) and uploaded to a publicly accessible S3 bucket that the attacker made public (it was private before).
6. Storage Enumeration Attack: The attacker is also attempting a storage discovery or enumeration attack, possibly trying to identify more data storage or resources, through which he enumerates:
- QLDB Resources
- RDS Resources
- S3 Resources
Try Rezonate today to assess your organization’s identity risk!
