Beaconing ATMs and an Encrypted Patch Server on Salary Week
An urban co-operative bank with 214 branches runs its SOC through an outsourced MSSP on a 24x7 retainer. At 02:10 on a Tuesday the MSSP escalates a medium-severity alert: 37 ATMs in the western zone are querying a domain registered 11 days earlier, with a fixed 60-second beacon interval. At 03:05 the regional data centre's patch-management server begins encrypting files and drops a ransom note demanding 40 XBT within 72 hours. Core banking runs on AIX and is unaffected; the ATM switch runs Windows Server 2012 R2 and sits on the same VLAN as the patch server. The cash and currency team warns that ATMs must stay online through salary week, which begins in 48 hours. The CTO wants an immediate restore from Sunday's tape backup. A board director messages the CISO asking whether the bank should engage a ransom negotiator to 'buy time'. CERT-In directions and RBI's cyber incident reporting requirements both apply, and the MSSP's contract has a four-hour escalation SLA that was met.
1. Set out the actions you would take in the first six hours, in order, and identify the single decision that most constrains everything else.
Read the worked answer
The first constraint is not technical: you cannot answer anything else until you know whether the ATM beaconing and the patch-server encryption are one incident or two. Same window, same estate - assume one until disproved.
Order of actions (0-6 h):
- Declare a major incident and convene the crisis team (CISO, CTO, operations, legal, communications, MSSP lead). One incident commander, one decision log.
- Preserve, then isolate. Capture volatile evidence from the patch server (memory, running processes, network connections) before shutdown; pulling the power destroys encryption keys and the persistence mechanism. Then quarantine the server's switch port and block lateral SMB/RDP.
- Segment the ATM estate - block the ATM VLAN from the corporate LAN and from the internet except the ATM switch; permit only switch-to-ATM transaction flows.
- Hunt the beaconing across all 214 branches, not just the 37; 37 is a detection floor, not a population.
- Test the backups before you need them. Sunday's tape is not a recovery plan until restored to an isolated environment and confirmed clean and complete.
- Rotate credentials for domain admin, service accounts and the patch server, and disable the MSSP's remote-access accounts until their access path is understood.
Why this order: containment decisions are commercially irreversible and must be taken on facts; eradication without evidence gives you a repeat incident a week later. Restoration is a late step, not the first one.
2. The ATM switch must remain reachable from the ATM network for cash dispensing but must not be reachable from the corporate LAN. Describe the isolation design, and say whether you would approve the CTO's immediate restore from Sunday's tape.
Read the worked answer
The availability pressure is real, but it is a business constraint, not a security one - the correct answer is partial containment, not a binary choice between full isolation and doing nothing.
Design:
- Put the ATM switch and the ATM VLAN in a dedicated security zone; the only permitted flows are ATM-to-switch transaction ports and switch-to-core-banking on fixed IP and port. Default deny.
- Remove the switch's internet access. If vendor remote support is needed, force it through a jump host with MFA and session recording, time-boxed.
- Restrict DNS to the bank's resolvers with a response-policy zone blocking newly registered domains; this kills the 60-second beacon without touching cash availability.
- Application whitelisting on the ATM kiosk software; USB and boot-from-media disabled.
The restore: correct only as a last resort, and only after three conditions - (a) the initial access vector is identified, (b) the persistence mechanism is removed, (c) credentials the attacker could have harvested are rotated. Otherwise the restored server is re-encrypted within days. Restore to an isolated VLAN, validate, then reconnect.
Judgement point: the CTO's instinct addresses recovery time, but restoring before eradication converts a contained incident into a repeat one, and the second encryption event will be harder to explain to the board than a delayed restore.
3. Advise the board director on the ransom negotiator, and set out the reporting obligations with timelines.
Read the worked answer
To the director: do not engage a negotiator to 'buy time'. Time is bought by containment and clean backups, not by a conversation. Say so in writing and route the question to the crisis team and legal. Payment does not reliably produce a working decryptor, it does not restore service, and it exposes the bank to sanctions screening and financing-prohibition risk under PMLA. If the board still wants a negotiator for intelligence purposes, that is a legal and insurance decision taken with law enforcement informed - not a CISO decision.
Reporting:
- CERT-In: under the 2022 directions, specified incidents including unauthorised access and data breach must be reported within 6 hours of noticing. The 02:10 alert started that clock - file a preliminary report and update it.
- RBI: cyber incidents are reported under the cyber-security framework within 2-6 hours of detection to the RBI nodal office, followed by root-cause analysis and a closure report.
- Police / cyber crime cell: file a complaint; it also supports the insurance claim and any later prosecution.
- Board: note within 24 hours. Customer communication only once data-exposure facts are known - do not speculate.
Judgement point: regulators prefer a preliminary report later corrected over a late complete one. Reporting runs in parallel with investigation, not after it.