The AIIMS Delhi ransomware attack of 23 November 2022 took down the servers running the hospital's eHospital system, forcing India's premier government hospital into manual registration, paper-based billing, and disrupted outpatient and sample-collection services for roughly two weeks. It remains the most consequential publicly documented cyberattack on Indian healthcare infrastructure — and it is a case study every Indian hospital, clinic chain, and health-tech SMB should study line by line, because the failures that let it happen (poor network segmentation, single points of backup failure, delayed detection) are common, not exotic.
What Happened in the AIIMS Delhi Ransomware Attack: A Verified Timeline
Multiple official statements — including replies given in the Lok Sabha by the Minister of State for Health and Family Welfare and by then-Minister of State for Electronics and IT Rajeev Chandrasekhar — along with CERT-In's own assessment, establish the following sequence of events. Where reporting is unconfirmed or contested, it's flagged as such below rather than presented as fact.
| Date (2022) | Event |
|---|---|
| Nov 23 | Servers run by the National Informatics Centre for AIIMS Delhi's eHospital application went down around 7 AM; OPD, sample collection, and billing shifted to manual mode |
| Nov 24 | Delhi Police registered an FIR against unknown persons; the case was moved to the Intelligence Fusion and Strategic Operations (IFSO) cyber unit |
| Nov 25 | A complaint citing extortion and cyber terrorism was filed; a National Investigation Agency team visited AIIMS |
| Nov 28 | Roughly 1,200 of AIIMS's 5,000 computers had been sanitised and 20 of 50 servers scanned, as part of a round-the-clock cleanup |
| Nov 30 | AIIMS arranged replacement servers via DRDO to help resume the eHospital facility |
| Dec 6 | Trial runs of the restored eHospital server succeeded; officials said most lost data had been recovered |
| Dec 16 | In a Lok Sabha reply, the government confirmed eHospital data had been restored from backup onto new servers, with registration, appointment, admission, and discharge functions resumed |
How the Attackers Got In and Moved Laterally
Neither AIIMS nor CERT-In has publicly confirmed the exact initial access vector — whether phishing, an exposed remote service, or a compromised credential. What CERT-In's preliminary assessment did confirm publicly is that the servers were compromised due to inadequate network segmentation, which is precisely what let attackers move from an initial foothold to critical application, database, and backup servers rather than being contained to one isolated system.
Union Minister Rajeev Chandrasekhar told the Rajya Sabha that five AIIMS servers were affected, encrypting approximately 1.3 TB of data — out of a reported total of roughly 40 physical servers at the institute, per contemporaneous media reporting (the exact physical-versus-virtual server count was not itself part of the Parliament statement). Some technical reporting also referenced multiple malware families found on the compromised servers, though attribution to a specific ransomware group (media reports pointed toward LockBit, and separately, IP addresses in email headers traced to Hong Kong and China's Henan province) was never officially confirmed by Indian authorities.
The Ransom Demand: What's Confirmed vs. What's Contested
This is the part of the story where accuracy matters most, because figures circulated widely without official confirmation. Multiple outlets reported a very large cryptocurrency ransom demand attributed to the LockBit group, while a separate report cited a purported attacker email referencing a much smaller cryptocurrency-denominated figure. Against this, Delhi Police officials and India's national cybersecurity coordinator publicly stated that no ransom had actually been negotiated or specifically demanded through official channels, with one AIIMS official suggesting the actors may have been testing capability rather than running a structured extortion operation.
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanImpact on Patient Care and Hospital Operations
The operational consequence was immediate and severe, independent of the ransom question. With eHospital down, AIIMS Delhi — which handles a very high daily patient volume — had to run outpatient registration, sample collection, and billing entirely on paper for close to two weeks. Reports at the time raised concern about whether patient records had been exposed given the scale of data involved, though the precise scope of any data exfiltration (as opposed to encryption) was not conclusively established in public reporting.
The gap between "partial sanitisation" (day 5) and "confirmed full restoration" (day 23) is the real story for any organisation planning its own incident response: cleanup and rebuild, done properly, takes weeks — not the hours most continuity plans assume.
Who Investigated, and Why That Matters
The AIIMS incident wasn't handled by a single agency. Delhi Police's IFSO cyber cell registered and initially investigated the FIR; the National Investigation Agency sent a team within 48 hours; CERT-In conducted the technical assessment of the compromise; and the case was subsequently reported to have been taken up by the CBI given the critical-infrastructure and national-security dimensions of an attack on a central government hospital. This multi-agency involvement reflects how India treats attacks on healthcare and other critical information infrastructure — as both a cybercrime and a national security matter, not purely an IT outage.
Defensive Lessons for Indian Healthcare and SMBs
The AIIMS incident is unusually well-documented for an Indian breach, which makes it genuinely useful as a lessons-learned exercise rather than speculation. The gaps CERT-In and investigators pointed to map directly onto controls any healthcare provider or SMB can implement.
| Control Area | Gap Identified at AIIMS | Action for Indian Organisations |
|---|---|---|
| Network segmentation | Flat network let attackers reach app, DB, and backup servers from one entry point | Segment clinical, admin, and backup networks; enforce least-privilege between zones |
| Backup integrity | Main and backup servers were both affected by encryption | Keep offline or immutable backups isolated from the production network |
| Patching and hardening | Exact vulnerability unconfirmed publicly, but legacy/unpatched systems are a known healthcare-sector weakness | Maintain a patch cadence for internet-facing and internal critical systems; retire unsupported OS/software |
| Incident detection | Outage discovered only when services visibly failed at 7 AM | Deploy monitoring that flags anomalous encryption activity or mass file changes before full outage |
| Incident response plan | Manual failover took the hospital roughly two weeks to fully restore | Pre-define a manual-operations runbook and a tested restoration sequence, rehearsed, not assumed |
| Regulatory reporting | Multiple agencies engaged reactively after public disclosure | Have a CERT-In reporting workflow ready in advance, per the six-hour requirement |
Building Resilience Before the Next Incident
Healthcare data carries some of the highest sensitivity of any data category under India's DPDP Act 2023, administered by MeitY, and hospitals and health-tech platforms processing patient records should treat breach-readiness as a compliance obligation, not just an IT concern — see our DPDP compliance guide for how patient data handling and breach-notification duties intersect. For organisations without in-house incident-response depth, running structured penetration testing and exposure assessment on a regular cadence — ideally with a CERT-In empanelled partner where regulatory submission is required — closes exactly the kind of segmentation and patching gaps that turned a single compromised server into a two-week hospital-wide outage at AIIMS.
Bachao.AI, built by Dhisattva AI Pvt Ltd, runs continuous automated vulnerability assessment designed to surface these exposures — exposed services, missing segmentation signals, unpatched software — before an attacker finds them first. If your organisation handles patient or other sensitive personal data, get a free VAPT scan to see where your own network stands, or browse the Bachao.AI blog for more incident case studies and defensive guides.