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.\u00a0Recent 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 firewallsMy recommendation in this sort of scenario is twofold: firstly, don\u2019t 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\u2019t 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\u2019m 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\u2019m seeing. Surely some other company has seen and reported this behavior before and I\u2019m merely misunderstanding what is happening?Do due diligence when purchasing new softwareI must often reassure myself through additional research and external verification that what I\u2019m seeing is not normal. Thus, when purchasing any new software, ensure that staff is empowered to investigate any unusual traffic that can\u2019t be explained and consider moving to a \u201cblock first, enable after\u201d vetting process for your firewall. Don\u2019t 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 \u201cliving off the land\u201d style of attack that uses existing code or infrastructure. If you have an Active Directory network, you\u2019ll 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 \u2014 you need to know about some of these weak spots.ADCS attacks can be trivial for bad actorsIf 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\u2019s coming next, because the attacker requested a certificate and has received it with the equivalent of domain administrator rights.Even if you\u2019ve already fixed this potential for breach and pivot in-house, I\u2019d argue that you\u2019d still want to reach out to any consultant you rely on \u2014 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 WindowsSome of the methods you can use to monitor and prevent these attacks are already built into Windows. You\u2019ll want to monitor for Event 4886 which states \u201cCertificate Services received a certificate request\u201d as well as Event 4887, \u201cCertificate Services approved a certificate request and issued a certificate.\u201dFinally, don\u2019t forget to review your network\u2019s 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\u2019t encrypt the Windows LAPS password.\u00a0 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\u2019ve left behind and not gotten around to updating.