INDUSTRY FACT FILE · GOVERNMENT, PSUS & PUBLIC DIGITAL SERVICES

Five New Case Studies in Government and Public Sector Security

Original 2026 case studies, each written as a blog post, showing how current threats play out in public hospitals, municipal portals, central PSUs, government technology providers and state data centres, and how Codec Networks services break the attack chain.

In this document 1.  About these case studies 2.  Case Study 1: The Hospital That Went Back to Paper 3.  Case Study 2: The Certificate Portal That Said Too Much 4.  Case Study 3: The Circular That Was Not From the Ministry 5.  Case Study 4: One Vendor Account, Twelve Portals 6.  Case Study 5: The Night Forty Websites Were Defaced

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 in government and public-sector organisations with the obligations that apply in India as of October 2026—in particular CERT-In's Directions, its Guidelines on Information Security Practices for Government Entities and its 2025 audit policy, NCIIPC duties for protected systems, GIGW 3.0, the DPDP Act and Rules and the tender and contract terms under which public systems are built and run.

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	Organisation type	Core threat	Regulatory lens	Primary bundles
1. The Hospital That Went Back to Paper	State government teaching hospital	Ransomware through vendor remote access and a flat network	CERT-In Directions and 2023 guidelines; DPDP	B3, B7, B8
2. The Certificate Portal That Said Too Much	Municipal services portal	Citizen data exposure through an API authorisation flaw	DPDP; GIGW 3.0; CERT-In	B2, B1, B6
3. The Circular That Was Not From the Ministry	Central public-sector enterprise	Spear-phishing and state-linked espionage	CERT-In; NCIIPC if notified; SEBI LODR	B7, B10, B8
4. One Vendor Account, Twelve Portals	Government technology provider	Supply chain compromise of a shared deployment server	Contracts; CERT-In guidelines; DPDP	B9, B2, B7
5. The Night Forty Websites Were Defaced	State data centre	Hacktivist defacement and DDoS against legacy websites	CERT-In; GIGW 3.0; state IT policy	B1, B7, B10

The vendor needed to connect once a month. The port stayed open all year.

At a glance
Organisation	A state government teaching hospital (“Hospco A”) with outpatient, inpatient, laboratory and billing systems on its own servers
Threat	An internet-exposed remote-desktop port left open for a vendor, a weak password and a flat network that let ransomware reach every server
Why it is new	Hospitals cannot stay offline, so they are prime ransomware targets
Codec Networks services	Segmentation and remote-access hardening, managed SOC, ransomware response (Bundles B3, B7, B8)

The scenario

Hospco A's hospital information system had been built and supported by a private vendor that connected remotely once a month to apply updates. To make that easy, a remote-desktop port on one application server had been opened to the internet with a shared administrator password that had not changed in years.

Attackers found the port in an internet-wide scan and guessed the password. Because the hospital network was flat, the same administrator account reached the laboratory, radiology, billing and backup servers. Over a weekend they disabled antivirus, deleted online backup copies and encrypted every server they could reach.

On Monday morning registration counters could not issue numbers, laboratory reports could not be printed and doctors went back to paper. Hospco A reported to CERT-In, called in forensics and restored from an older offline copy found at the vendor's office. Full services took eleven days to return, and questions in the assembly followed.

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

What went wrong

• Remote desktop exposed to the internet with a shared, unchanged password.
• Flat network with no separation between clinical, administrative and backup zones.
• Online backups reachable and deletable by the same administrator account.
• No 24x7 monitoring to catch the weekend intrusion.

The impact

Hospco A ran on manual processes for eleven days, delayed treatment and reports, faced legislative questions and audit observations, and rebuilt its network with segmentation, vendor access controls and monitoring.

The regulatory lens

• CERT-In Directions: incident reported within six hours of noticing it; 180-day logs needed for the investigation.
• CERT-In guidelines for government entities: CISO accountability, third-party access controls, audits and backups.
• DPDP: patient personal data on the encrypted servers assessed for exposure; intimation duties once provisions commence.

How Codec Networks would help

Need	Codec Networks response	Bundle
Close and zone the network	Remote access only through MFA and a jump host; clinical, admin and backup segmentation	B3
Watch the weekend	EDR and 24x7 SOC alerts on lateral movement, backup deletion and mass encryption	B7
Recover and explain	Ransomware response, forensics, restore planning and CERT-In reporting support	B8

Key lessons Never expose remote desktop to the internet. Separate clinical, admin and backup zones. Keep one backup copy offline and tested. Monitor nights and weekends, not office hours.

Every request came from a logged-in user. None of them owned the records they asked for.

At a glance
Organisation	A state urban development agency (“Cityco B”) running a portal for birth, death and marriage certificates and property tax across its towns
Threat	An API that returned any certificate or tax record when a sequential application number was changed, exploited by automated scraping
Why it is new	Authorisation flaws in citizen APIs expose whole databases without any break-in
Codec Networks services	Application and API security audits, infrastructure testing, DPDP programme (Bundles B2, B1, B6)

The scenario

Cityco B had launched a new mobile app for its certificate and property tax portal. The app called a set of APIs that checked whether the user was logged in, but not whether the application number in each request belonged to that user. The web portal had been audited before hosting; the new APIs had not.

A scraper registered an ordinary account and wrote a script that counted through application numbers. Over three weeks it downloaded lakhs of records containing names, addresses, parents' names, phone numbers and property details. The data was offered for sale and used for fraud calls claiming to be from the municipal office.

A journalist's query and a CERT-In notification arrived the same week. Cityco B took the app offline, commissioned an urgent audit, fixed the APIs and issued public advisories, while citizens' complaints about fraud calls continued for months.

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

What went wrong

• No object-level authorisation on API requests.
• New APIs went live without an audit after the web portal was cleared.
• No rate limiting or bot detection on citizen endpoints.
• APIs returned more data than the app needed.

The impact

Cityco B suspended the app, handled public criticism and citizen complaints, faced audit observations and committed to testing every release and minimising the data returned by its APIs.

The regulatory lens

• DPDP: citizen personal data processed by the State for services must follow the Rules' standards and safeguards; breach intimation duties once provisions commence.
• GIGW 3.0: cybersecurity requirements for government websites and apps, alongside a separate application security audit.
• CERT-In Directions: data exposure reported within six hours of noticing it.

How Codec Networks would help

Need	Codec Networks response	Bundle
Test every release	Web, mobile and API security audits before hosting and after every change	B2
Find the exposure	External attack-surface review and rate-limit and bot-control testing	B1
Return less data	DPDP data minimisation review, data map and breach workflow	B6

Key lessons Check ownership of every record requested. Audit new APIs, not just the website. Rate-limit and monitor citizen endpoints. Return only the data the screen needs.

The circular looked exactly like the last one. The domain was one letter different.

At a glance
Organisation	A central public-sector engineering enterprise (“Psuco C”) designing and building large infrastructure projects
Threat	Spear-phishing using a fake ministry circular from a lookalike domain, a backdoor on an engineer's laptop and months of quiet exfiltration of drawings and tender documents
Why it is new	Espionage actors imitate official correspondence because officials are expected to open it
Codec Networks services	SOC threat hunting, phishing simulation, compromise assessment and forensics (Bundles B7, B10, B8)

The scenario

Engineers at Psuco C received an email titled as a ministry circular on project reviews, sent from a domain that differed by one letter from the real one. The attached document asked the reader to enable content to view a table. One engineer did, and a small backdoor was installed on his laptop.

Over the following months the attackers harvested email credentials, mapped the project file servers and copied drawings, bid documents and correspondence in small, regular transfers that looked like normal traffic. Nobody was hunting for beaconing to unfamiliar servers.

The first sign came from outside: CERT-In alerted Psuco C that one of its addresses was communicating with a known command server. A compromise assessment found the backdoor on several machines, and the enterprise had to assess what had been taken, report the incident and brief its Board and ministry.

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

What went wrong

• No lookalike-domain blocking or strong email authentication checks.
• Macros allowed in documents from the internet.
• No threat hunting for beaconing or slow exfiltration.
• No realistic phishing training for engineers and officials.

The impact

Psuco C lost sensitive project and tender information, spent months on investigation and clean-up, briefed its Board and ministry, considered disclosure duties and rebuilt its email and endpoint defences.

The regulatory lens

• CERT-In Directions: incident reported within six hours of noticing it; logs needed for the investigation.
• NCIIPC: if any affected system is a notified protected system, NCIIPC guidance and reporting apply.
• SEBI LODR (if listed): cyber incidents disclosed in the quarterly corporate governance report.

How Codec Networks would help

Need	Codec Networks response	Bundle
Hunt the intruder	SOC threat hunting for beaconing, credential misuse and exfiltration	B7
Train the target	Spear-phishing simulation with realistic official lures for officials and engineers	B10
Scope the loss	Compromise assessment, forensics and reporting support	B8

Key lessons Block lookalike domains and macros from the internet. Hunt for quiet beaconing, not just alerts. Train officials with realistic official lures. Assume someone else may spot you first.

Twelve departments had twelve portals. They all trusted one developer's password.

At a glance
Organisation	A system integrator (“Infraco D”) that builds and hosts portals for twelve departments of a state government
Threat	A developer's reused password giving access to a shared deployment server, followed by a web shell planted in a common code library used by every portal
Why it is new	One vendor's weakness becomes every department's incident
Codec Networks services	Third-party risk, secure development and code review, managed SOC (Bundles B9, B2, B7)

The scenario

Infraco D used a shared deployment server and a common code library for all twelve department portals it maintained. Developers logged in with passwords and no MFA. One developer reused his password on a personal account that had been exposed in an unrelated breach.

Attackers used the password to log into the deployment server, added a web shell to the common library and waited for the next routine release to push it to every portal. Within days they had copied applicant data from several departments and defaced three homepages with political messages.

Departments suspended services and asked Infraco D for evidence of its controls. The state IT department invoked audit rights, required every portal to be retested before going back online and began reviewing the contract and the vendor's access across government.

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

What went wrong

• No MFA on developer and deployment accounts.
• Shared code and servers with no integrity checks.
• No vendor audits or security clauses enforced in the contract.
• No monitoring of web shells or changes to production code.

The impact

Infraco D faced contract penalties and the risk of losing its government business, departments suspended services and notified affected applicants, and the state adopted vendor security audits and code-integrity checks.

The regulatory lens

• Contracts and tender terms: security, audit, reporting and penalty clauses invoked by the departments.
• CERT-In guidelines for government entities: controls on third-party access and outsourcing; incidents reported within six hours under the Directions.
• DPDP: applicant personal data processed for the State by a vendor; safeguards and breach intimation once provisions commence.

How Codec Networks would help

Need	Codec Networks response	Bundle
Audit the vendor	Third-party security assessment and enforceable contract clauses	B9
Secure the pipeline	Secure SDLC, code review and integrity checks on shared libraries	B2
Spot the shell	SOC monitoring of web shells, admin activity and code changes	B7

Key lessons Require MFA for every vendor and developer. Check the integrity of shared code before release. Audit vendors, not only their deliverables. Monitor production for unexpected changes.

Most of the sites had not been updated in years. Some belonged to schemes that had ended.

At a glance
Organisation	A state data centre (“Dataco E”) hosting several hundred department, district and scheme websites on shared infrastructure
Threat	A hacktivist campaign exploiting known flaws in old content-management systems to deface forty websites overnight, combined with a DDoS on the main state portal
Why it is new	Forgotten websites give hacktivists easy, highly visible targets during tense events
Codec Networks services	External exposure assessment, managed SOC with defacement and DDoS monitoring, crisis exercises (Bundles B1, B7, B10)

The scenario

Dataco E hosted hundreds of websites built over fifteen years by different departments and vendors. Many ran old versions of content-management systems; some belonged to schemes that had ended, and nobody could say who owned them. There was no complete inventory.

During a tense national event, a hacktivist group announced a campaign against government websites and scanned for known flaws. Overnight it defaced forty sites hosted at Dataco E with propaganda, while a DDoS made the main state portal unreachable during the busiest morning hours.

Screenshots spread on social media before the data centre team was awake. Sites were taken offline one by one, restored, patched and audited before returning, the incident was reported to CERT-In, and the state ordered a review of every hosted site.

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

What went wrong

• No inventory or ownership of hosted websites.
• Old CMS versions left unpatched for years.
• No defacement or DDoS monitoring outside office hours.
• No crisis playbook for public communication.

The impact

Dataco E took dozens of sites offline, faced public embarrassment and misinformation, spent weeks restoring and auditing sites, and decommissioned more than a hundred orphan websites.

The regulatory lens

• CERT-In Directions: defacement and DDoS are reportable incidents, to be reported within six hours of noticing them.
• GIGW 3.0: lifecycle management and cybersecurity requirements for government websites, including timely updates and decommissioning.
• State IT policies: hosting conditions and security audit requirements for sites in the state data centre.

How Codec Networks would help

Need	Codec Networks response	Bundle
Find every site	External attack-surface inventory, vulnerability scans and decommissioning plan	B1
Watch all night	24x7 defacement, DDoS and web-attack monitoring with alerting	B7
Rehearse the morning	Crisis exercise on defacement and DDoS with communication playbooks	B10

Key lessons Keep an owner for every hosted website. Retire sites when schemes end. Monitor defacement and DDoS around the clock. Prepare public messages before you need them.

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