Tuesday morning in Madhapur, five encrypted laptops
The IT admin arrived at our store at 10:15 AM with five laptops in two laptop bags and a level of controlled calm that only comes from having already spent the previous night on the phone with the cloud security team. The startup — a Series A fintech in Madhapur ’s HITECH City corridor — had discovered the encryption at 7:30 AM when the first employee tried to open a project file and found it renamed to .lockbit3. By 8:00 AM all five Windows 11 Pro machines on the internal network had the same symptom. By 8:30 AM the IT admin had isolated all five machines from the network and filed the CERT-In incident report. By 9:00 AM they had confirmed the backup was intact on AWS S3 Object Lock and that the backup had not been encrypted (it was air-gapped from the local network). They needed the laptops cleaned and restored. That was our job.
The bench triage: hardware first, then software
Step 1 — USB boot verification on all 5 machines
The cardinal rule after a ransomware infection: never trust the installed OS for any diagnostic or data confirmation. A sophisticated ransomware variant may persist in the EFI System Partition or the Master Boot Record, surviving a standard format. We booted each laptop from a clean, write-protected Ventoy USB drive running a lightweight Linux live environment. From within Linux we could confirm: (1) each laptop’s SSD was detected and physically functional; (2) no unusual EFI partitions were present (LockBit 3.0 does not typically survive an EFI wipe, but we verified); (3) RAM tested clean on memtest86+ (ransomware does not persist in RAM as it is volatile, but we checked for any firmware-level tampering).
All five machines were physically and firmware-clean. The infection had been confined to the OS partition and had not achieved persistent BIOS/UEFI implant. This is the most common outcome for LockBit 3.0 (also called LockBit Black) — it is primarily a file-encryptor, not a firmware rootkit.
Step 2 — Forensic image before wipe
For incident evidence and potential law enforcement reporting, we used dd from the Linux live environment to create a forensic sector-by-sector image of each encrypted SSD to a dedicated evidence drive. This preserves the encryption state as evidence without keeping any device in an unusable state longer than necessary. The evidence images were handed to the IT admin on a separate encrypted drive for their incident file.
Step 3 — Secure erase and OS installation
Each SSD was securely erased using hdparm --security-erase at the firmware level — this overwrites all sectors including any areas LockBit might have placed secondary payloads. Windows 11 Pro was then installed clean from a verified Microsoft ISO. All 5 laptops were re-imaged and restored in 1 working day. The IT admin’s deployment scripts handled driver installation, application configuration, and MDM enrolment from the clean state. Data was restored from the AWS S3 Object Lock immutable backup at the office — that restore happened on their own network, not at our bench.
The CERT-In and RBI reporting timeline — what the IT admin handled correctly
The IT admin had already filed the mandatory CERT-In incident report within 90 minutes of detection — well within the 6-hour reporting window. The report correctly stated: date/time of detection (7:30 AM), ransomware variant (LockBit 3.0/Black, identified from the ransom note naming convention and file extension), systems affected (5 Windows 11 laptops, company domain), data types potentially compromised (the encrypted data included internal financial models but no customer PII), and actions taken (network isolation, backup verification, professional re-imaging).
The startup was not an RBI-regulated entity, so the specific RBI cyber incident reporting obligation did not apply — but CERT-In’s mandate applies to all organisations in India handling information systems. The IT admin was correct to file promptly. The common mistake is waiting until the incident is resolved before reporting — the 6-hour window starts at detection, not at resolution.
Invoice and the economics of immutable backup
Bench fee for 5-laptop triage, forensic imaging, secure erase, and Windows 11 re-imaging: ₹3,500 per device × 5 = ₹17,500. USB evidence drive: ₹1,000. Total: ₹18,500. The immutable backup that made restoration possible: an AWS S3 Object Lock bucket with 90-day retention and daily backups, costing approximately ₹1,200/month for their data volume. A backup investment of ₹14,400/year averted what could have been total data loss or a ransom payment request. For related OS installation service and data recovery service, see our pages.