INDUSTRY FACT FILE · CLOUD, DATA CENTRES & HOSTING

Five New Case Studies in Cloud and Data Centre Security

Original 2026 case studies, each written as a blog post, showing how current threats play out for infrastructure providers and how Codec Networks services break the attack chain.

In this document 1.  About these case studies 2.  Case Study 1: The Hypervisor Ransomware Weekend 3.  Case Study 2: The VPS That Attacked a Bank 4.  Case Study 3: The Out-of-Band Door Left Open 5.  Case Study 4: The Snapshot That Went Public 6.  Case Study 5: The Cooling System That Became a Cyber Incident

These five case studies were written for this document set and have not been published elsewhere. Each is a composite scenario combining attack techniques and control failures widely observed among cloud, data centre and hosting providers with the obligations that apply in India as of October 2026—in particular CERT-In's Directions, MeitY empanelment, customer regulators' cloud requirements and the DPDP framework.

Important disclosure The organisations described are fictional and the scenarios are illustrative. They are not accounts of real incidents, and they are not Codec Networks client engagements or claims of achieved outcomes. Their value lies in showing how connected weaknesses form an attack chain, which controls break it, and which services test those controls.

Case study	Provider type	Core threat	Regulatory lens	Primary bundles
1. The Hypervisor Ransomware Weekend	Managed hosting provider	Ransomware at the virtualisation layer	CERT-In; customer SLAs; DPDP	B3, B7, B8
2. The VPS That Attacked a Bank	VPS provider	Platform abuse with fake identities	CERT-In subscriber records; law enforcement	B4, B7, B2
3. The Out-of-Band Door Left Open	Bare-metal and GPU provider	Exposed BMC/IPMI interfaces	CERT-In; customer contracts	B1, B3, B7
4. The Snapshot That Went Public	Cloud service provider	Insecure defaults and customer misconfiguration	DPDP; shared responsibility; CERT-In	B2, B3, B6
5. The Cooling System That Became a Cyber Incident	Colocation operator	Facility BMS compromise	CERT-In; customer SLAs; safety	B3, B7, B10

The guest operating systems were fully protected. The attack happened underneath them.

At a glance
Organisation	A managed hosting provider (“Host A”) running several hundred customer VMs
Threat	Exploitation of an internet-reachable hypervisor management interface
Why it is new	Encrypting at the hypervisor bypasses guest security and hits every customer
Codec Networks services	Virtualisation hardening, SOC monitoring, incident response (Bundles B3, B7, B8)

The scenario

Host A's hypervisor management interfaces were reachable from the internet for convenience, and a published vulnerability had not been patched.

On a Saturday night attackers exploited it and encrypted virtual machine files directly on the hypervisors. Backups on the same management domain were deleted.

Hundreds of customer services went down at once. Host A had to report to CERT-In within six hours and manage hundreds of customer notifications.

Figure 8: Illustrative attack path for Case Study 1 and the controls that break it.

What went wrong

• Management planes were internet-reachable.
• Hypervisors were not patched promptly.
• Backups shared the hypervisor admin domain.
• Management-plane activity was not monitored.

The impact

Host A faced SLA penalties, customer departures and claims, and some customers faced their own reporting obligations.

The regulatory lens

• CERT-In Directions: incidents reported within six hours.
• Customer contracts and SLAs: availability, recovery and notification commitments.
• DPDP Act and Rules: customers' personal data safeguards and breach intimation once provisions commence.

How Codec Networks would help

Need	Codec Networks response	Bundle
Harden the layer	Virtualisation and management-plane review	B3
Watch the plane	24x7 management-plane monitoring	B7
Recover customers	Ransomware response and restoration support	B8

Key lessons Keep management planes off the internet. Patch hypervisors quickly. Separate backups from production admin. Monitor management-plane activity.

The servers were paid for. The identities were not real.

At a glance
Organisation	A VPS provider (“Provider B”) with self-service sign-up
Threat	VPS instances rented with fake identities to host bank phishing sites
Why it is new	Cheap, fast infrastructure is attractive to criminals
Codec Networks services	Onboarding and records review, abuse monitoring, portal testing (Bundles B4, B7, B2)

The scenario

Criminals signed up for dozens of VPS instances using stolen identity details and prepaid cards.

The servers hosted phishing pages impersonating a major bank and harvested thousands of customers' credentials.

Law enforcement requested subscriber records. Provider B struggled to produce validated details and had been slow to act on abuse reports.

Figure 9: Illustrative attack path for Case Study 2 and the controls that break it.

What went wrong

• Customer identity was not validated at sign-up.
• Subscriber records were incomplete.
• Abuse reports took days to action.
• No detection of phishing-kit hosting.

The impact

Provider B faced regulatory questions about CERT-In record duties, reputational damage and blocklisting of its IP ranges.

The regulatory lens

• CERT-In Directions: validated subscriber records retained for five years after cancellation.
• Law enforcement: lawful requests for subscriber information.
• CERT-In: reporting of phishing and related incidents within six hours where applicable.

How Codec Networks would help

Need	Codec Networks response	Bundle
Fix onboarding	Onboarding and subscriber-record gap assessment	B4
Spot abuse	Abuse and phishing-hosting detection	B7
Harden sign-up	Provisioning portal testing	B2

Key lessons Validate customer identity. Keep complete subscriber records. Act on abuse within hours. Detect phishing hosting proactively.

The attacker never touched the operating system.

At a glance
Organisation	A bare-metal provider (“Provider C”) renting GPU servers
Threat	BMC interfaces with default credentials reachable on a shared network
Why it is new	Out-of-band access gives control below every software defence
Codec Networks services	BMC and IPMI testing, segmentation review, monitoring (Bundles B1, B3, B7)

The scenario

Provider C's BMC interfaces sat on a network reachable from customer servers, and some still used default credentials.

A malicious tenant scanned the network, logged into other servers' BMCs and modified firmware settings, then wiped disks.

Several customers lost data and Provider C had to rebuild servers and prove the platform was clean.

Figure 10: Illustrative attack path for Case Study 3 and the controls that break it.

What went wrong

• No isolated out-of-band network.
• Default BMC credentials remained.
• BMC firmware was outdated.
• BMC access was not logged.

The impact

Provider C faced customer claims and lost trust in its multi-tenant bare-metal offering.

The regulatory lens

• CERT-In Directions: incidents reported within six hours.
• Customer contracts: isolation, security and data-protection commitments.

How Codec Networks would help

Need	Codec Networks response	Bundle
Test the BMCs	BMC and IPMI security testing	B1
Isolate management	Out-of-band network segmentation review	B3
Log access	Monitoring of out-of-band access	B7

Key lessons Isolate out-of-band management. Remove default credentials. Update BMC firmware. Log every BMC session.

The customer clicked 'share'. The console chose 'public'.

At a glance
Organisation	A regional cloud provider (“Cloud D”) serving SMEs and start-ups
Threat	A storage snapshot shared publicly because of a console default
Why it is new	Defaults decide outcomes for less experienced customers
Codec Networks services	Console and default review, configuration review, privacy support (Bundles B2, B3, B6)

The scenario

A customer shared a database snapshot with a support partner. Cloud D's console defaulted the share to public.

The snapshot contained customer personal data. Researchers found it and reported it publicly.

The customer and Cloud D disputed responsibility, and both faced questions about reporting.

Figure 11: Illustrative attack path for Case Study 4 and the controls that break it.

What went wrong

• Sharing defaulted to public.
• No warning for public resources.
• Shared-responsibility guidance was unclear.
• No posture alerts for customers.

The impact

Cloud D changed its defaults under public pressure; the customer faced data-protection exposure.

The regulatory lens

• DPDP Act and Rules: reasonable safeguards and breach intimation once provisions commence.
• CERT-In Directions: data leaks reported within six hours.
• Customer agreements: shared-responsibility terms.

How Codec Networks would help

Need	Codec Networks response	Bundle
Fix the console	Console and secure-default review	B2
Check configurations	Cloud configuration and posture alerting review	B3
Support privacy	Customer data handling guidance	B6

Key lessons Make private the default. Warn before anything goes public. Give customers posture alerts. Document shared responsibility clearly.

No server was hacked. They simply got too hot.

At a glance
Organisation	A colocation operator (“Colo E”) hosting BFSI and enterprise racks
Threat	Remote manipulation of the building management system through a phished vendor engineer
Why it is new	Facility OT is often outside the security team's view
Codec Networks services	Facility OT assessment, OT monitoring, facility exercises (Bundles B3, B7, B10)

The scenario

Colo E's BMS was supported remotely by a facilities vendor through a VPN account shared by several engineers.

Attackers phished one engineer, logged in and changed cooling setpoints overnight while suppressing alarms.

Halls overheated and customer servers shut down. Colo E faced a multi-customer outage and a safety investigation.

Figure 12: Illustrative attack path for Case Study 5 and the controls that break it.

What went wrong

• BMS was not segmented from vendor and corporate networks.
• Vendor access was shared and unmonitored.
• OT alarms could be suppressed remotely.
• Facility incidents were never exercised.

The impact

Colo E paid SLA penalties, BFSI customers informed their regulators, and Colo E rebuilt its facility security model.

The regulatory lens

• CERT-In Directions: incidents reported within six hours.
• Customer SLAs: availability commitments and penalties.
• Customer regulators: BFSI customers' outsourcing and resilience obligations.

How Codec Networks would help

Need	Codec Networks response	Bundle
Segment the facility	Facility OT and BMS assessment	B3
Watch the plant	OT and alarm monitoring	B7
Rehearse	Facility incident exercises	B10

Key lessons Segment facility OT. Give vendors named, monitored access. Protect alarms from tampering. Exercise facility incidents.

Contact Codec Networks Pvt. Ltd. New Delhi: 507, 5th Floor, New Delhi House, Barakhamba Road, Connaught Place, New Delhi – 110001 Gurugram: 707, 7th Floor, Silverton Tower, Golf Course Extension Road, Sector 50, Gurugram – 122018, Haryana Landline: 011 430 496 96 | 011 437 522 99   Mobile: +91 99716 76124 | +91 88007 88220 | +91 88003 31124 Email: mktg@codecnetworks.com   Web: www.codecnetworks.com