Loading story…
Huntress reported that LDAP Ping–based Active Directory username enumeration is not captured by Windows Event 1644 because the traffic is handled by netlogon.dll rather than the LDAP engine in ntdsa.dll. Testing of the ldapnomnom tool found its current implementation is more detectable than advertised: because it uses TCP instead of true UDP cLDAP, Windows can generate Security Event 5156 with the attacker source IP when Filtering Platform Connection auditing is enabled. Netlogon debug logging can also record each queried username and indicate whether accounts are enabled, disabled, or nonexistent.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
1 event from the most recent confirmed update back to the earliest known activity.
In a blog post published on 2026-06-19, Huntress analyzed LDAP Ping-based Active Directory username enumeration and concluded that ldapnomnom is more detectable than advertised because its current implementation uses TCP, which can generate Windows Security Event 5156 when Filtering Platform Connection auditing is enabled. The post also explained that true UDP cLDAP remains a logging blind spot for Windows event logs and discussed defender visibility through netlogon.log, packet capture, firewall logs, and Microsoft Defender for Identity.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
1 reference tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Microsoft disclosed and patched **CVE-2017-8563**, an elevation-of-privilege flaw in Windows LDAP authentication that could let a man-in-the-middle attacker forward authentication requests to a vulnerable LDAP server. The issue affects Windows LDAP servers, including systems running **Active Directory Domain Services (AD DS)** and **Active Directory Lightweight Directory Services (AD LDS)**, when they are configured to require signing or sealing on incoming connections. The security update adds support for **Extended Protection for Authentication**, allowing affected LDAP servers to detect and block forwarded authentication attempts. Organizations using Windows-based directory services are advised to apply the Microsoft update and enable the protection to reduce the risk of authentication relay leading to privilege escalation in Active Directory environments.
Jun 29, 2026
Two separate Windows authentication weaknesses were highlighted as enabling high-impact **Active Directory** compromise via relay-style attacks. One issue, **CVE-2025-33073**, affects Windows **SMB client** authentication and enables **NTLM reflection**: attackers can coerce `lsass.exe` (running as **SYSTEM**) to authenticate to attacker-controlled infrastructure using techniques such as *PetitPotam*, *DFSCoerce*, and *Printerbug*, then relay/reflect that authentication to gain SYSTEM-level access and potentially full domain compromise. Reporting emphasized that despite a June 2025 patch, the condition remains widely present in enterprise environments due to incomplete patch adoption, and exploitation can be enabled with relatively low prerequisites such as the ability to register a malicious AD DNS record (often permitted to Authenticated Users by default) or to perform local DNS poisoning. A second technique described a **Kerberos relay** vector that abuses how Windows clients process **DNS CNAME** responses when building the SPN for TGS requests, allowing an on-path attacker (e.g., via ARP poisoning or DHCPv6/mitm6) to redirect victims to attacker-controlled services and obtain service tickets usable for relays and lateral movement. The write-up claims default configurations across Windows 10/11 and Windows Server 2022/2025 are susceptible, with potential impact including cross-protocol relays (e.g., HTTP→SMB/LDAP) and paths to RCE in some environments (e.g., via ADCS web enrollment scenarios). A separate Metasploit weekly wrap-up noted new and updated offensive modules (including AD privilege-escalation content), but it did not specifically tie to either of the two relay issues above.
Jun 30, 2026
Multiple security research teams reported **DNS-related abuse paths** that can be weaponized for denial-of-service and authentication relay. Unit 42 described how Azure *Private Endpoint/Private Link* DNS behavior can be leveraged—accidentally or maliciously—to disrupt access to Azure resources by effectively “over-privatizing” name resolution, creating a DoS condition for services such as **Storage Accounts, Key Vault, Cosmos DB, Azure Container Registry, Function Apps, and OpenAI accounts**. Their assessment suggested the exposure is not rare in the wild (they observed **5%+ of Azure storage accounts** in configurations susceptible to this DoS pattern) and noted Microsoft guidance around *internet fallback* as a partial mitigation, alongside recommendations to scan environments for susceptible configurations. Separately, Cymulate detailed a **Kerberos authentication relay technique via DNS CNAME abuse** in Windows/Active Directory environments: an on-path attacker can influence DNS CNAME resolution so Windows clients request Kerberos service tickets for attacker-chosen **SPNs**, enabling relays to services like **SMB/HTTP** when signing or **Channel Binding Tokens (CBT)** are not enforced. Cymulate stated Microsoft acknowledged the behavior and responded by improving target-service resilience, including **backported CBT support for HTTP.sys** in supported Windows Server versions (released in a January patch cycle). A third report from Positive Technologies analyzed an **RCE path in Windows Telephony Service (TAPI)** via arbitrary file write from a low-privileged client, which is a distinct Windows local/service exploitation topic and not part of the DNS/Kerberos abuse story.
Jun 29, 2026