How to defend against Active Directory attacks that leave no trace

Cybercriminals are using new tactics and techniques to gain access to Active Directory in novel ways, making their attacks even more dangerous—and more necessary to detect.  

One of the most important parts of any cybersecurity strategy is detection. Having an ability to spot the bad guy entering, moving about, or worse—administering—your network is key to a swift response. And with the median number of days an attacker sits undetected on your network at 146, according to Microsoft, it’s evident that the bad guys are very good at working in stealth.  

When it comes to detecting potentially malicious actions within Active Directory (AD), most organisations rely on Domain Controller event log consolidation and SIEM solutions to spot abnormal logons and changes. This all works—as long as the attack technique leaves a log trail. 

A few types of attacks have been seen in the wild that leave no discernable trail or, at least, any evidence of malicious activity. Some examples include: 

DCShadow attack  

Using the DCShadow functionality within the hacker tool Mimikatz, this attack first takes the path of registering a rogue domain controller (DC) by modifying the Configuration partition of AD. Then the threat actor makes malicious fake changes (e.g., changes to group memberships of Domain Admins, or even less obvious changes such as adding the SID of the Domain Admins group to the sidHistory attribute of a compromised normal user). This attack technique bypasses traditional SIEM-based logging, as the rogue DC doesn’t report the changes. Instead, changes are injected directly into the replication stream of the production domain controllers.  

Group Policy changes  

A documented attack involving Ryuk ransomware resulted in changes being made to a Group Policy object that propagated the installation of Ryuk to remote endpoints within the victim organization. By default, event logs don’t include details on what was changed within a Group Policy. So, if an attacker makes a malicious change (as in the case of Ryuk), all that’s seen is that an account with access to the Group Policy made a change, which probably won’t set off any alarms.  

Zerologon attack  

After a proof–of–concept exploit code was released in public, an attacker with network access to a domain controller was able to send special Netlogon messages consisting of strings of zeros, forcing the domain controller computer password to be changed to an empty string. So, without any logon—i.e., with zero logon—the attacker now owns the domain controller, can perform any changes in AD, and can further use this path to attack other systems in your infrastructure. It is unlikely that your monitoring tools today are watching out for unexpected password changes on your DCs. 

It isn’t by chance that these attacks don’t leave a trace; it’s by design. The bad guys are spending massive amounts of time inspecting exactly how their target environments function and looking for ways to bypass, obfuscate, and circumvent any form of detection—which includes logging.  

Because these kinds of attacks exist, the question becomes what should you do about it—both proactively and reactively? 

There are three ways to protect your organization against malicious AD changes:  

Monitor AD for malicious changes: This goes beyond SIEM and involves a third-party solution designed to see every change made within AD—regardless of who makes it, on which DC, using what solution, etc.—ideally by reading and understanding the replication traffic of the DCs themselves. This monitoring needs to include changes within Group Policy as well. In many cases, solutions designed to monitor changes in AD can define specific protected objects to be monitored for any change—for example, changes in membership to Domain Admins—so that any time those protected objects are modified, alarms do go off. The solution should cover both changes to Group Policies as well as visibility into replication.  

Look for DCShadow: Mimikatz leaves some artifacts behind and there are some telltale signs that DCShadow has been used on your network. Reviewing AD for these signs needs to be part of a regular review of AD security. Note that once you find a trace of Mimikatz DCShadow in your environment, you must act quickly as you’ll already be a victim of an attack. At that point, you will wish you also had a solution that would show you what changes were performed at the replication level, which you could then analyze and ideally revert.  

Be able to recover AD: Your organization needs the proactive ability to recover any and all of AD should you determine that AD has been compromised. In some cases, you can be thinking in terms of backups and a DR strategy to recover AD in a cyberattack scenario. Should you indeed need to recover your complete AD service, potentially as the next victim of a malware attack, beware that a good domain controller backup does not equate to a seamless and fast AD service recovery. You’ll want to have practiced the whole recovery process periodically, following the copious Microsoft AD Forest Recovery Guide. But it’s equally valuable to look for solutions that can revert changes down to the attribute level or even automatically revert changes to protect objects when detected. 

Targeting Active Directory and modifying it to suit the attacker is a common tactic taken by today’s cybercriminal—so much so that the old model of watching AD audit events for changes might no longer be viable. Organisations that are serious about the security and integrity of their AD need to be looking for additional ways to gain visibility into every AD change and have the ability to revert or recover when necessary.