## Triage and analysis

### Investigating Potential Credential Access via DCSync

Active Directory replication is the process by which the changes that originate on one domain controller are
automatically transferred to other domain controllers that store the same data.

Active Directory data consists of objects that have properties, or attributes. Each object is an instance of an object
class, and object classes and their respective attributes are defined in the Active Directory schema. Objects are
defined by the values of their attributes, and changes to attribute values must be transferred from the domain
controller on which they occur to every other domain controller that stores a replica of an affected object.

Adversaries can use the DCSync technique that uses Windows Domain Controller's API to simulate the replication process
from a remote domain controller, compromising major credential material such as the Kerberos krbtgt keys used
legitimately for tickets creation, but also tickets forging by attackers. This attack requires some extended privileges
to succeed (DS-Replication-Get-Changes and DS-Replication-Get-Changes-All), which are granted by default to members of
the Administrators, Domain Admins, Enterprise Admins, and Domain Controllers groups. Privileged accounts can be abused
to grant controlled objects the right to DCsync/Replicate.

More details can be found on [Threat Hunter Playbook](https://threathunterplaybook.com/library/windows/active_directory_replication.html?highlight=dcsync#directory-replication-services-auditing) and [The Hacker Recipes](https://www.thehacker.recipes/ad/movement/credentials/dumping/dcsync).

This rule monitors for Event ID 4662 (Operation was performed on an Active Directory object) and identifies events that
use the access mask 0x100 (Control Access) and properties that contain at least one of the following or their equivalent:
Schema-Id-GUID (DS-Replication-Get-Changes, DS-Replication-Get-Changes-All, DS-Replication-Get-Changes-In-Filtered-Set).
It also filters out events that use computer accounts and also Azure AD Connect MSOL accounts (more details [here](https://techcommunity.microsoft.com/t5/microsoft-defender-for-identity/ad-connect-msol-user-suspected-dcsync-attack/m-p/788028)).

#### Possible investigation steps

- Identify the user account that performed the action and whether it should perform this kind of action.
- Contact the account owner and confirm whether they are aware of this activity.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Correlate security events 4662 and 4624 (Logon Type 3) by their Logon ID (`winlog.logon.id`) on the Domain Controller
(DC) that received the replication request. This will tell you where the AD replication request came from, and if it
came from another DC or not.
- Investigate which credentials were compromised (for example whether all accounts were replicated, or only a specific account).

### False positive analysis

- This activity should not happen legitimately, since replication should be done by Domain Controllers only. Any
potential benign true positive (B-TP) should be mapped and monitored by the security team. Any account that performs
this activity can put the domain at risk for not having the same security standards as computer accounts (which have
long, complex, random passwords that change frequently), exposing it to credential cracking attacks (Kerberoasting,
brute force, etc.).

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- If specific credentials were compromised:
  - Reset passwords for affected accounts.
- If the entire domain or the `krbtgt` user were compromised:
  - Activate your incident response plan for total Active Directory compromise which should include, but not be limited
  to, a password reset (twice) of the `krbtgt` user.

## Config

The 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).
Steps to implement the logging policy with Advanced Audit Configuration:

```
Computer Configuration >
Policies >
Windows Settings >
Security Settings >
Advanced Audit Policies Configuration >
Audit Policies >
DS Access >
Audit Directory Service Changes (Success,Failure)
```

If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, events will not define `event.ingested` and default fallback for EQL rules was not added until 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.