Ransomware on the Teller Subnet

Sequence and rationale:

1. Declare a major incident and start an evidence log (0-15 min). Record who did what and when; image the EDR telemetry and SIEM logs before any reimage. Scope cannot be reconstructed later without this.
2. Contain identity first (15-60 min). Reset the krbtgt account twice, disable the 14 domain-admin accounts, rotate the backup service account and force a reset of all privileged credentials. Credential dumping on a teller subnet means the attacker can move laterally; identity is the fastest lever.
3. Isolate proportionally (60-120 min). Isolate the 40 encrypted file servers and the affected teller subnet, not all 1,100 branches. Full-branch isolation stops about 3,000 transactions an hour and is hard to justify while the vendor-hosted core is not shown to be compromised. Keep branch transaction processing and block lateral paths.
4. Hunt persistence (2-6 h). Check scheduled tasks, GPOs, new service accounts, remote-management tools and egress logs for the command-and-control channel.
5. Notify in parallel, not after. Vendor within four hours per contract (bank-side credentials were compromised), insurer within 24 hours, regulator and CERT-In per applicable directions.

Deliberately not yet: pay the ransom; wipe and reimage before imaging; restore from backup before verifying the backups are not encrypted or poisoned; send a customer-wide notice before scope is known.

This is not one analyst's error; it is a rule-design and governance failure.

• Rule design: the rule alerted only on external source IPs, so lateral movement from an internal teller subnet was invisible by construction. The use case was never validated against an internal-threat scenario.
• Tuning without adversarial testing: rules were tuned to reduce noise without a purple-team or red-team check that the tuning preserved detection.
• Closure process: a high-severity alert was closed without a documented rationale or peer review, and no metric tracked 'closed as benign' rates.
• Governance: no owner for detection coverage against a framework such as MITRE ATT&CK, and no board-level MTTD metric.

Fixes:

1. Rewrite the rule to trigger on credential-dumping behaviour regardless of source IP, plus user-and-entity behaviour analytics on privileged-account anomalies.
2. Mandatory closure codes and peer review for high-severity alerts; sample closed alerts monthly.
3. Quarterly purple-team exercises that measure detection, not only prevention.
4. Report MTTD, MTTR and false-negative test results to the risk committee.

The lesson: a quiet SIEM is not evidence of a safe network.

Notification order and reasoning:

1. Vendor (within 4 hours, per contract). Bank-side domain credentials were compromised and the vendor hosts core banking; the vendor must check for bank-originated access and may have contractual rights to isolate. Missing this is a contract breach independent of the incident.
2. Insurer (within 24 hours). The 24-hour clause is a condition precedent; late notice can reduce or void cover. Notify even though the loss is still being quantified.
3. Regulator and CERT-In (per applicable directions, typically 2-6 hours for a major incident). Ransomware affecting 40 servers is a reportable cyber incident. Do not disclose unverified attribution; state facts, containment and the customer-impact assessment.
4. Law enforcement. Report the extortion; this also creates a record if a ransom payment is ever considered.
5. Customers. Notify affected customers once scope is known, with specific guidance, not a generic advisory.

On paying: the decision belongs to the board with legal and sanctions advice. Payment does not guarantee decryption, may breach sanctions rules if the actor is listed, and funds further attacks. The technical priority is restoring from verified clean backups; the ransom decision should be made on that timeline, not under the attacker's clock.