ADWS Architecture - Evasion of PowerShell AD Enumeration

What Happened

A recent incident revealed a significant blind spot in Active Directory (AD) security monitoring. A threat actor successfully enumerated an entire AD environment using the PowerShell command Get-ADComputer, but none of the existing detection mechanisms triggered alerts. This incident underscores a critical flaw in how PowerShell interacts with Active Directory through Active Directory Web Services (ADWS).

Why Detection Failed: The ADWS Blind Spot

The core issue lies in the architecture of ADWS. Unlike traditional LDAP queries that operate over ports 389 or 636, PowerShell utilizes ADWS, which communicates over port 9389 using encrypted SOAP/XML. This means that network-based LDAP detection tools are blind to these interactions. When the command was executed, the query appeared to originate from localhost, obscuring the attacker's real IP address and making it look like routine internal system activity.

The Critical Architectural Detail

When a PowerShell command is executed, it communicates with ADWS, which then makes the actual LDAP queries as localhost. This results in two major detection challenges:

1. Network sensors are blind: Since the query never touches the traditional LDAP ports, it goes unnoticed by standard monitoring tools.
2. Event logs show localhost: The logs indicate activity from localhost, misleading analysts into thinking it is legitimate internal traffic.

The Case Obfuscation Red Herring

The threat actor employed case obfuscation in their command (geT-aDcompUTER), which was intended to evade detection by security tools that rely on exact string matches. However, this tactic was largely irrelevant because PowerShell is case-insensitive. The real issue was the lack of detection strategies for ADWS itself.

Analyzing the Threat Actor's Command

The attacker’s command aimed to gather extensive information about computer objects in the domain. By using the filter {eNaBLed -eq $TruE}, they efficiently retrieved data on enabled computer accounts, including sensitive attributes like operating system versions and security descriptors. This comprehensive information could be leveraged for further exploitation.

What I Missed: The ADWS Context

The failure to detect this enumeration stemmed from a lack of event correlation. The detection logic was focused solely on Event 1644, which showed localhost activity. However, when correlated with other relevant events (1138, 1139, 1166, and 1167), the full picture emerged, revealing the true nature of the query and the attacker's actions.

Conclusion

This incident serves as a critical reminder of the need for robust detection strategies that account for the unique characteristics of ADWS. By understanding how PowerShell communicates with Active Directory, security teams can develop more effective monitoring solutions that close these detection gaps and enhance overall security posture.