Attackers love to find weak spots in our domains and networks. Too often, they can enter systems to lie in wait and launch attacks at a later time. A case in point is the infamous SolarWinds software attack, which infected up to nine US agencies and many organizations with backdoors into their infrastructure.
Recent investigations show that the Department of Justice may have been aware of the potential for a breach months before it happened. Prior to purchasing the affected software, a trial was installed on sample servers and network administrators appear to have been concerned and questioned when there was unusual traffic from one of the servers. Investigators were brought in to examine the situation, but no one understood the significance until months later.
The backdoor was ultimately discovered by several of these same investigators when the software was found on their servers. If it took experts in the field months to find that this software was backdoored, can those of us who are not experts expect to find these attackers in our network?
Use egress filtering on firewalls
My recommendation in this sort of scenario is twofold: firstly, don’t overlook using egress filtering on a firewall to determine if traffic being sent outbound from your servers is normal. Note that you can use the basic built-in Windows firewall to block traffic. Too often we fail to use solutions that are built into our existing infrastructure and want to go with vendor solutions. But using egress filtering comes with a large overhead: businesses often demand that connections and communications with other servers come first and do not take the time and effort to determine what traffic is normal and expected.
Secondly, don’t second-guess network administrators when they question why a vendor is doing something odd with their software. I have often been in the situation where I’m investigating something that appears to be either an unexpected leak of information or downright misbehaving software, and I think that I must be overreacting to the evidence I’m seeing. Surely some other company has seen and reported this behavior before and I’m merely misunderstanding what is happening?
Do due diligence when purchasing new software
I must often reassure myself through additional research and external verification that what I’m seeing is not normal. Thus, when purchasing any new software, ensure that staff is empowered to investigate any unusual traffic that can’t be explained and consider moving to a “block first, enable after” vetting process for your firewall. Don’t introduce new software to your Active Directory domain before performing true due diligence and investigation.
But what if the attack technique is a bit closer to home? Another method attackers employ that is equally hard to investigate and understand is the “living off the land” style of attack that uses existing code or infrastructure. If you have an Active Directory network, you’ll want to perform a bit of self-examination. If you have ever used an Active Directory Certificate Services (ADCS) server in your network, attackers may be able to pivot from a regular user to a domain administrator merely by exploiting ADCS vulnerabilities. Note that these types of vulnerabilities will not show up on a normal scan — you need to know about some of these weak spots.
ADCS attacks can be trivial for bad actors
If your firm is like a typical firm, your Active Directory infrastructure has been in place for many years. As a result, you may have older settings, leftover services, and older forest and domain settings. Pentesters and attackers will often use the ADCS attacks to showcase how trivial it can be to gain access. As Spectorops have showcased in a whitepaper on the topic, there are several methods to run attack techniques.
If your Active Directory certificate template permits client authentication and allows an enrollee to supply an arbitrary subject alternative name (SAN), the attacker can request a certificate based on the vulnerable template and specify an arbitrary SAN. Thus, if the attacker has a password gleaned from a user authenticated on the domain, they can then use various tools to request a certificate and specify that it has the domain administrator as the SAN field. You can already see what’s coming next, because the attacker requested a certificate and has received it with the equivalent of domain administrator rights.
Even if you’ve already fixed this potential for breach and pivot in-house, I’d argue that you’d still want to reach out to any consultant you rely on — if they have a weakness, you share the risk. Thus, ensure that vendors that you rely on also audit their Active Directory.
Some protections are built into Windows
Some of the methods you can use to monitor and prevent these attacks are already built into Windows. You’ll want to monitor for Event 4886 which states “Certificate Services received a certificate request” as well as Event 4887, “Certificate Services approved a certificate request and issued a certificate.”
Finally, don’t forget to review your network’s domain functional level. Not having it on a newer release can often hold back the rollout of key security protections. A case in point is the recently released native Windows Local Administrator Password Solution (LAPS). With the April 2023 cumulative updates, Microsoft has introduced a new feature to all Windows 10 and 11 platforms as well as Server 2022 and Server 2019 that now integrates the ability to store a random local administrator password natively without needing the separate (now called legacy) local administrator toolkit deployed. You also can use Windows LAPS to automatically manage and back up the directory services restore mode (DSRM) account password on your Windows Server Active Directory domain controllers.
If you are still running a Windows 2016 domain controller, Server 2016 does not support the newly released Windows LAPS solution and thus you can’t encrypt the Windows LAPS password. As Microsoft notes, if your domain forest level is 2016 or lower, clear-text password storage is supported but encrypted password storage for domain-joined clients and DSRM account management for domain controllers is not.
You must deploy Windows Server 2019 or later domain controllers to obtain the full benefit of integrated Windows LAPS password encryption using the new methodology integrated into the April cumulative updates. Your weak spot may be that legacy domain controller that you’ve left behind and not gotten around to updating.
Copyright © 2023 IDG Communications, Inc.
