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
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.
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.
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.
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.
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.
| Option | Preconditions | Notes |
|---|---|---|
| AD forest recovery from trusted backup | An offline system-state backup predating the attack exists | Follow Microsoft's forest recovery procedure, with a comprehensive credential reset and double krbtgt rotation |
| Clean and harden the existing domain | Attacker privilege depth was limited, artefacts are clear, and full-domain credential export can be ruled out | Viable where risk is low, but that conclusion needs real evidence behind it |
| Build a clean new domain and migrate | No trusted AD backup, or long dwell time with cleared logs and no way to prove eradication | Highest 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
- Some versions decryptable
LockBit
LockBit is one of the largest ransomware-as-a-service operations in the world. Despite the 2024 law-enforcement takedown it returned as LockBit 5.0, with working Windows, Linux and VMware ESXi payloads, and it remains one of the most frequently seen families in China.
- Some versions decryptable
Akira
Akira is a ransomware-as-a-service operation that emerged in March 2023, breaking in through VPNs without MFA and edge-device flaws, then encrypting Windows estates and VMware ESXi clusters under double extortion. CISA's November 2025 advisory update calls it an imminent threat to critical infrastructure.
- Some versions decryptable
Black Basta
Black Basta was a Conti-derived RaaS operation that emerged in April 2022 and affected more than 500 organisations, known for QakBot delivery and Microsoft Teams IT-impersonation social engineering. It disbanded in February 2025 after its internal chat logs leaked, though its tradecraft carried over to successors such as Cactus.
- No public decryptor
Medusa
Medusa appeared in June 2021 and shifted to a ransomware-as-a-service model from 2023, using the .MEDUSA extension and !!!READ_ME_MEDUSA!!!.txt note. It specialises in exploiting remote-management and file-transfer components such as ScreenConnect, Fortinet EMS and GoAnywhere, and applies pressure through a countdown clock with paid extensions.
- No public decryptor
RansomHub
RansomHub launched in February 2024 as a rebrand of Knight/Cyclops and rapidly absorbed affiliates from ALPHV and LockBit with a 90% revenue share, accumulating hundreds of victims within a year. Its infrastructure went offline in early April 2025 and the operation has been dormant since, with affiliates largely migrating to Qilin and DragonForce.
- No public decryptor
Play
Play (PlayCrypt / Balloonfly) has been active since June 2022 and is one of the few closed-group ransomware operations, recompiling its encryptor for every victim. It targets FortiOS and Exchange flaws, RDP and VPN, and maintains a dedicated ESXi encryptor. CISA counted roughly 900 victims as of May 2025, and public leak-site trackers list over 1,200 entries as of September 2026.
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
- First response
What should I do if I've been hit by ransomware?
Isolate first and keep the power on: unplug the network cable or turn off Wi-Fi, but do not reboot, format, delete the ransom note or contact the attackers. Then work in order: confirm it is ransomware and whether it is still spreading, preserve the note, encrypted samples and logs, identify the family, inventory backups and snapshots to assess recovery paths, and report the incident. Do not reconnect restored systems until the entry point is closed, credentials are rotated and backdoors are removed.
- First response
What should we do when a server is hit by ransomware?
Isolate first and do not reboot: cut the affected server off at the switch or in the cloud security group, but leave it running. Then snapshot or image the system and data disks, keep the ransom note and encrypted samples, and check read-only whether shadow copies, cloud snapshots and backups survived. If several servers are down, set a restore order by business dependency, and bring nothing back online until the entry point is closed and every credential has been changed. What can be recovered depends on the family, the encryption mode and the backups.
- Ransom & cost
Should we pay the ransom after a ransomware attack?
We advise against treating payment as the default, and we neither pay ransoms nor negotiate on anyone's behalf. Some organisations do pay, but payment guarantees neither a working decryptor nor deletion of stolen data, it often invites repeat extortion, and buying and moving cryptocurrency for a ransom carries legal and sanctions exposure in China and abroad. Identify the family and establish what backups, snapshots and database repair can recover before deciding anything.
- Aftermath
Why do we keep getting hit by ransomware, and how do we stop it for good?
Repeat infections are rarely bad luck; the previous incident was almost always left unfinished. The real entry point was never found or never closed, accounts, scheduled tasks, remote-access tools or web shells left by the attacker are still there, credentials were only partly changed, or systems were restored from backups that already contained the backdoor. Environments that paid, or whose access was resold, also get revisited. The fix follows an order: forensics to find the real entry point, a rebuild-or-clean decision, closing the entry and removing persistence, a full credential reset, then verified hardening and ongoing monitoring.
Related industries
Manufacturing Ransomware Response and Recovery
Ransomware in manufacturing hits information systems and production cadence at the same time: with ERP down there are no orders, with MES down there is no schedule, and an encrypted drawing library takes the process documentation for an entire product line with it. This page covers the asset profile, recovery priorities and targeted defences.
Healthcare Ransomware Response and Recovery
When a hospital is hit, registration, consultation, orders, billing, laboratory and imaging fail at the same moment and care falls back to paper. This page covers the healthcare threat picture, a recovery priority built around clinical continuity, and the handling of patient data and compliance obligations.
Financial Services Ransomware Response and Recovery
Financial and quasi-financial institutions face far stricter requirements on data integrity, transaction continuity and regulatory reporting than most sectors, so one ransomware event hits availability, customer trust and compliance simultaneously. This page covers the threat profile, a recovery approach centred on transactional consistency, and hardening priorities.
Government and Public Sector Ransomware Response
Public sector ransomware incidents run on three lines at once: service interruption, data security and mandatory reporting. When document circulation, archives and integrated service platforms stop, both public services and internal operations are affected. This page covers the handling sequence, reporting duties and hardening priorities.
Related services
Incident Response
Round-the-clock intake: contain first, preserve evidence second, recover third.
Attack Forensics & Attribution
Establish the intrusion path, timeline and impact — in a report usable for police reporting and compliance.
Data Recovery
Recovery beyond decryption: backup repair, database repair and remnant extraction.
Security Hardening
Close the handful of paths attackers actually use: exposure, weak credentials, patches, privilege, backups.
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