Detect Azure Pass Through Authentication Abuse — Azure Hybrid Environments
In recent years, the cloud computing industry has experienced substantial growth, with three prominent vendors emerging as leaders: Amazon AWS, Microsoft Azure, and Google Cloud Provider (GCP).
In this article, we will explore a method attackers use to exfiltrate credentials in hybrid environments that utilize both on-premises Microsoft Active Directory and Azure, thanks to Microsoft Entra Connect (ex Azure AD Connect).
Let’s say your company runs an on-premises Active Directory setup with lots of users, computers, and other resources. You’ve also expanded into Azure to take advantage of cloud-based services, and you’re using pass-through authentication to handle user sign-ins.
For this article, I’ll assume you already know the basics of Azure, Active Directory, and how hybrid environments work, including syncing between on-premises and the cloud, so I can go straight to the point.
It’s worth noting that companies might choose this authentication approach when they need to perform checks based on Active Directory rules that aren’t available in Azure. An example can be rules that block the authentication on both on-premise and cloud outside working hours.
To learn more about Microsoft Pass Through Authentication, you can check the official documentation.
Introduction is over, let’s move to the juicy part!
Adam Chester did an incredible job in reversing the authentication agent (AzureADAuthenticationService.exe), discovering the attack which leads to credentials exfiltration. He unveiled that by exploiting the LogonUserW function in the authentication process, an attacker can inject a DLL into the AzureADAuthenticationService.exe process and hook this function. The hook captures the clear-text credentials of users trying to authenticate, before forwarding the request to Active Directory for validation. This allows the attacker to steal credentials every time someone logs in via Microsoft Entra, provided they have local admin access to the Azure AD Connect server.
In his article Adam creates a named pipe to print credentials, however as a proof of concept (PoC) I recreated the scenario in a simpler way, by saving the captured credentials in a file instead.
He does not provide the script to inject the DLL into the process, but I found creating it an amazing challenge which I recommend! If you want to learn more about the attack, here is the link to Adam’s research.
The following is a video demonstrating the credentials exfiltration:
Detection
When looking into detection strategies this attack, I came across several methods focused on cloud-side monitoring. However, in hybrid environments, telemetry data is gathered from both the cloud and on-premise systems. So, why not leverage both sources of information when building detection strategies?
The attack we’re talking falls into the DLL injection category, which generally follows a consistent set of operations:
I chose to leverage Sysmon as a telemetry source to detect these types of attacks, focusing on two key events:
- Event ID 7 Image loaded: The image loaded event logs when a module is loaded in a specific process. It basically logs the DLL imported by a process;
- Event ID 8 CreateRemoteThread: The
CreateRemoteThreadevent detects when a process creates a thread in another process. This technique is used by malware to inject code and hide in other processes.
As mentioned earlier, this attack revolves around injecting a malicious DLL into the AzureADAuthenticationService.exe process. After injecting the DLL, the malware executes it by creating a remote thread, which can be captured by monitoring these Sysmon events.
Event 7: Image Loaded
After running the injector, Sysmon generates a few Image Loaded events from the AzureADAuthenticationService.exe process. This behavior is expected, as the process naturally relies on various libraries to function.
However, it’s easy to spot the malicious DLL since it isn’t signed by Microsoft.
While attackers may attempt to sign the DLL to make their attack more sophisticated, defenders can still analyze all legitimate DLLs used by the authentication agent and create a detection rule. This rule can trigger an alert whenever an unrecognized or different DLL is loaded.
Event.System.EventID.#text:"7"
AND Event.EventData.Data.Image:*AzureADConnectAuthenticationAgentService.exe
AND (Event.EventData.Data.SignatureStatus.keyword : "Unavailable"
OR (NOT Event.EventData.Data.Product: *Microsoft*)
OR (NOT Event.EventData.Data.Signature: *Microsoft*))This query is not intended for production use but serves as a proof of concept (PoC). I recommend tuning it based on the specific environment where it will be deployed to ensure optimal results.
Event 8: CreateRemoteThread
The other crucial event to monitor is Event ID 8, which detects the creation of remote threads. This event occurs when one process creates a thread within another process, a technique widely used in DLL injection.
In our scenario, the injector specifically uses the CreateRemoteThread method to inject the malicious DLL into the legitimate process. The following KQL query can be used to spot the events:
Event.System.EventID.#text: "8"
AND Event.EventData.Data.TargetImage: *AzureADConnectAuthenticationAgentService.exe
A helpful tip I suggest is to correlate these two events. If both are triggered in short time window, it strongly indicates this attack is occurring.
Wrapping Up
The primary objective of this article was to analyze the telemetry generated after an attacker successfully compromises a domain-joined machine that is responsible for authenticating users both on-premises and in the cloud.
It is crucial for companies operating in environments similar to the one described in this article to monitor the events triggered by this particular DLL injection in the authentication agent.
Hopefully the detection strategies outlined here can be helpful to companies adopting hybrid Azure environments with Pass-Through Authentication enabled.
Feel free to reach out and ask me anything by connecting with me on LinkedIn!