Active Directory database tampering

Threat snapshot

Active Directory is the identity backbone of most Windows enterprise environments. The NTDS.dit file is the Active Directory database: it contains every user account, every password hash, every group membership, and every trust relationship in the domain. Whoever controls NTDS.dit controls the domain. This makes it one of the most targeted files in enterprise security, and one of the most dangerous to leave unmonitored.

Attackers who reach a domain controller and extract NTDS.dit or its credentials gain the ability to authenticate as any user in the domain, forge Kerberos tickets, and maintain persistent, undetected access long after the original compromise has been remediated. The four detection rules in this use case cover the primary techniques used to tamper with, copy, or extract credentials from the Active Directory database: creating a shadow database via install-from-media, copying the live database using volume shadow copy bypass techniques, extracting Kerberos tickets via PowerShell, and creating a memory dump of the LSASS process using the MiniDump API. Together they give the SOC early warning of an attack that, if missed, results in total domain compromise.

At a glance

How this attack works

Active Directory database attacks fall into two broad categories: offline extraction, where the attacker obtains a copy of the NTDS.dit file and processes it outside the domain controller, and live extraction, where the attacker pulls credentials directly from memory or from the Kerberos ticket cache on a running system. The four detection rules in this use case cover one technique from each of the main attack paths.

Install-from-media database creation

The ntdsutil.exe utility includes an Install From Media (IFM) feature designed for provisioning new domain controllers without requiring full replication. When invoked with the create full command, it generates a snapshot of the Active Directory database including a copy of NTDS.dit and the SYSTEM registry hive. Attackers abuse this feature because it is a built-in, signed Microsoft tool that produces a portable, complete copy of the credential database without requiring the attacker to interact with the live VSS subsystem or stop any services. The resulting IFM set contains everything needed to extract all domain password hashes offline.

Credential database copy via Ninja-Copy technique

The Windows Volume Shadow Copy Service (VSS) maintains point-in-time snapshots of volumes. Because NTDS.dit is locked by Active Directory while the domain controller is running, attackers use VSS to access a shadow copy of the volume and copy NTDS.dit from the snapshot path rather than the live path. The Ninja-Copy technique, originating from a PowerShell-based tool, automates this process by using raw disk reads to bypass the file lock entirely, without creating or mounting a traditional VSS snapshot that would be visible in the event log. The result is a copy of the live NTDS.dit extracted without standard VSS audit events firing.

Kerberos ticket extraction via PowerShell

Kerberos tickets cached in the memory of a domain-joined system can be extracted using PowerShell-based tooling that calls into the Windows SSPI layer to enumerate and export ticket-granting tickets (TGTs) and service tickets. Extracted TGTs can be imported on another system and used to authenticate as the ticket's owner for the duration of the ticket's validity, typically 10 hours, without needing the account's password. This technique, commonly referred to as Pass-the-Ticket, is particularly dangerous when used against high-privilege accounts whose tickets are cached on shared or compromised systems.

Credential dump creation via PowerShell MiniDump

The LSASS process holds plaintext credentials, NTLM hashes, and Kerberos tickets for all users with active sessions on a Windows system. The Windows MiniDump API, accessible from PowerShell via the DbgHelp.dll MiniDumpWriteDump function or via the Out-MiniDump PowerShell function, allows the LSASS process memory to be written to a dump file on disk. That dump file can then be transferred off the system and processed offline using credential extraction tools to recover plaintext passwords and hashes without ever running a credential dumping tool directly against the live LSASS process.

Attack chain

The table below maps each stage of an Active Directory database tampering attack to the corresponding MITRE ATT&CK technique.

Real-world scenario

A healthcare organization runs a single Active Directory domain serving 2,400 users across three hospitals. A threat actor who gained access six days earlier via a phishing email targeting a senior IT administrator has been moving laterally using the compromised account's domain credentials. Having identified the primary domain controller, the attacker uses a known privilege escalation exploit to obtain SYSTEM-level access on the DC.

The attacker opens a PowerShell session as SYSTEM and runs ntdsutil.exe with the IFM create full command, outputting a complete Active Directory snapshot to a temporary directory. They then copy this directory to a network share on a compromised workstation. The NTDS.dit file and SYSTEM hive from the IFM set are sufficient to extract all 2,400 password hashes offline using publicly available tools. Separately, the attacker runs a PowerShell MiniDump script against the LSASS process on the same domain controller, writing the memory dump to a file in the Windows Temp directory before transferring it out of the environment.

Within 48 hours, the attacker has plaintext credentials for 34 privileged accounts including the domain administrator, three service accounts with SQL Server access, and the organisation's backup administrator. None of the extraction steps triggered an alert because process creation auditing was enabled but the SOC had no rule specifically targeting ntdsutil.exe IFM invocations or PowerShell MiniDump activity against LSASS. The attacker uses the extracted KRBTGT hash to forge a Golden Ticket, establishing indefinite domain access that persists even after the initial compromised account is discovered and disabled.

Why this happens
ntdsutil.exe is a signed Microsoft binary with legitimate administrative uses. LSASS memory dumps are used by legitimate diagnostic tools. Kerberos ticket extraction can be performed using built-in Windows APIs. Volume shadow copy access is a routine backup operation. Each of these techniques individually resembles a legitimate administrative action. Without rules that specifically target the combination of the tool, the target, and the operational context, each step of the credential extraction passes undetected.

Business impact: What can go wrong

Active Directory database tampering is one of the highest-impact threat scenarios in enterprise security. The consequences of an undetected extraction are severe and long-lasting:

• Total domain compromise: extraction of NTDS.dit yields password hashes for every account in the domain. Combined with the SYSTEM hive for decryption, all domain credentials become accessible to the attacker offline, with no further network access required.
• Golden Ticket persistence: the KRBTGT account hash extracted from NTDS.dit allows the attacker to forge Kerberos tickets for any account, with any group memberships, for any validity period. A Golden Ticket created from an extracted KRBTGT hash provides indefinite domain access that survives password resets on every account except KRBTGT itself, and persists for up to 10 years if the KRBTGT hash is not rotated.
• Credential reuse across the enterprise: domain account hashes can be cracked offline or used directly in Pass-the-Hash attacks against every system in the domain, every cloud service using Azure AD synchronisation, and every VPN or remote access solution using domain authentication.
• Silent long-term access: because Golden Tickets and Pass-the-Hash techniques use valid cryptographic material, authentication events generated by their use appear identical to legitimate logons in the event log. The attacker continues to operate inside the environment undetected indefinitely.
• Regulatory and legal consequences: exposure of credential databases containing personal data, health records, or payment data triggers breach notification obligations under GDPR, HIPAA, and PCI DSS. Failure to detect and report within the required notification window compounds the regulatory penalty.
• Recovery cost: recovering from a confirmed NTDS.dit extraction requires rotating the KRBTGT password twice, resetting every privileged account password, auditing every service account, and potentially rebuilding the Active Directory environment from scratch if the extent of the compromise cannot be fully determined.

Indicators of compromise and detection signals

Prerequisites for detection using Log360

Before the Active Directory database tampering rules can fire reliably, ensure the following are in place:

• Windows Process Creation auditing with command-line logging is enabled on all domain controllers, generating Event ID 4688 with the full ProcessCommandLine field populated. This is the primary telemetry source for the IFM creation and MiniDump rules.
• Sysmon is deployed on all domain controllers with a configuration capturing Event ID 1 (Process Create), Event ID 11 (File Create), and Event ID 7 (Image Load). Sysmon provides the enriched process context, parent-child relationships, and file creation events needed to detect Ninja-Copy and Kerberos extraction techniques that may not generate standard Windows audit events.
• Object Access auditing is enabled on domain controllers for the NTDS.dit file path (typically %SystemRoot%\NTDS\), generating Event ID 4663 (An attempt was made to access an object) when the database file is accessed by processes other than the Active Directory service.
• PowerShell Script Block Logging is enabled on all domain controllers via Group Policy (Event ID 4104). This captures the decoded content of PowerShell commands after the interpreter processes them, providing visibility into obfuscated Kerberos extraction and MiniDump scripts that may evade command-line logging.
• Domain controller logs are forwarded to Log360 in near-real-time via the Log360 agent or Windows Event Forwarding. Domain controllers are the highest-value log source in an Active Directory environment. Any forwarding delay creates a window during which credential extraction may complete before an alert fires.

Detecting Active Directory database tampering using Log360

Once log collection is configured, follow these steps to enable and tune detection in Log360:

Step 1: Enable the detection rules

Navigate to Security > Manage Rules > Rule Library in the Log360 console. Install and enable the rules: Install-From-Media Database Creation via Command Line, Credential Database Copy via Ninja-Copy Technique, Kerberos Ticket Extraction via PowerShell, and Credential Dump Creation via PowerShell MiniDump. Configure Critical-severity alerts to notify the SOC queue immediately.

Step 2: Read the alert

The alert will display the domain controller hostname, the account that executed the command, the full command line (if process creation auditing is enabled), the process name, and the timestamp. For the Kerberos extraction and MiniDump rules, the PowerShell Script Block log content in the alert detail provides the decoded command even if the invocation was obfuscated. Pay close attention to the executing account: a domain administrator account running these commands outside a documented maintenance window requires immediate verification. Any non-administrative account triggering these rules is a confirmed high-severity event.

Investigating an alert

When any Active Directory database tampering rule fires, an L2 analyst should work through the following steps before declaring a confirmed incident:

• Identify the executing account and its session context. Determine the account under which the extraction tool ran, the logon type used to establish the session, and the source IP address if the session was remote. A remote session from an unrecognised IP running extraction tools on a domain controller is the highest-confidence indicator of an active intrusion.
• Check for output files. For IFM creation, search for recently created directories containing ntds.dit on the domain controller and any connected network shares. For MiniDump, search for .dmp or .mdmp files created in Temp, AppData, or user-writable paths in the same time window as the alert. The presence of output files indicates the extraction completed successfully.
• Check for data staging and exfiltration. Query Log360 for network connections from the domain controller in the 30 minutes following the alert. Look for outbound connections to external IPs, large file transfers to internal file shares, or SMB copy events that would indicate the extracted files were transferred off the domain controller.
• Verify against documented administrative activity. Check the change management system for any approved domain controller maintenance, domain controller provisioning activity, or authorised diagnostic work that would explain the observed commands. If no ticket exists and the executing account owner cannot confirm the activity, treat the event as confirmed malicious.

Escalation trigger
Escalate immediately to L3 and treat as a domain-wide compromise if any of the following are observed: an IFM set or NTDS.dit copy has been created and output files are present on disk; a MiniDump of the LSASS process has been written to a file; more than one of the four rules has fired on the same domain controller in a 60-minute window; or network connections from the domain controller to external IPs occurred within 30 minutes of any rule firing. Any confirmed extraction of NTDS.dit or LSASS memory requires mandatory KRBTGT password rotation and full privileged account credential reset as part of the incident response.

Responding and remediating

Immediate containment

• Isolate the affected domain controller from the network immediately if an active extraction session is in progress or if output files are present on disk. Use EDR host isolation rather than shutting down the DC, to preserve volatile memory evidence and avoid triggering additional replication or GPO processing events that could mask attacker activity.
• Disable the executing account in Active Directory immediately. If the account used to run the extraction tool is a named administrator, disable it and force a password reset. If it is a service account, disable it and notify the owning team. If it is a machine account or SYSTEM, the DC itself is the source of the threat and isolation takes priority.
• If an IFM set or NTDS.dit copy is confirmed to exist, initiate an immediate mandatory KRBTGT account password reset, performed twice with a minimum 10-hour interval between resets to invalidate all outstanding Kerberos tickets across the domain. This must be done regardless of whether the extracted file has been confirmed as transferred off the domain controller.

Forensic preservation

• Capture a memory image of the affected domain controller before any reboot or remediation using WinPmem or your EDR's memory acquisition capability. The attacker's tools and any in-memory credential material they captured may be recoverable from the memory image.
• Export Windows Security, Sysmon, and PowerShell Script Block logs from the affected domain controller covering the full period from the first unusual event. These logs are the primary forensic record of the extraction sequence and the account and session context used.
• Preserve any output files found on disk, including IFM directories, .dmp files, and any staging directories. Hash these files and document their creation timestamps before removing them.

Eradication and recovery

• Rotate the KRBTGT password twice with a 10-hour interval between resets. This is mandatory for any confirmed or suspected NTDS.dit extraction because the KRBTGT hash is extractable from the database and is used to forge Golden Tickets.
• Reset passwords for all privileged accounts: Domain Admins, Enterprise Admins, Schema Admins, service accounts with domain rights, and any account confirmed to have been used by the attacker. Treat all credentials accessible on the compromised domain controller as exposed.
• Audit all domain controllers for the same extraction artefacts. Run targeted searches across all DCs for recently created IFM directories, .dmp files, and scheduled tasks or services that may have been used to run extraction tools.
• Review and rotate the passwords of all service accounts synced to Azure AD or external identity providers, as extracted hashes from NTDS.dit may be usable against synchronised accounts in cloud environments.

False positive guidance

The techniques targeted by these rules have narrow legitimate use cases. False positives are uncommon but do occur in the following scenarios:

• Domain controller provisioning via IFM: the Install-From-Media feature is its intended use case. When a new domain controller is being provisioned from an IFM set rather than full replication, ntdsutil.exe will be run with create full arguments. Verify that a domain controller build is in progress, that the executing account is the documented DC build account, and that the activity aligns with a change ticket. Add a scoped exclusion for the build account and the specific provisioning schedule.
• Authorised diagnostic memory dumps: Windows Error Reporting and some endpoint protection products create process memory dumps under specific error conditions. These may occasionally include LSASS. Verify that the dump was created by a signed vendor process, not by PowerShell or a custom binary, and that the dump destination is a documented diagnostic path.
• Authorised red team or penetration testing: authorised security assessments may exercise these techniques as part of their scope. Cross-reference with the penetration test schedule and scope documentation before treating an alert as malicious. Even in authorised testing, the alerts should not be suppressed retroactively. Document the test activity and the corresponding alerts in the incident record.
• Backup software accessing NTDS.dit via VSS: backup agents that perform system state backups of domain controllers access NTDS.dit via VSS as part of their normal operation. These accesses will generate Event ID 4663 against the NTDS.dit path. Verify the accessing process is the documented backup agent binary and occurs on the documented backup schedule.

Key differentiator

Legitimate administrative use of ntdsutil.exe IFM is rare, scheduled, and performed by a named administrator following a documented process. Legitimate LSASS memory dumps are created by signed vendor binaries, not by PowerShell. Legitimate Kerberos ticket operations use standard Windows APIs via authenticated sessions, not PowerShell scripts invoking SSPI directly. Any of these techniques being executed via PowerShell, a script, or an unrecognised binary, outside a documented administrative window, by an account not associated with the specific task, should be treated as malicious.

Hardening and prevention

Detection is most effective when paired with controls that restrict access to Active Directory credential material at the source:

• Restrict access to domain controllers to named administrative accounts only, via tiered access models or privileged access workstations. Domain controllers should not be reachable via RDP or SMB from general-purpose workstations. Every unnecessary authentication path to a DC is a potential credential extraction path.
• Enable Windows Defender Credential Guard on all domain controllers to prevent LSASS from storing plaintext credentials and Kerberos ticket material in a form accessible to usermode processes. Credential Guard moves LSASS secrets into a virtualization-based security enclave that is inaccessible to PowerShell and standard Win32 APIs.
• Restrict execution of ntdsutil.exe to documented domain controller build accounts via AppLocker or WDAC policies. Outside of planned DC provisioning workflows, ntdsutil.exe has no routine operational use and its execution should be blocked or alerted on at the process execution layer before it reaches log-based detection.
• Enable Protected Users security group membership for all Domain Admin and privileged accounts. Members of Protected Users cannot use NTLM, cannot have their credentials delegated, and cannot cache credentials on non-DC systems, significantly reducing the material available for extraction via LSASS MiniDump on workstations.
• Rotate the KRBTGT account password on a scheduled basis, at minimum twice per year, in addition to any emergency rotation following a security incident. Regular KRBTGT rotation limits the validity window of any Golden Tickets that may have been silently forged from a prior extraction that was not detected.
• Deploy a Privileged Access Management solution to enforce just-in-time access to domain controllers. Requiring time-limited, approval-gated administrative access to DCs eliminates the standing access that attackers rely on to run extraction tools interactively.
• Enable and enforce PowerShell Constrained Language Mode on domain controllers to restrict the PowerShell capabilities available to non-administrative sessions. Kerberos extraction and MiniDump techniques delivered via PowerShell depend on full language mode to call into native APIs and load external assemblies.