To combat the growing threat of identity attacks, organizations need to adopt a proactive approach that goes beyond traditional security measures. Identity Threat Detection and Response (ITDR) is one such approach that focuses on monitoring and responding to suspicious activities related to user identities and access management. ITDR solutions can help organizations spot unusual patterns, such as multiple failed login attempts, access from unusual locations, or abnormal behavior within the system.
The Cross-Tenant Impersonation Attack
To better understand the Cross-Tenant Impersonation Attack that MGM and other hospitality/casino groups fell victim to, we need to delve into the specific Tactics, Techniques, and Procedures (TTPs) used by these attackers. These TTPs were identified by the Okta Security team, shedding light on the methods employed to compromise highly privileged roles within Okta customer organizations. These attacks, marked by a high level of sophistication, involve novel approaches to lateral movement and evasion of defense mechanisms. Essentially, once the attackers gain access, they exhibit an ability to navigate freely while adeptly concealing their tracks.
Understanding the TTPs used
One of the primary objectives of these attackers is to target and compromise Okta Super Administrator accounts. Through this, they exploit legitimate identity federation features, enabling them to impersonate users within the targeted organization. To effectively defend against these attacks, it’s essential to understand these TTPs in detail and leverage useful audit logs that can serve as valuable resources for building robust security detection rules. This proactive approach will help organizations enhance their defenses against such sophisticated threats.
Social Engineering
As attackers have escalated their sophistication in conducting convincing phishing campaigns, it becomes crucial for Okta administrators to enhance their ability to detect such campaigns. Leveraging existing technologies like Okta FastPass becomes essential in this context. FastPass offers a zero-trust authentication solution that aims to reduce end-user friction while maintaining strong trust in both user identities and devices. To improve phishing detection, Okta administrators can execute the following System Log query, allowing them to gain insight into instances where Multi-Factor Authentication (MFA) failures may indicate a potential phishing attempt:
eventType eq "user.authentication.auth_via_mfa" AND result eq "FAILURE" AND outcome.reason eq "FastPass declined phishing attempt"
Code language: Perl (perl)Understanding how to interact with Okta event logs allows users to easily construct similar rules in Sysdig, using the open-source Falco rule logic. For example, here is a rule that was crafted to detect potential Okta phishing attacks:
rule: Okta FastPass Phishing Attempt
desc: Detect a phishing attempt using FastPass
condition: okta.evt.type = "user.authentication.auth_via_mfa" and okta.result="FAILURE" and okta.reason="FastPass declined phishing attempt"
Code language: Perl (perl)Anonymization
To conceal their activities, the attackers accessed compromised accounts through anonymizing proxy services, using IP addresses and devices not previously associated with the user accounts. Of course we could detect when an inbound or outbound connection is made to those anonymization feeds. Using Sysdig, users can construct their own security rules for Okta to detect suspicious inbound or outbound connection attempts to anonymous IP feeds:
- rule: Okta Suspicious IP Inbound Request
desc: >-
Detect inbound requests from known suspicious IP sources, such as TOR exit
Nodes and anonymization proxy services, to Okta services.
condition: okta.client.ip in (ti_anonymous_ips) and okta.result="PASS"
output: >-
Suspicious IP Inbound Request (okta.client.ip=%okta.client.ip,
okta.target.user.name=%okta.target.user.name,
okta.useragent.raw=%okta.useragent.raw, okta.app=%okta.app)
priority: CRITICAL
source: okta
Code language: Perl (perl)From there you would simply need to populate the ti_anon_ips macro with the IP’s specified in Okta’s Indicators of Compromise (IoC) disclosure. In the long run, this would require a managed security approach to updating those anonymization feeds, an approach which is currently continuous assessment from security teams. An alternative approach would be to alert specifically on any sign-in attempt via those anonymization proxies, as seen in the below system log queries.
eventType eq "user.session.start" and securityContext.isProxy eq "true"
Code language: Perl (perl)In the case of the recent MGM impersonation attacks, the threat actors accessed the administrator accounts with anonymized proxy services and used them to reset authenticators and assign higher privileges for other accounts. Based on our knowledge of the Okta audit logging service, and the Falco rule logic, a rule can be constructed specifically to detect Okta sign-in attempts via a Proxy service.
rule: Okta Sign-in via Proxy
desc: Detect a successful Okta sign-in via a proxy
condition: okta.evt.type = "user.session.start" and json.value[/securityContext/isProxy] = "true" and okta.result = "SUCCESS"
Code language: Perl (perl)Privilege Escalation
Compromised Super Administrator accounts were used to grant higher privileges to other accounts or reset enrolled authenticators in existing administrator accounts. In some cases, the threat actors even removed second-factor requirements from authentication policies.
However, it’s worth noting that there are no System Log events for a Factor downgrade. To monitor all activation and deactivation events, you would need to run the following query in Okta:
eventType sw "system.mfa.factor"
Code language: Perl (perl)As a best practice, users can detect when all forms of MFA are removed from a user account, therefore indicating a potential account takeover attempt while indicating to the Incident Response and Forensics teams which Okta actor name was responsible for making these changes. A rule can be configured to identify MFA removal based on the above Okta event type.
rule: Removing MFA from Admin in Okta
desc: Detect removing MFA on the Admin in Okta
condition: okta.evt.type = "system.mfa.factor.deactivate"
Code language: Perl (perl)Impersonation App
The attackers configured a second Identity Provider (IdP) to act as an “impersonation app” that accessed applications within the compromised organization on behalf of other users. This “source” IdP, controlled by the attacker, established an inbound federation relationship with the target. Thankfully, in Okta there is an event type related to user sessions that initiated impersonation. you can run the following query in Okta to see all cases of impersonation:
eventType sw "user.session.impersonation.initiate"
Code language: Perl (perl)Without any need for complex rule logic, we can simply trigger a Sysdig alert when the user.session.impersonation.initiate event is flagged, as seen below:
rule: User initiating impersonation session in Okta
desc: Detect a user who initiates an impersonation session in Okta
condition: okta.evt.type = "user.session.impersonation.initiate"
Code language: Perl (perl)Single Sign-On (SSO) Manipulation
From the “source” IdP, the threat actor manipulated the username parameter for targeted users in the second “source” IdP to match a real user in the compromised “target” IdP. This manipulation allowed them to SSO into applications in the target IdP as the targeted user, further emphasizing the importance of protecting these highly-privileged accounts. Protecting these accounts is not merely a matter of security compliance but a fundamental necessity to preserve the integrity of an organization’s identity and access management ecosystem.
To establish a more comprehensive identity security stance, it will be essential to leverage Okta services like Okta FastPass to guard against potential phishing attempts and Okta ThreatInsight for detecting suspicious IP requests. However, responding quickly to these events with high confidence requires a managed ITDR approach.
Organizations must improve time to detect and stop breaches
In the contemporary landscape, organizations are tasked with managing data sources stemming from a multitude of origins, encompassing host endpoints, cloud services, and the Identity provider. This comprehensive oversight assumes a requisite level of visibility across all these diverse environments. Frequently, organizations opt to transmit logs to a centralized SIEM (Security Incident and Event Management) platform, although the efficacy of such platforms in real-time detection of suspicious activities can be variable.
In contrast, the heightened efficiency in data pre-processing offered by Incident Response tools like Sysdig minimize the inefficiencies of funneling data into a SIEM, where subsequent analysis tends to occur retrospectively, often incurring substantial costs for the organization. This conundrum underscores the pressing demand for an identity-centric ITDR solution equipped with the essential capabilities to identify and promptly address issues related to identity security. In the context of cloud environments, this requirement typically aligns with the realm of CDR (Cloud Detection and Response).
Conclusion
Securing your identity provider is a multifaceted challenge with no one-size-fits-all solution. To enhance its security, consider configuring Authentication Policies for privileged application access, enforcing re-authentication. Be prepared for evolving security landscapes and adapt to the latest authentication tools and recovery methods.
Extend the principle of least privileged access to help desk teams by limiting the use of remote management tools. To address device and permission changes, consider using open-source Threat Detection and Response (TDR) tools like Sysdig to enhance threat detection and response within the Okta environment.
In conclusion, while there’s no magic solution, a proactive, adaptive approach involving strong authentication policies, least privileged access, and TDR tools can significantly bolster your identity provider’s security against evolving threats.