They told me I could be anything I wanted ... So I became a domain controller
DCShadow is a new feature in mimikatz located in the lsadump module.
It simulates the behavior of a Domain Controller (using protocols like RPC used only by DC) to inject its own data, bypassing most of the common security controls and including your SIEM.
It shares some similarities with the DCSync attack (already present in the lsadump module of mimikatz).
As a reminder a Domain Controller is a server controlling an "Active Directory", a shared authentication service used in enterprises.
It was already possible to simulate a domain controller or to alter its internal database.
For example, by installing in a virtual machine a customized version of SAMBA. But given the fact that running a virtual machine needs hardware instruction (on x64 CPU it is disabled by default), a physical interaction with the computer may be required to enable them in the BIOS/EFI. In addition the size and time needed for a VM is not scalable.
The attacks is done using the following steps:
Here is an example of error when pushing an incorrect DACL (in this case the Owner part was missing)
And some other example of invalid data
|Feature||Prototyped||Released in mimikatz|
|Modify existing objects||YES||YES|
|Add new objects||YES||NO|
|Delete (without trace) existing objects||YES||NO|
|Alter replication data with version changed||YES||YES|
|Alter replication data without version changed||YES||NO|
|Altering schema data||YES||YES|
|Altering schema signature||NO||NO|
|Linked attributes (aka group membership)||NO||NO|
At a functional level:
At a technical level:
Because DCShadow is pushing replication information, DCShadow is responsible for pushing replication metadata. This metadata is accessible to anyone (including from trusted domains) and available throught LDAP or RPC.
This metadata is used by forensic analysts to rebuild the history of change and understand what happened on a domain. Well, this data cannot be trusted anymore.
DCShadow is easy to detect at network level. API like DrsAddEntry or DrsReplicaAdd are called only from a DC so a call from another computer should be considered as suspicious.
Using logs DCShadow can be detected when objects in the Configuration partition is added or when the computer object is changed. However a DC does not replicate the modifications immediately and regroup the changes when it replicates (a few minutes). As a consequence, the changes can be observed only on the DC attacked. This can be avoided by reusing a demoted DC (the information needed is already present in the configuration partition).
DCShadow does set the SPN GC/* or E3514235-4B06-11D1-AB04-00C04FC2DCD2/* on computers object (via DrsAddEntry)
Using LDAP cookie (LDAP_SERVER_DIRSYNC_OID) is also a way to be notified of LDAP modification
Using Audit Detailed Directory Service Replication events 4928 An Active Directory replica source naming context was established. and 4929 An Active Directory replica source naming context was removed.
First the attribute has to be found in the schema using the LDAP query (&(objectclass=attributeSchema)(lDAPDisplayName=<attribute>))
Then the OID is extracted of the attribute using the property attributeID. The syntax is extracted from attributeSyntax. Both OID are converted using a prefixTable to AttiD using the procedure described in MS-DRSR 5.16.4 ATTRTYP-to-OID Conversion
Using the attributeSyntax, a syntax is selected according to a MS-DRSR encoding algorithm. This page describes all kind of supported encoding.
The DC checks the presence of mandatory attributes such as: instanceType, objectGuid (in NC) and whenCreated. If they are present, the object is new else it is an update. If the request is considered as an update but the object is not present, the object is considered as lingering object and an event is created
Want more - ask some questions !
Is DCShadow a permanent domain controller ?
No: it transforms itself as a DC only the time the changes are pushed (a few seconds)
Does DCShadow deals with the KCC ?
No. It only add a single branch to the replication topology and remove it afterwards. It deals with KCC only if the Configuration records stay for long and in this case, it does not break the topology.
Check that instanceType and whenCreated are set ; check that the objectGuid has not be used before (log internal processing - Duplicate event log entries were suppressed)
The creation date must be larger that the lingering time (more than 6 months!). Symptom: no RPC connection to the server
Postcast NoLimitSecu (in French)