Skip to main content

Hit by ransomware? Isolate affected systems now. Do not reboot or reformat.

SheMo Noransom舍末无勒

Scenario solution

Domain Controller Compromise and Estate-Wide Encryption

  • Active Directory 域控制器
  • 组策略 GPO
  • NTDS.dit
  • Windows 终端与成员服务器
  • 文件服务器与打印服务
  • 备份服务器
  • 虚拟化平台

A compromised domain controller hands the attacker a legitimate administrator identity, allowing an encryptor to be pushed to every host at once through Group Policy or remote execution. This page covers how such incidents present, the correct order for Active Directory recovery, and how to decide between cleanup and full rebuild.

Typical symptoms

  • Endpoints and servers across the estate were encrypted within a very short window — often one or two hours — with identical extensions and ransom notes
  • The domain controller itself is encrypted or will not boot, NTDS.dit or SYSVOL is damaged, and domain logons fail broadly
  • Group Policy contains unfamiliar startup scripts, scheduled tasks or software distribution entries, with suspicious batch or executable files in SYSVOL
  • New domain administrator accounts exist, or existing accounts have been added to Domain Admins, with krbtgt anomalies
  • Antivirus has been uninstalled or disabled estate-wide by policy, and Defender has been given whole-disk exclusions
  • Event logs show heavy PsExec / WMI / WinRM remote execution, directory replication requests with DCSync characteristics, and logs cleared in bulk

Business risk & common mistakes

Domain controller compromise is the most comprehensive form of ransomware damage, because the attacker no longer has to break into each host — they hold legitimate administrative credentials and can distribute the encryptor estate-wide using the very tools administrators use (Group Policy, PsExec, WMI, SCCM, remote scheduled tasks). It is fast, complete, and in the logs it looks like ordinary operations.

The typical chain: an initial foothold from exposed RDP, a VPN, a web application flaw or a phishing email; local privilege escalation and credential harvesting from memory; lateral movement in search of privileged accounts; DCSync or a direct NTDS.dit export to obtain hashes for the whole domain; domain administrator rights; and then delete backups, disable antivirus, clear logs, and deploy estate-wide. In publicly documented cases, attackers have also bypassed technical controls entirely through social engineering, impersonating an employee to a service desk to obtain a password reset.

Three things make these incidents distinctive:

  • Recovery must begin at the identity layer. Data can be restored from backup, but if Active Directory itself is not clean and credentials have not been comprehensively reset, restored systems will simply be re-encrypted. Identity first, data second — the order cannot be reversed.
  • "Clean up or rebuild" is a judgement that must actually be made. Where the attacker achieved domain administrator rights and may have exported NTDS.dit, they in principle hold credential material for every account, including krbtgt. Password changes alone cannot guarantee eradication, so a domain rebuild — or at minimum a properly executed double krbtgt rotation — must be seriously assessed.
  • The backup estate has probably fallen too. A backup server inside the domain, running jobs under a domain administrator account, is dealt with along the way.

Mistakes to avoid: restoring a domain controller from backup and reconnecting it to the network without assessment, declaring safety after a single password change, and rebuilding endpoints with the original domain credentials. We do not recommend paying, and we do not negotiate on your behalf.

Our response plan

  1. Isolate the estate and preserve evidence

    Isolate quickly by segment, prioritising the lateral channels between endpoints and servers (SMB, RDP, WinRM) and cutting external connectivity. Do not immediately rebuild the domain controllers. Image or snapshot the domain controllers, backup servers and critical member servers read-only. Evidence priorities: DC security and directory service logs, SYSVOL and Group Policy objects, traces of NTDS.dit access, Kerberos ticket anomalies, artefacts left by remote execution tooling, network flow records, and VPN and firewall logs.

  2. Reconstruct the attack chain and gauge privilege depth

    This step drives every later decision. The core questions: how deep did the attacker's privileges go, was NTDS.dit exported, how long were they resident, and what backdoors remain? Examine newly created or elevated accounts, changes to Group Policy and logon scripts, scheduled tasks and services, indications of golden or silver tickets, signs of AD certificate services abuse, and covert delegation settings or ACL modifications. Identify the encryptor family and its behaviour at the same time, to inform the data recovery assessment.

  3. Decide the route: clean and rebuild AD, or build a new forest

    Make an explicit route decision on that basis and document the reasoning. Where domain administrator rights were demonstrably obtained and NTDS.dit export cannot be ruled out, ordinary password changes carry real risk. The options are an AD forest recovery from trusted offline backups combined with a comprehensive credential reset (including a correct double krbtgt rotation and handling of service and computer accounts), or building a clean new domain and migrating users and resources into it. The latter costs more but offers certainty, and is often the safer choice where dwell time was long and artefacts were thoroughly wiped.

  4. Restore identity first, then business systems in batches

    The order is strict: identity and authentication (domain controllers, DNS, certificate services), then network and security infrastructure, then core databases, then business applications, then endpoints. Every batch is cleaned and validated in an isolated segment — no persistence, no web shells, fully patched, EDR deployed, credentials reset — before it joins the network. For endpoints, reimaging is usually preferable to cleaning, because their number makes verification costlier than rebuilding. Keep heightened monitoring throughout, and re-isolate immediately on any anomaly.

  5. Comprehensive credential reset and structural hardening

    The reset must cover every domain user and administrator, service accounts, local administrators (randomised via a solution such as LAPS), krbtgt (rotated twice, correctly), backup and virtualization platform accounts, network devices and VPN, and application and database accounts. Structural remediation includes a tiered administration model where administrators never log on to ordinary endpoints, separate privileged accounts with MFA, restricted SMB / RDP lateral paths, a backup estate outside the domain with immutable copies, full EDR coverage with tamper protection, and centralised log retention with alerting. Conclude with a complete incident report.

Recovery paths

Recovery here runs on two parallel tracks — rebuilding identity and restoring data — with entirely different assessment logic.

Identity layer.

OptionPreconditionsNotes
AD forest recovery from trusted backupAn offline system-state backup predating the attack existsFollow Microsoft's forest recovery procedure, with a comprehensive credential reset and double krbtgt rotation
Clean and harden the existing domainAttacker privilege depth was limited, artefacts are clear, and full-domain credential export can be ruled outViable where risk is low, but that conclusion needs real evidence behind it
Build a clean new domain and migrateNo trusted AD backup, or long dwell time with cleared logs and no way to prove eradicationHighest cost, highest certainty; appropriate for critical sectors and high-risk cases

Data layer. Each asset class follows its own scenario: file servers and shares as per the file server scenario, databases as per the database scenarios, virtual machines as per the virtualization scenario. Pay particular attention to the backup estate here: because backup servers commonly run inside the domain, they were very likely dealt with when the domain fell, so prioritise inventorying offline media, immutable storage, storage array snapshots, and independent backup systems outside the domain.

Endpoints. Reimage the estate in bulk rather than cleaning machine by machine. The reasoning: there are many endpoints, verification is expensive, and the attacker may have left backdoors across several of them; reimaging with a standard image and a credential reset is both faster and more reliable. Extract local data from important endpoints in an isolated environment first.

Stated plainly: where AD backups cannot be trusted, offline copies are missing and logs have been cleared, recovery becomes an engineering project with a rebuild character, with timeline and cost well above a single-system restore. We avoid "100%" and "guaranteed recovery", and we provide a staged schedule and resourcing plan during assessment. No ransom payment, no negotiation.

Common ransomware families

Hardening recommendations

  • Adopt a tiered administration model. Domain administrator accounts must never log on to ordinary endpoints and servers; administrative work happens on privileged access workstations. Keep day-to-day accounts strictly separate from privileged ones.
  • Strong authentication for privileged accounts. Enforce MFA on every administrator account, restrict where and when they can log on, and audit membership of Domain Admins, Enterprise Admins and similar groups regularly.
  • Suppress lateral movement. Deny SMB / RDP between endpoints by default, randomise local administrator passwords with a LAPS-style solution, restrict the sources permitted to use WinRM / WMI remote execution, and apply network segmentation and host firewalls.
  • Protect credentials. Enable Credential Guard, disable WDigest where unnecessary, limit delegable accounts, and monitor for DCSync-style directory replication requests and anomalous Kerberos ticket requests.
  • Harden the service desk process too. In publicly documented cases, attackers bypassed technical controls by impersonating an employee on a call to the service desk and obtaining a password reset. Password resets and MFA re-enrolment need robust identity verification.
  • Take the backup estate out of the domain. Keep backup servers unjoined, with separate credentials and network, immutable backups enabled and an offline copy retained. Store domain controller system-state backups offline separately — they are the precondition for forest recovery.
  • Full EDR coverage with tamper protection. Watch especially for anomalous Group Policy changes, new executables in SYSVOL, bulk remote execution, shadow-copy deletion and antivirus uninstallation — the last signals before estate-wide deployment.
  • Drill AD recovery. Rehearse the forest recovery procedure in an isolated environment at least annually to prove backup usability and build operator fluency; doing it for the first time during a real incident is extremely costly.

Emergency response

Data already encrypted? Stop and let an engineer look first

We do not pay ransoms and we do not negotiate with attackers. Engineers run a free assessment first, then propose a recovery plan and a firm quote.

Related questions

Related industries

FAQ

Frequently asked questions

  • Hundreds of machines encrypted at once — how was that possible?

    Because the attacker held domain administrator rights and no longer needed to break into each machine. With legitimate administrative credentials they can use the very distribution mechanisms administrators use: Group Policy startup scripts or scheduled tasks, bulk remote execution via PsExec / WMI / WinRM, and software distribution systems. In the logs this closely resembles normal operations, which is why detection typically comes only once encryption starts. The chain is usually: initial foothold, escalation and credential harvesting, lateral movement, domain administrator rights, then delete backups, disable antivirus, clear logs, and deploy.

  • Is changing all the passwords enough?

    No. If the attacker obtained domain administrator rights and may have exported NTDS.dit, they hold more than cleartext passwords — they hold credential material for every account, including the krbtgt key, which can forge Kerberos tickets for any identity. A single password change does not invalidate such tickets. Proper remediation covers all users and administrators, service accounts, local administrators and computer accounts, plus a correctly executed double krbtgt rotation — alongside hunting for subtler persistence such as delegation settings, ACL backdoors and certificate services abuse.

  • Should we rebuild the domain? How do we decide?

    Three factors decide it: how deep the attacker's privileges went (was domain administrator genuinely reached), whether full-domain credentials may have been exported (NTDS.dit or DCSync indicators), and how intact the evidence is (were logs cleared, how long was the dwell time). Where all three point to deep privileges, probable full credential compromise and destroyed artefacts, cleanup cannot support a reliable eradication conclusion, and forest recovery from trusted offline backups or a clean new domain is safer. This should be a documented, evidence-based conclusion rather than a judgement call — our report sets out the evidence and the recommended route.

  • In what order should we recover?

    Identity first, data second. The recommended order: domain controllers, DNS and certificate services; then network and security infrastructure and the EDR management platform; then core databases; then business applications (ERP, OA, production systems); then endpoints. The reason is straightforward: bringing business systems back while AD is still unclean and credentials unreset lets the attacker repeat the exercise immediately with the credentials they already hold. Each batch must be cleaned and verified in an isolated segment before it joins the network, rather than going straight back online.

  • Should endpoints be cleaned individually or reimaged?

    In most cases reimaging. There are many endpoints, and hunting for persistence and verifying each one usually costs more than rebuilding, while still failing to support a confident "this is clean" conclusion — and attackers commonly leave different backdoors across several machines. A workable approach: extract local business data from endpoints in an isolated environment, then reimage in bulk from a standard clean image, joining the new or reset domain with fresh credentials and EDR policy. A small number of special cases — dedicated equipment, legacy systems — can be assessed individually.

  • Why was the backup server compromised as well?

    Because it sat inside the same trust boundary. In most environments the backup server is domain-joined, jobs run under domain accounts (sometimes domain administrators), and the repository is writable from production hosts. Once the attacker held domain administrator rights, all of that fell inside their reach, and deleting or encrypting the backups was a trivial extra step. The remediation is clear: keep the backup server unjoined, with its own credentials and network, make the repository unwritable from production, enable immutable backups and retain an offline copy — and store domain controller system-state backups offline separately, since they are the precondition for forest recovery.

Updated