Attack Against Azure AD Pass-Through Authentication Agent can Compromise Azure/Office 365 Tenants

Recently, Varonis researcher Eric Saraga published a blog post announcing a new attack against Azure Active Directory (Azure AD) which can allow an attacker to log in as any synchronized user. The attack method exploits a flaw in the Pass-Through Authentication (PTA) password verification method of allowing users to use their on-premises Active Directory credentials to log into Azure and Office 365.

PTA is one mechanism available for organizations to allow users to use their on-premises Active Directory (also known as Active Directory Directory Services, or “AD DS” and not to be confused with Azure AD, which is Microsoft’s cloud-based directory service – clear as mud?)

PTA simply passes the user’s username and password and securely transmits it to the organization’s on-premises AD DS for verification. The other two methods available are:

PTA is facilitated through Microsoft Azure AD Connect that facilitates a whole bunch of services, including synchronizing users and groups from on-prem AD into Azure AD/Office 365. Obviously, with only one on-prem server facilitating PTA, this presents organizations with a single point of failure that, if offline, would prevent users from logging into Azure and Office 365 services. So, to address this issue, Microsoft developed a standalone agent that can run on a different server and create a high availability authentication mechanism for PTA.

To be clear, the attack doesn’t exploit a weakness in PTA itself, it exploits a weakness in the way that the agent does its thing. However, and to be clear, the server running the agent must be compromised first for the attack against the agent can succeed. Therefore, an attacker needs either local network access or needs to exploit a local machine remotely and pivot to the agent via the compromised host. The attacker also needs to gain administrative privileges to the server hosting the agent.

After an attacker successfully compromises a server running the Azure agent, they manipulate the authentication flow by hooking the API function LogonUserW. After the attacker successfully hooks into the API function, they can compromise the passwords of synchronized users connecting to Azure AD/Office 365. Varonis took this a step further and automated the collection of credentials via injecting a custom DLL (Dynamic Link Library) into the process flow which will still authenticate the user but in addition, writes the individual’s username and password to a specified text file. While this gives the attacker plenty of ways to authenticate but it doesn’t provide the “skeleton key.” To achieve that we need more.

Modifying the return value in the API function, LogonUserW, to accept any password as correct for any user is the key to turning this attack into a skeleton key attack. LogonUserW is a Boolean function that requires the population of the user’s token. If that token returns a true value, then the authentication is successful. The process which the Azure agent uses to authenticate users has its own token and the API function LogonUserW is being called inside of that process so the researchers at Varonis asked themselves, “Why not use the agent process’s own token?” And voila, the Azure AD Skeleton Key was created: the process’s own token will allow an attacker to log in as a user, including a Global Administrator account.

The gory details can be found in Saraga’s post here: https://blogvaronis2.wpengine.com/azure-skeleton-key/

Hat tip to our buddy Steven Rennard at Varonis for alerting us to this research.

While this is certainly a high impact attack it appears from Varonis’ communication with Microsoft that there are no plans to patch this vulnerability any time soon. As such, it becomes all the more important to ensure that your environment and users are thoroughly protected through secure configuration practices and modern security technologies.

Detecting an attacker getting into your network via an IDS/IPS or SIEM technology, limiting the attacker’s ability to escalate privileges or pivot via an Endpoint Detection and Response tool and preventing this skeleton key attack via implementation of Multi-Factor Authentication (MFA) technology are all viable and practical options to mitigate this threat.

If you’re an Assura Managed SIEM, Managed Endpoint Protection, or Managed Multi-Factor Authentication client, then we are actively taking measures to protect you from these attacks. If you’re an existing Assura customer, contact your Virtual ISO or Assura POC for further guidance.

Stay safe, stay healthy, and as always feel free to submit any questions you may have about this or any other cybersecurity matter through our website or to [email protected].

Sincerely,

The Assura Team