Active Directory and the Cyber Kill Chain
AD provides security and control over critical IT systems and infrastructure. As I discussed in my post Active Directory Security Risk Factors and What to Do About Them (Part 1), many attack paths lead through AD.
Cyberattackers are adept at getting a foothold into victim’s environments through spear phishing and other techniques. Once attackers control a domain account, they can perform LDAP lookups against the AD. Reconnoitering the IT environment reflected in AD, they can discover user names, job titles and roles, devices, servers, services, and user/service relationships.
Imagine having a Google-like search tool to discover the paths of privilege through AD to the “crown jewel” IT assets. It exists. Tools such as PowerSploit and Bloodhound make it easy for a “script kiddie” type of threat actor to plan their cyberattack.
Attackers can move laterally towards the target by putting the name of the account they control into a group that has privileges over the target network, server, database, or application. Still trickier exploits can leverage password resets, or compromise AD infrastructure objects that affect built-in Windows OS behavior, and can confer privileges throughout a domain.
The Big Gotcha
For cyber defense, one can lock down domain controllers with control baselines, require domain administrators (DAs) to use multi-factor authentication (MFA), and take other preventative controls. Organizations should also put tight procedural controls in place using strict AD policies, procedures, and change management. For example, adding a new DA should require a service ticket from the company’s IT service management tool, and it should go through a workflow approval.
However, many preventative controls are subject to The Big Gotcha: DAs create the rules in AD and can change them. A malicious or policy-violating DA insider, or an attacker with DA privileges, can override most of the preventative controls.
Closing the Procedural Loop
The term “AD audit” is overloaded. Sometimes it’s used for logging or monitoring (“audit log”), at other times to describe a process of verifying (“auditing”) that other controls are operating effectively. In the latter sense, audit supports compliance reporting. Auditing controls in operation also close procedural loops. It can ascertain whether or not policies or procedures on administrative privileges, DA accounts, or DC configurations are followed.
Suppose an organization with 10 DAs restricts the ability to create more through a procedure that only one DA account is authorized to add new DAs, and only with workflow approval. Audit should flag any additions of new DAs, and it should have the ability to create rules-based alerts if an out-of-process DA appears, violating the policy. For more details, check out the slides and the recording of my recent on-demand webinar: Active Directory Audit: Why and How.
The Second Chance
The diagram at the beginning of this post shows the main moving parts of an AD audit capability. When audit (a “detect” control in the NIST Cybersecurity Framework Terminology) is integrated with change monitoring and rollback (a “response” control) defenders get a second chance to stop a breach.
AD audit can also be tied with an enterprise-wide security and event information management (SIEM) solution to correlate diverse events, find additional indicators of compromise, and reduce false positives. Organizations should ensure that AD audit is part of broader AD management and monitoring capabilities that enable a rapid response.
