Cover Illustration by mocapoca_
A lot of fuzz has been made about the ALPHV/Blackcat hack against MGM Resorts, where they said that they exploited MGM's Okta Agent to sniff for passwords, gaining super administrator privileges to MGM's Okta account and escalating their attack to Global Administrator privileges on their Azure Active Directory Tenant.
Specifically, they outlined that :
MGM made the hasty decision to shut down each and every one of their Okta Sync servers after learning we had been lurking on their Okta Agent servers sniffing passwords of people whose passwords couldn't be cracked from their domain controller hash dumps.
This leads to very interesting questions :
What did they mean by "sniffing passwords of people whose passwords couldn't be cracked"?
What role did Okta Sync servers play in breaching MGM's active directory?
3rd Party Identity Providers and AD
We know that Okta, like other IdP vendors such as Jumpcloud, has integrations with Microsoft Active Directory for both On-prem AD and Azure-based Cloud AD. While these companies usually tout that their solutions can replace Active Directory, sometimes migrating away from Active Directory as a single source of truth for user management can be a pain in the ass especially if you operate a large workforce.
Okta also syncs Application-level password synchronization, which allows it to sync an Okta password to certain third-party applications. This also works with Active Directory and LDAP as outlined in this [documentation](https://help.okta.com/en-us/content/topics/directory/password-sync-application.htm) :
If you have configured Okta to use delegated authentication with Active Directory (AD) or LDAP, the password used to sign in to Okta is the Active Directory or LDAP password. Okta uses the application API to synchronize the Active Directory or LDAP password to the application. The password is stored as the application password.
Okta Agent connections also use Port 443 for AD and 636 for LDAP, both of which are secured using SSL by validating the Okta server SSL and mutual authentication with the Domain Controller using a limited read-only integration account created at the DC during the agent install process according to this document.
Many were quick to assume that either Okta was storing the passwords in cleartext or that ALPHV had magically found a way to decipher TLS connections, which have massive implications. But I think the explanation is far more simple than this.
Okta is not a small company, but a massive IdP vendor. I think if they were transferring passwords from AD to Agent, someone would've sniffed the packets and reported it publically. And I'm pretty sure the ones behind ALPHV don't have access to Project BULLRUN.
Delegated Authentication
Okta's AD synchronization feature syncs users to Okta and enables Delegated Authentication. So basically, when you enter your password in Okta, it gets put in a queue and the agent grabs it and authenticates on your behalf to AD. The password gets encrypted when put in the queue and then the agent decrypts on-premises (or they can just purely rely on TLS), but it will use the clear text to authenticate to AD as the Microsoft API works that way. You can replicate this via powershell easily :
param(
[string]$Username,
[string]$Password,
[string]$domain.domain
)
Add-Type -AssemblyName "System.DirectoryServices.AccountManagement"
$Context = New-Object System.DirectoryServices.AccountManagement.PrincipalContext([System.DirectoryServices.AccountManagement.ContextType]::Domain, $Domain)
$IsValid = $Context.ValidateCredentials($Username, $Password)
if ($IsValid) {
Write-Host "The credentials are valid."
}
else {
Write-Host "The credentials are not valid."
}
It's possible that they injected a DLL to hook the function obtaining data from Okta. This can occur post-TLS decryption, letting them sniff the data in the agent. Then, the Okta Agent employs a Windows API function to update the user's domain details, using the native API to generate a hash and input it into the active directory domain.
Insecure by Design
Okta has compromised security measures to cater to large enterprises, which isn't necessarily an uncommon thing. However, by enabling integration with Active Directory, Okta has inherited the security weaknesses that come with AD environments.
Active Directory in corporate networks is one of the leading providers of tech debt, and honestly, new corporations if possible should stay clear of it.
In the functioning of Active Directory (AD), domain-connected computers necessitate the exposure of certain firewall ports to facilitate essential communications and operations. However, this comes with the risk of opening potential gateways for unauthorized entries.
Active Directory's use of Group Policy Objects (GPO), used for central management of network computers, can offer control over network policies to attackers by dictating policies across the network. Additionally, the local caching of credentials, a common practice in Windows systems integrated with AD, can be another access point for attackers to extract vital credentials and facilitate lateral movement across the network.
Active Directory is also a repository of valuable network information, including intricate details about users, groups, and computers, which can turn into a gold mine for attackers.
Service Principal Names (SPNs), indicative of the services running on the network, can also be scanned to locate high-value targets, providing attackers with a blueprint to orchestrate well-planned attacks.
AD’s support for older protocols and technologies, albeit to maintain compatibility with outdated systems, creates several security challenges. The continued support for the less secure NTLM alongside Kerberos is one such example. This support enlarges the scope for attackers, offering them opportunities to exploit known vulnerabilities in NTLM.
The shift towards a SaaS-first IdP system is increasingly recognized as a robust strategy to enhance security, with SSO and SCIM (System for Cross-domain Identity Management) allowing systems to offer seamless experiences without inheriting the vulnerabilities prevalent in traditional Active Directory environments.
