Detection and Triage of Domain Persistence

Detection and Triage of Domain Persistence

Speakers: Joshua Prager; Nico, Adversary Detection Researcher, SpectreOps

Conference: BSides NYC

YouTube: https://www.youtube.com/watch?v=OMAs_Q0sQ08

Overview

This talk, presented by Nico and Joshua Prager from SpectreOps, delves into the critical and often overlooked area of domain persistence techniques utilized by advanced adversaries. Drawing from real-world compromise assessments, the speakers highlight how organizations frequently lack the necessary detective controls to identify sophisticated attacks that establish elevated and enduring control within an Active Directory environment. The presentation meticulously breaks down various persistence methods, from credential theft on domain controllers to advanced abuses of Active Directory Certificate Services (ADCS) and System Center Configuration Manager (SCCM), offering a comprehensive guide for defenders to detect and triage these threats.

The significance of this research stems from a stark reality observed during a SpectreOps compromise assessment: a client was so deeply compromised that the only viable solution appeared to be a complete "burn down the forest" scenario. This severe breach was initially undetected, underscoring a pervasive gap in many organizations' security postures. The talk aims to bridge this gap by providing detailed insights into the telemetry generated by these attacks, moving beyond high-level guidance to offer actionable detection and triage strategies.

Crucially, the speakers challenge common defender biases regarding attack complexity, demonstrating how adversaries can achieve full domain compromise in a surprisingly few, efficient steps. While the original research included recovery strategies, this particular presentation focuses intently on the detection and triage aspects, incorporating SpectreOps' latest offensive tradecraft insights from their adversary simulation team to provide a defender's perspective on the cutting edge of attack techniques.

Background

▶ Watch: Introduction, speakers, and talk scope (0:00)

The genesis of this research originated from a sobering compromise assessment conducted by SpectreOps. A client, suspecting a minor breach, was found to be "really, really, really compromised," necessitating drastic recovery measures. At the time, the client's existing security infrastructure completely missed the domain persistence techniques employed by the adversary. Furthermore, comprehensive, detailed guidance on recovering from such a deep domain compromise was scarce, with only high-level recommendations from Microsoft available. This dual challenge – a lack of detection and insufficient recovery blueprints – spurred SpectreOps' in-depth investigation.

A common misconception among defenders, red teamers, and penetration testers is the assumption of a lengthy, multi-stage attack path. This bias suggests an adversary starts with a low-privilege user, performs local privilege escalation, propagates laterally, harvests elevated credentials, and only then attempts domain compromise. However, as the speakers emphasize, real-world attacks are often far more direct and rapid.

To illustrate this, the talk outlines a specific, real-world attack path that led to full domain compromise in just four steps:

1. Initial Access & Privilege Escalation: The adversary exploited CVE-2019-0604 against a forward-facing SharePoint server. This vulnerability allowed remote code execution by uploading ASPX files and executing post-commands, granting System-level access by abusing the server farm service account.
2. Credential Harvesting: Despite the SharePoint server running Carbon Black App Control, the adversary leveraged Sysinternals tools, which are Microsoft-signed and thus often whitelisted. They used procdump to dump the LSASS process memory, exfiltrated it to their attacker machine, and then used Mimikatz to harvest the credentials of two domain administrators who were interactively logged in via RDP. Within two steps, the adversary achieved Domain Administrator (DA) privileges.
3. Lateral Movement to Domain Controller: From the compromised SharePoint server, the adversary utilized psexec (another Microsoft-signed binary) with the harvested domain admin credentials to move laterally to the domain controller.
4. Persistent Data Exfiltration: On the domain controller, a scheduled task was created to continuously dump the ntds.dit file using ntdsutil. The ntds.dit file contains all Active Directory users, computers, and their secrets. This file was then exfiltrated to an external command-and-control (C2) host using invoke-ninja-copy and powercat.

This compromise persisted for an extended period, only coming to light when a new defensive EDR solution was being demoed and detected the ntds.dit dumping activity. This case starkly demonstrates that full domain compromise can be achieved with surprising simplicity and speed, often bypassing traditional defenses.

The speakers define domain persistence as an adversary's ability to gain elevated control in an environment and make modifications or take actions that ensure their continued presence, even after initial access might be detected or mitigated. The techniques discussed in the talk, such as credential dumping, ntds.dit theft, DC-Sync, Golden Ticket and Diamond Ticket creation, ADCS abuse, and SCCM abuse, all fall under this umbrella, enabling adversaries to maintain powerful footholds.

Key Findings

▶ Watch: Fast, simplified attack paths challenge defender bias (2:00)

The talk reveals several critical findings regarding the state of domain persistence detection and the evolving threat landscape:

• Pervasive Detection Gaps: Many organizations lack specific, custom detective controls for advanced domain persistence techniques. There's a common overestimation of how many steps an adversary needs to take, leading to a false sense of security that initial compromises will be caught.
• Simplicity and Speed of Attack Paths: Contrary to popular belief, full domain compromise can be achieved in as few as four steps, as demonstrated by the real-world example involving CVE-2019-0604, LSASS dumping, and ntds.dit exfiltration.
• Insufficient Default Telemetry: Out-of-the-box Windows and Active Directory logging is often inadequate for detecting these sophisticated attacks. Crucial visibility often requires enabling non-default auditing and configuring System Access Control Lists (SACLs) on sensitive objects.
• Microsoft's Recommendations vs. Security Reality: Microsoft's own guidance, such as recommending against enabling CredGuard on domain controllers due to potential domain issues, creates inherent vulnerabilities that adversaries can exploit for LSASS credential theft.
• Irreversible Compromise Risk: The theft of the ntds.dit file exposes the Domain DP API Backup Key, which is practically unchangeable. This means that even after extensive remediation, an organization remains susceptible to recurring compromise if this key is stolen, highlighting a critical flaw in recovery strategies.
• Advanced Adversary Evasion: Sophisticated attackers modify standard tools like Mimikatz to avoid default Indicators of Compromise (IOCs) and detection flags, necessitating detections that focus on underlying API calls or behavioral anomalies rather than tool-specific signatures.
• Rapid Evolution of ADCS Abuse: Active Directory Certificate Services (ADCS) continues to be a fertile ground for privilege escalation and persistence. New attack paths, such as those documented in the "Certified Pre-Owned" white paper (now up to ESC15 and beyond), emerge rapidly, requiring continuous updates to defensive strategies.
• SCCM as a C2 Platform: System Center Configuration Manager (SCCM), a ubiquitous enterprise management tool, is increasingly abused by adversaries as a Command and Control (C2) platform. Reconnaissance against SCCM infrastructure can often be performed by any authenticated user via basic LDAP queries.
• The Power of Prevention: While the talk primarily focuses on detection, the speakers strongly emphasize that most of these advanced techniques, including NTLM Relay, have robust preventative controls. Implementing these controls, though potentially time-consuming, can significantly harden an environment against these threats.

Technical Deep Dive

▶ Watch: Detailed 4-step domain compromise walkthrough (2:40)

The core of the talk provides a granular breakdown of various domain persistence techniques, outlining the adversary's methods and the specific telemetry defenders can leverage for detection.

Credential Theft on the Domain Controller via LSASS Memory

Credential theft from the Local Security Authority Subsystem Service (LSASS) process is a foundational technique. On a domain controller (DC), this is particularly critical due to the presence of Tier Zero accounts. Unlike client machines, CredGuard cannot typically be enabled on DCs to isolate LSASS.exe due to potential domain-wide operational issues, as per Microsoft's own recommendations.

Adversaries employ various methods to dump LSASS, including procdump, Task Manager, or direct memory access. Advanced adversaries often modify tools like Mimikatz to avoid common detection signatures (e.g., specific access mask flags like 1410 or 1010). They may also avoid direct OpenProcess calls, instead looking for leaked handles, creating child processes of LSASS, or snapshots. Regardless of the method, most techniques eventually utilize ReadProcessMemory API calls, which can be a more robust detection point.

The detection model proposed by SpectreOps focuses on an entity-action-entity relationship across multiple telemetry sources:

• Process Creation: Detecting the creation of processes like procdump.exe or modified Mimikatz variants. Relevant event IDs include Sysmon Event ID 1 and Windows Security Event 4688.
• Process Requesting Handle: Monitoring for processes requesting handles to LSASS.exe.
• Process Access: Detecting suspicious access patterns to the LSASS process.
• Process Memory Read: Specifically looking for calls to ReadProcessMemory targeting LSASS.

NTDS Access

The ntds.dit file, containing Active Directory's database, is typically locked by the Active Directory Users and Computers (ADUC) service. Adversaries bypass this lock by using the Volume Shadow Copy Service (VSS) to create a snapshot of the volume, which allows access to the ntds.dit file without direct interaction with the locked original.

Detecting ntds.dit access requires enabling non-default auditing. Defenders should:

• Set a SACL on the ntds.dit file itself: This generates telemetry when the file is accessed.
• Monitor for VSS service startup: A service starting (specifically VSS) followed by shadow copy creation.
• Monitor for processes requesting handles to ntds.dit.

The speakers highlight a critical ethical and recovery concern: stealing the ntds.dit file also compromises the Domain DP API Backup Key. This key is used to encrypt everything for every user across Windows in the enterprise and, per Microsoft's guidance, cannot be changed without risking accidental encryption of the entire domain. This makes organizations susceptible to recurring compromise even after extensive cleanup.

DC-Sync

DC-Sync is a common red team technique that requests replication of Active Directory data from a domain controller, mimicking legitimate replication traffic. It gained popularity as an alternative to ntds.dit theft because it avoids the ethical dilemma of exfiltrating the unchangeable Domain DP API Backup Key. Red teams often use it to prove the ability to synchronize all users by targeting a specific Domain Administrator account.

Detection of DC-Sync relies on auditing the Directory Replication Service (DRS) API, which is not enabled by default. Key telemetry to monitor includes:

• Process Connection: A process connecting to the DC via the DRSU API and making an NC changes request. This manifests as a process connecting to a specific IP address, generating relevant Windows Security Events.

Numerous existing detections are available from security vendors and researchers (e.g., Splunk Lantern, Palo Alto Unit 42), but they all hinge on enabling the necessary auditing.

Golden Tickets

Kerberos is the primary authentication protocol in Active Directory, relying on a Key Distribution Center (KDC) to issue Ticket Granting Tickets (TGTs) and Service Tickets (TGSs). A Golden Ticket attack involves forging a TGT, allowing an adversary to impersonate any user (including Domain Admins) and access any resource within the domain for an extended period, often up to 10 years by default. This requires the domain's FQDN, SID, the impersonated account, and critically, the Kerberos TGT password hash, typically obtained from an ntds.dit dump.

Defenders face challenges because Microsoft's Kerberos implementation does not include a centralized ticket counting process, making it difficult to track all issued tickets. Detection strategies include:

• Auditing Kerberos Events: Enable auditing for Event ID 4768 (TGT requested) and Event ID 4769 (TGS requested).
• Mismatch Detection: Look for 4769 events (service requests) from a user without a corresponding 4768 event (TGT request) within a reasonable timeframe. This indicates a forged TGT.
• Mimikatz Time Stomps: Default Mimikatz-generated Golden Tickets often have suspicious lifespans (e.g., 10 years), which can be an anomaly.
• Access Mask Flags: Detect default access mask flags used by common Golden Ticket tools.

Nico presented a BPMN (Business Process Model and Notation) diagram to illustrate the operational flow of an adversary creating a Golden Ticket, detailing interactions between the adversary, the Domain Controller, and the KDC.

Diamond Tickets

Unlike Golden Tickets, which forge a TGT from scratch, Diamond Tickets involve modifying a legitimately issued TGT. The adversary intercepts a valid TGT, decrypts its Privilege Attribute Certificate (PAC) (if weak encryption or the TGT hash is known), and modifies it to impersonate a different user, alter resource access, or change the ticket's lifespan.

Detection for Diamond Tickets is more challenging. One strategy is to:

• Isolate Tickets without TGS Requests: A modified TGT might not generate subsequent TGS requests because the altered PAC invalidates it for new service requests. Defenders can look for TGTs issued to a user that are never followed by TGS requests.
• Baselining: Extensive baselining is required to identify anomalies in ticket usage patterns.

A corresponding BPMN diagram was presented, emphasizing the PAC modification step.

Active Directory Certificate Services (ADCS) Abuse

ADCS abuse has become a major vector for privilege escalation and persistence, extensively documented in the "Certified Pre-Owned" white paper by Will Schroeder and Lee Christensen. The attack surface is constantly expanding, with new escalation paths (e.g., ESC15) emerging frequently.

The core of ADCS abuse involves an adversary manipulating certificate templates to gain control, often by leveraging misconfigurations where authenticated users have excessive permissions (e.g., GenericAll access) over these templates.

Centralized detection for ADCS abuse focuses on monitoring changes and activities related to certificate templates:

• Machine Certificate Enrollment: Monitor Event ID 4886 for user requests for specific certificates.
• Certificate Issued: Track the event ID generated when the Certificate Authority issues a certificate.
• Certificate Modification: Monitor Event IDs 4899 and 4900 when a machine certificate template is modified. Note that these events only generate if the template is both modified and enrolled.
• SACLs on Certificate Templates: For more robust detection, set SACLs on certificate templates to generate Event ID 4663 upon access or modification, providing an additional layer of visibility regardless of enrollment status.

The speakers highly recommend the "Certified Pre-Owned" white paper as an essential resource for detection engineers working with ADCS.

SCCM Abuse (Misconfiguration Manager Project)

System Center Configuration Manager (SCCM), a widely deployed software management solution, is increasingly abused by adversaries as a C2 platform. SpectreOps' "Misconfiguration Manager" project categorizes these abuses into reconnaissance, credential theft, execution, and site takeover. SCCM operates in a hierarchical structure, typically involving a Central Administration Site (CAS) server, primary/secondary site servers, and configuration manager clients (endpoints).

Reconnaissance (Recon 1-6)

Adversaries first enumerate SCCM infrastructure to identify site servers, distribution points, and SMS providers. This is crucial because many attack techniques require specific FQDNs.

• Remote Reconnaissance:
• LDAP Queries: Any authenticated user can perform LDAP queries against the Active Directory's System Management container to identify SCCM components. Tools like TrustedSec's SA boffs can execute these queries.
• SMB, HTTP, Named Pipes: Various communication mechanisms can be used to identify SCCM infrastructure.
• Detection: Event ID 1644 (Domain Controller LDAP diagnostic log) can catch inefficient or suspicious LDAP queries. However, this log is verbose, has a 100MB size limit, and requires careful management.
• Local Reconnaissance: If an SCCM client is compromised, adversaries can examine files like cwindows.ccm.logs.smsts.log, CCM cache, and CCM setup for information about distribution points and site servers.
• Detection: Set SACLs on these directories and log files to detect unauthorized access.

Credential Theft (Cred 1)

The Cred 1 technique focuses on identifying servers that contain Pixieboot variable settings, which often include sensitive credentials.

• Operational Flow:

1. Identify and connect to a distribution point via SMB.
2. Enumerate the reminst (remote install) share, typically used for Windows Deployment Services (WDS).
3. Enumerate the SMS temp directory within reminst.
4. Collect .var files from SMS temp, which may contain credentials.
5. Parse these files using offensive tooling.

• Detection:
• Event ID 3 (SMB Connection): While noisy, it indicates an SMB connection.
• Event ID 5145 (Detailed File Share Event): This provides granular logging for connections to the reminst share and references to the SMS temp directory.
• SACLs: Set SACLs on the reminst share, SMS temp directory, and .var files to detect access.

Execution (Exec 1)

The goal of Exec 1 is to force an SCCM client to execute arbitrary code (e.g., a beacon). This involves several steps within the SCCM framework:

1. Collection Creation: Define a collection of target users or devices.
2. Application Creation: Create an application, specifying its content. This content can be a binary already on the client, a UNC path to a network share (e.g., \\fileshare\beacon.exe), or an uploaded binary to the SCCM infrastructure itself.
3. Deployment Creation: Combine the collection, application, and scope into a deployment.
4. Deployment Initiation: Initiate the deployment, causing the SCCM client agent to pull and execute the application.

• Detection: The Configuration Manager Status Message Queue provides critical logs:
• Event ID 30015: Collection created.
• Event ID 30152: Application created.
• Event ID 30226: Deployment created.
• Event ID 40800: Deployment initiated. Anomalous creation of these objects can indicate malicious activity.

Site Takeover (Takeover 1 - NTLM Relay)

The Takeover 1 technique leverages NTLM Relay to gain full administrative control over the MSSQL database server backing an SCCM site. By default, an SCCM site server has full administrative control over its associated MSSQL database.

• Operational Flow:

1. An authenticated user (even from a non-SCCM client) coerces authentication from the target SCCM site server via SMB.
2. The adversary acts as a relay point, forwarding the SCCM site server's coerced authentication to its MSSQL database server.
3. This grants the adversary full administrative control over the SQL database, enabling site takeover.
4. A common prerequisite step for adversaries is to stop the LanmanServer (server service) to unbind port 445, allowing their tools to listen on it.

• Detection:
• Successful Logon Event (4624): Look for Logon Type 3 (network logon) with NTLM SSP as the authentication package. The detection involves comparing the Subject Account Name (a machine account, expected to be an SCCM site server) with the Host Machine Name where the logon originated (expected to be the SQL database server). This requires significant baselining to filter legitimate traffic.
• Service Stoppage: Detect the stopping of the LanmanServer service.
• Sysmon Event ID 18 (LSA RPC Name Pipe): While connections to the LSA RPC name pipe are generated, this is generally unrealistic for detection due to extreme verbosity.

Demo / Proof of Concept

▶ Watch: Overview of domain persistence techniques covered (6:00)

While the talk meticulously details the mechanics of various domain persistence techniques and their associated telemetry, it does not include a live demonstration or proof of concept. Instead, the speakers focus on explaining the attack flows and the specific data models and event IDs that defenders can leverage, drawing from their extensive experience with SpectreOps' offensive and defensive research. The emphasis is on providing comprehensive, actionable guidance for detection engineering rather than showcasing a live exploit.

Defensive Implications

▶ Watch: Practical vs. theoretical detection guidance approach (6:40)

The insights presented in "Detection and Triage of Domain Persistence" carry profound implications for defensive security strategies. Organizations must move beyond default security configurations and adopt a proactive, intelligence-driven approach to detect and mitigate these advanced threats.

1. Proactive Auditing Configuration: The most immediate implication is the necessity of enabling non-default auditing across the Active Directory environment. This includes enabling auditing for:

• Directory Replication Service (DRSU API) for DC-Sync detection.
• Kerberos TGT (4768) and TGS (4769) events to identify Golden Ticket and Diamond Ticket attacks.
• LDAP diagnostic log (1644) on domain controllers to catch suspicious SCCM reconnaissance.
• Specific events related to ADCS certificate template modification and issuance.

Without this granular telemetry, detection of many advanced techniques is impossible.

1. Strategic Use of SACLs: System Access Control Lists (SACLs) are highlighted as critical, yet often underutilized, defensive tools. Defenders should implement custom SACLs on highly sensitive objects, including:

• The ntds.dit file itself, to detect unauthorized access.
• ADCS certificate templates, to log modifications and access attempts.
• SCCM shares (e.g., reminst, SMS temp) and local SCCM log directories (e.g., .var files), to detect credential harvesting and local reconnaissance.

SACLs provide a vital layer of custom auditing that default logging often lacks.

1. Comprehensive Baselining: Many advanced detection strategies, particularly for techniques like NTLM Relay (using Event ID 4624 logon events) or identifying anomalous Kerberos ticket usage, require extensive baselining. Defenders must understand normal network and system behavior to effectively identify deviations indicative of compromise. Without baselining, the sheer volume of legitimate events can render otherwise useful telemetry too noisy for practical application.

1. Operational Context in Detection Engineering: It's crucial for detection engineers to understand the operational context of various event IDs. As the speakers noted, some events (e.g., Sysmon Event ID 18 for LSA RPC name pipe connections, or generic SMB Event ID 3 connections) are technically present but too verbose and noisy to be actionable without unrealistic levels of baselining. Detections should focus on higher-fidelity signals or combinations of events.

1. Stay Current with Offensive Tradecraft: The rapid evolution of attack techniques, particularly in areas like ADCS (e.g., new ESC paths up to ESC15+) and SCCM abuse (e.g., Misconfiguration Manager project, Sharp SCCM, SCCM Hunter), demands continuous threat intelligence integration. Defenders must proactively research and integrate new detection logic to counter emerging attack vectors.

1. Robust Recovery Planning for Deep Compromise: The talk underscores the severe challenges posed by deep domain compromises, especially when the Domain DP API Backup Key is stolen via ntds.dit exfiltration. Organizations must develop recovery plans that account for "burn down the forest" scenarios and the practical impossibility of replacing certain keys. Recovery procedures should be designed to mitigate recurring compromises and offer realistic steps for environments that cannot simply be rebuilt from scratch.

1. Prioritize Prevention: While the talk focuses on detection, a strong emphasis is placed on prevention. Many of the discussed techniques, including NTLM Relay and various SCCM abuses, have effective preventative controls. Implementing these, though potentially time-consuming (e.g., a year for NTLM Relay preventions), significantly hardens the environment and makes it much harder for adversaries to achieve persistence in the first place. The "Misconfiguration Manager" project, for instance, offers more preventative controls than detections.

1. Adopt the "Entity-Action-Entity" Model: Applying the "entity-action-entity" relationship model to telemetry analysis can help structure detection engineering efforts, ensuring that events are broken down into their fundamental components for more effective rule creation.

Key Takeaways

• Domain Persistence is a Silent Threat: Many organizations are deeply vulnerable to domain persistence attacks, which often go undetected due to inadequate security controls and a misunderstanding of adversary tradecraft.
• Attack Paths Are Simpler Than Assumed: Adversaries can achieve full domain compromise in a surprisingly small number of steps, bypassing traditional defenses that expect complex, multi-stage attacks.
• Default Logging is Insufficient: Relying solely on default Windows and Active Directory logging leaves critical blind spots. Custom auditing, especially through SACLs on sensitive objects like ntds.dit and certificate templates, is paramount.
• ADCS and SCCM Are High-Value Targets: Active Directory Certificate Services (ADCS) and System Center Configuration Manager (SCCM) are increasingly abused for privilege escalation and persistence, with new attack methods emerging rapidly.
• Detection Requires Deep Technical Understanding: Effective detection engineering necessitates a granular understanding of attack mechanics, underlying API calls, and the ability to differentiate anomalous behavior from normal activity through baselining.
• Prevention is the Strongest Defense: While detection is crucial, most advanced persistence techniques have robust preventative controls that, if implemented, can significantly harden an environment against compromise.
• Recovery Planning Must Be Realistic: Organizations need to develop comprehensive recovery plans that account for deep domain compromise scenarios, including the challenges posed by unchangeable artifacts like the Domain DP API Backup Key.

About the Speaker(s)

Nico Schein is an Adversary Detection Researcher at SpectreOps, where he focuses on blue team and purple team research. He is a graduate of the Naval Academy and served five years in the Navy as an Information Professional Officer, specializing in cryptography and satellites. After leaving the Navy, he joined SpectreOps and recently completed his Master's degree in Management of IT from UVA. Nico’s expertise lies in dissecting offensive tradecraft to develop robust defensive strategies.

Joshua Prager is a co-presenter and researcher at SpectreOps, deeply involved in the adversary detection and simulation research discussed in the talk. His contributions cover a wide range of domain persistence techniques, including ADCS and SCCM abuse. Like Nico, Joshua is committed to transparency in security research, believing in sharing insights that benefit both offensive and defensive communities.