When Active Directory is gone, every authentication boundary in the estate is gone with it. The IR playbook that works in Indian BFSI is the one that assumes domain-wide compromise from minute one, maps every action to the CERT-In 6-hour reporting clock, and rebuilds the forest rather than cleaning it.
Across the last 24 months of DFIR engagements in Indian banking, NBFC and insurance environments, the pattern is recognisable. The intruder lands via a phishing payload or an exposed VPN appliance, gains initial AD foothold within 4-8 hours, escalates to Domain Admin via Kerberoasting or ADCS abuse inside 24-72 hours, and detonates either a ransomware payload or a data-exfiltration workflow at hour 96-120. By the time the SOC sees the first ransom note or the first regulator query, the attacker has had three to five days inside the forest. This post is the operational playbook our DFIR team executes against that timeline.
The regulatory clock you are running against
Before any technical phase, the legal/compliance clock starts the moment you have reasonable belief a reportable incident has occurred. For Indian BFSI, the relevant timers are: CERT-In 6 hours from awareness (Direction 20(3)/2022/CERT-In), RBI Master Direction on Information Technology Governance reporting windows for scheduled commercial banks, SEBI CSCRF for capital markets entities, and IRDAI for insurers. Customer / data-subject notification under DPDP §8(6) layers on top once the rules operationalise. A reporting decision made at hour 5 is not the same as one made at hour 7 — the difference is a regulatory finding.
Phase 1 · Detect & validate (hours 0-2)
Detection signals that have been reliable across our BFSI engagements: a sudden spike in 4769 ticket-granting-service tickets with unusual encryption types (Kerberoasting), 4624 logon events with high-privilege groups from non-administrative workstations, replication anomalies in Repadmin, or the appearance of accounts in Protected Users or Enterprise Admins outside of change-control windows. Once any one of these signals is corroborated by a second source (EDR alert, BloodHound delta, or a sysadmin's anomalous-behaviour report), the validation phase ends and Phase 2 begins.
- Snapshot the AD database (NTDS.dit) and SYSVOL on every domain controller before any change.
- Capture memory + disk image on the suspected initial-access host.
- Pull the last 30 days of 4624/4625/4768/4769/4776 logs from every DC and every Tier-0 host to cold storage.
- Disable replication-suspending operations only if the GRC lead has signed off — premature suspension destroys evidence.
- Open a dedicated war-room bridge; no work happens outside it until the incident closes.
Phase 2 · Contain (hours 2-12)
Containment in an AD-compromise scenario is not the same as 'isolate the workstation'. The intruder probably already has at least one of: a forged TGT (golden ticket), a KRBTGT hash, a DSRM password, a domain-joined attacker-controlled host, or a backdoored GPO. Containment means cutting all of these simultaneously, which in turn means cutting authentication for several hours. The decision to accept the operational impact rests with the CISO and the head of business operations.
| Containment action | Operational impact | When to execute |
|---|---|---|
| Reset KRBTGT password twice (with replication wait) | All Kerberos tickets invalidated, 6-12h auth disruption | If golden ticket suspected or DA compromise confirmed |
| Reset every Tier-0 admin credential | Tier-0 ops paused 2-4h | Always, once DA compromise confirmed |
| Disable / quarantine compromised workstation(s) | Affected user(s) offline | Immediately on detection |
| Isolate domain controllers from non-essential network | External auth disrupted | If lateral spread to multiple DCs |
| Revoke all certificates issued by ADCS in the suspect window | Some apps may break until reissue | If ADCS abuse (ESC1-ESC11) suspected |
| Disable replication temporarily | Domain partitioning risk | Only after evidence preserved + GRC sign-off |
Phase 3 · Eradicate (hours 12-72)
Eradication is where most BFSI IR engagements either succeed or quietly fail. The honest answer in 70% of AD-compromise cases we have handled in India is that complete eradication requires a forest rebuild. Cleanup approaches — purging suspected backdoors, resetting all credentials, removing rogue GPOs — have a high false-negative rate, and a re-compromise within 30-90 days is the typical outcome.
- Inventory every persistence mechanism the attacker could have installed: AdminSDHolder ACL modifications, malicious GPOs, hidden DCs, rogue ADCS certificate templates, SID-history injections, golden / silver tickets, DSRM accounts, SeEnableDelegation rights on user accounts.
- For each persistence class, run a detection sweep (PingCastle, BloodHound, Locksmith, ADCSExploit, Sharphound's most-recent dataset).
- Evaluate the cost of cleanup vs forest rebuild — across our BFSI engagements, the break-even is around 6-8 confirmed persistence findings.
- If forest rebuild is chosen, plan for a 4-6 week parallel-build window with a managed cutover.
- If cleanup is chosen, schedule a follow-up audit at day 30, day 60 and day 90 to detect re-compromise.
Phase 4 · Recover (week 1-6)
Recovery in BFSI is constrained by regulator expectations, customer impact, and the fact that core banking systems cannot be down beyond the regulatory tolerance. The recovery plan our team writes for Indian banks has three parallel tracks: business-continuity (keep critical banking functions operational on hot-standby), platform-rebuild (new forest, new naming, new tiering model), and trust-rebuild (regulator communications, customer notifications, board reporting).
Phase 5 · Lessons & hardening (week 6-12)
The post-incident review should land on the CISO's desk within 12 weeks of detection and feed into both the next RBI/SEBI cyber-resilience audit and the board's IT/Risk Committee report. The hardening backlog we typically deliver covers: Tier-0 isolation enforcement, ADCS template review (ESC1-ESC11 coverage), service-account inventory and gMSA migration, privileged-access workstation rollout, Just-In-Time admin via PAM, BloodHound + PingCastle baseline + monthly delta review, and EDR coverage on every DC and every Tier-0 host.
Common mistakes we see in Indian BFSI IR
- Resetting KRBTGT only once — golden tickets remain valid.
- Restoring DCs from backup taken after the attacker's foothold — re-infection guaranteed.
- Communicating the CERT-In report from a compromised mailbox — assume out-of-band comms from minute one.
- Allowing IT-Ops to 'clean up' before forensic imaging — evidence destruction.
- Treating the incident as IT, not as a board-level event — the M.D. should be briefed inside hour 4.
- Disclosing 'all clear' before the 30-day follow-up audit confirms it.
How Macksofy helps
Our DFIR practice delivers AD-compromise IR on a 24/7 retainer basis to Indian banks, NBFCs, and insurers, with a guaranteed 1-hour engagement SLA. Engagements cover the full five-phase playbook above plus the CERT-In and RBI/SEBI/IRDAI reporting workflow as a single deliverable. Macksofy is CERT-In empanelled. See /services/digital-forensics-incident-response for the engagement scope and /resources/active-directory-compromise-runbook for the operational runbook we publish openly.