Stopping BadSuccessor with the LDAP Firewall

In recent years, the LDAP protocol has become an increasingly popular target for attackers looking to escalate privileges, move laterally, or persist inside Active Directory environments. As more researchers explore the depths of Microsoft’s legacy protocols, more vulnerabilities continue to surface — and many of them abuse LDAP in novel and unexpected ways. 

Just in the past few years, we've seen a surge in LDAP-based attack techniques and vulnerabilities, including: 

• LDAPNightmare, a remote code execution vulnerability found in the LDAP protocol itself  
• Certified Pre-Owned attacks, where LDAP is used to modify certificate attributes for performing authentication bypass 
• DACL-based attacks, which manipulate AD objects over LDAP to gain persistence or escalate privileges 
• Shadow Credentials, where attackers abused LDAP for AD user or computer account takeover 
• And now, BadSuccessor, which leverages Directory Managed Service Accounts (DMSA) to escalate privileges 

What all these attacks have in common is that they use legitimate LDAP functionality in malicious ways — slipping past traditional detection and often leaving defenders scrambling to respond post-disclosure. 

That’s why we built LDAP Firewall: to detect and block these attacks before they're even discovered. 

What is BadSuccessor? 

BadSuccessor, discovered by researchers at Akamai, is a new attack chain that leverages a lesser-known feature of Active Directory: Directory Managed Service Accounts (dMSA). These accounts are designed to provide services with a simple and secure credentials management solution, and are an expansion of Group Managed Service Accounts (gMSAs). The dMSA feature intended to provide a simple migration process for unboarding nonmanaged accounts, however it also introduced a new attack surface. 

The key problem is that dMSAs can be created and configured in a way that allows unintended privilege escalation. By leveraging LDAP requests, an attacker with limited privileges can create or manipulate a dMSA object in Active Directory — potentially gaining control over high-privilege accounts or sensitive services. 

Why These Attacks Keep Happening 

One recurring theme across these attacks is that they rely on unexpected or overly permissive LDAP operations. Even when proper access control lists (ACLs) are configured, LDAP can still expose dangerous functionality through obscure attributes, flexible filters, or writeable object paths. 

The bigger issue is that defenders are often stuck playing catch-up. By the time a new vulnerability is published, proof-of-concept code is already available and threat actors are actively scanning for vulnerable environments. 

So instead of waiting for the next LDAP-based zero-day to emerge, we need to flip the script: assume LDAP is a critical attack surface and proactively filter its traffic. 

How LDAP Firewall Stops BadSuccessor (and More) 

Zero Networks LDAP Firewall is an open-source tool designed to detect and block malicious LDAP traffic in real time. It sits on your domain controllers, analyzes each request, and applies customizable rules to drop anything suspicious before it reaches the Active Directory schema. 

Even though BadSuccessor was only recently disclosed, LDAP Firewall can already block it. That’s because the attack relies on adding new objects and modifying specific DMSA-related attributes via LDAP operations like Add or Modify — exactly the kind of traffic LDAP Firewall is designed to inspect and restrict. 

The first stage of the attack comprises of adding a new dMSA account that will later “inherit” the permissions of an existing account. In the POC, this was done using the New-ADServiceAccount Powershell command, although the same Add operation can be achieved using any tool or code that lets you perform raw LDAP queries.  

In our lab environment, our LDAP Firewall is configured to block all Add operations from unapproved sources. After running the PowerShell command, we can see that our attempt to add a new dMSA account fails, and an audit is written to the Windows Event log. 

The New-ADServiceAccount Powershell command fails to run 

The block is audited in our DC’s Windows Event Log 

Interesting to note is that this request occurs over SOAP using the Active Directory Web Services (ADWS, port 9389) and not over the regular LDAP port (389 / 636). We can see that even though the request happens from a remote host, the client network address field in the event log is ::1, which is the IPv6 loopback address.  

The second stage of the attack requires modifying two attributes on our newly created dMSA account, which triggers a migration process that allows our account to “inherit” the permissions of a legacy account. The attributes that need to be modified are msDS-ManagedAccountPrecededByLink and msDS-DelegatedMSAState. In our case, we had to first manually create the dMSA account from an approved host, as the LDAP request to create a new account in the previous step of the attack was blocked.  

Our LDAP Firewall is set to block suspicious modify operations, using rules that allow hosts to only perform modify operations for a defined list of known benign attributes. This caused the second step of the attack to fail as well, as the attributes used in the attack are not in the allowlist. 

The modify request to trigger the migration process is blocked 

Event log of the modify operation block 

By implementing rules that block dangerous object creation, overly broad searches, and modifications of sensitive attributes (like msDS-ManagedAccountPrecededByLink), LDAP Firewall prevents entire classes of attacks — including ones that haven’t been disclosed yet. 

Try It Now 

Zero Networks LDAP Firewall is free, open source, and easy to deploy. Whether you're worried about BadSuccessor, LDAPNightmare, or the next protocol-abusing zero-day, LDAP Firewall gives you a powerful way to control what gets through to your domain controllers — get it on GitHub