Domain Controller Replacement after Compromise - ToddMaxey/Technical-Documentation GitHub Wiki
DC Replacement plan
If a Domain Controller is compromised by a threat actor there are very specific remediation steps to assure the threat actor will not have any persistence or power over the domain or forest.
#Steps
-
Backup: Ensure you have a recent backup of the Active Directory (AD) database from a non-compromised DC.
-
Acquire VM or hardware: Acquire VM or hardware to be replacement server for the compromised DC.
-
Build new server: Build new replacement server for the compromised DC and DO NOT JOIN TO DOMAIN.
-
Isolate compromised DC: Physically remove the compromised DC from the network or place it on a non-internet connected network/subnet to allow for a forensic review.
-
Perform metadata cleanup: Perform meta data cleanup for the compromised DC – on the DC that holds the PDC Emulator role.
-
Replication and Deletion: Allow / force replication until no errors, and you can confirm that the machine account for the compromised DC had been deleted via AD replication on all DCs in the domain.
The command-line utility to force Active Directory (AD) replication across the domain is repadmin
. This tool allows you to manually trigger the replication of data between two or more domain controllers¹³⁵.
The specific command to force replication is:
repadmin /syncall /AdeP
This command initiates immediate replication of all directory partitions to all domain controllers in the forest¹. Here's what each option means:
-
/syncall
initiates synchronization with all replication partners. -
/A
includes all partitions. -
/d
specifies to print the distinguished names. -
/e
specifies to carry out the operation on all sites in the enterprise. -
/P
pushes changes outward from the specified domain controller¹.
Please note that you need to run this command on one of your domain controllers. Also, ensure that you have the necessary permissions to execute this command. It's recommended to use this command carefully as it can generate significant network traffic if your AD infrastructure is large.
-
Reset krbtgt account password: Reset the krbtgt account password twice. Use a krbtgt account password reset script.
-
Review AdminSDHolder permissions: Review AdminSDHolder permissions for change. This would be a method of persistence for the threat actor.
-
Review Administrator groups: Review the domain local Administrator, Domain Administrator, Enterprise Administrator, Administrator group for changes.
-
Test replication: Test replication (create object, replicate, delete object, replicate)
-
Rename new server: Rename new server to the compromised DC.
-
Change IP: Change IP on new server to match the proper IP for the compromised DC.
-
Join to domain: Join the new server to the domain.
-
Confirm new computer object: Confirm the new computer object for the compromised DC is on all DC's in the domain.
-
Promote new server: Promote the new server to Domain Controller and DNS roles.
-
Time Synchronization: Ensure that the new DC's time is synchronized with an external time source or the PDC emulator in the forest root domain.
-
Global Catalog: If the compromised DC was a Global Catalog server, ensure that you promote the new DC to be a Global Catalog as well.
-
FSMO Roles: If the compromised DC held any Flexible Single Master Operations (FSMO) roles, these roles should be seized or transferred to the new DC or another existing DC.
-
DNS Delegation: If the compromised DC was a DNS server, you'll need to update the DNS delegation to point to the new DC.
-
Site and Services: Update Active Directory Sites and Services to reflect the changes.
-
Monitoring: After the new DC is promoted, monitor the event logs for any replication or other errors.
Remember, every environment is unique, so this list may not cover all possible considerations for your specific situation. Always plan and test thoroughly before making changes in a production environment.