The Glasgow City Council cyber attack of June 2025 is worth studying for one reason that most of the news coverage skipped: the servers at the centre of it were not the council's own. They sat inside the supply chain, managed by a third party, and they still produced an incident with the council's name on it, the council's residents affected and the council's regulatory obligations to meet.
That is the part worth your attention. If you run security for a local authority, an ALEO, an NHS board or a housing association, a meaningful slice of your external attack surface is operated by someone else, appears on none of your inventories, and is patched to somebody else's schedule. This article walks through how to find it, how to verify a clean forensic finding rather than take it on trust, and how to turn supplier assurance into something that runs continuously instead of once a year.
Working only from what has been publicly reported by the BBC, the council's own incident updates and FutureScot, the sequence is straightforward.
Malicious activity was identified on Thursday 19 June 2025 by CGI, the council's IT supplier. The affected servers were managed by a third party within the supply chain rather than by the council directly. Services were taken offline as a containment measure, and the disruption was not brief.
Residents felt it through the front door of the digital estate. Online forms stopped working, a range of council services became unavailable, and payments and applications were disrupted for weeks. The council advised residents to treat unsolicited contact with caution, which is the correct advice and, as this article covers later, the single most predictable follow-on risk after any publicised outage.
Later reporting recorded that an expert review found no evidence that customer data had been downloaded or encrypted, and Police Scotland subsequently reported no further lines of inquiry. Keep both findings in their proper frame. They are conclusions drawn from the telemetry that existed, reviewed by people who did the work properly. They are not the same as proof that nothing left the estate, and no competent responder would present them so.
One housekeeping point, because social posts blur it: this incident is distinct from unrelated council malware stories circulating online and from the separate disruption at Highland Council. Treat those as different events with different facts.
Outsourced services do not hide. They announce themselves in DNS, usually years before anyone writes them into an asset register.
You will see it as a delegated subdomain handed to a contractor, a CNAME pointing at a supplier's platform, a payments hostname resolving into a cloud tenancy nobody in the internal team provisioned, a schools portal answering on an IP range that belongs to a company rather than the council. The evidence is public. The gap is that nobody is looking at DNS as an ownership record.
The inventory mismatch does the rest of the damage. The authority-side CMDB records contracts, suppliers and service owners. It rarely records hostnames. The supplier's inventory records servers, tenancies and patch states, but not which authority's data sits on which box. Between those two views is a space where a citizen-facing form can run for six years without appearing on either side as a named, owned asset.
Then there is the accumulated sediment: consultation microsites from a 2019 campaign, a decommissioned service portal that still resolves, a regeneration project site built by an agency on a subdomain the digital team no longer thinks about. Shadow IT in the public sector is rarely rogue. It is usually a procurement that ended without a decommissioning step.
The consequence is the one Glasgow demonstrates. A compromise in a supplier estate lands as an incident in your name, with your residents making the calls and your team facing the UK GDPR Article 33 clock to notify the ICO within 72 hours.
Do not start from the contract register. Start from DNS and certificate transparency, because those show what exists rather than what was procured.
Enumerate every subdomain across your primary domains and your ALEO and arms-length brands, then resolve each one and record where it actually points. Anything landing outside your own IP ranges is a supplier-operated asset until proven otherwise. Certificate transparency logs are particularly useful here, since every publicly trusted certificate issued for your domains is logged, including the ones a contractor requested without telling you. A large authority with planning, licensing, payments, schools, libraries and housing brands will routinely surface dozens of hostnames the central IT team cannot immediately account for.
Then do the step that matters more than the count.
A bigger asset list is not progress. An asset list where every entry answers two questions is progress: is this internal or externally hosted, and which supplier is accountable for patching it? Without that second field, a critical CVE announcement turns into a week of emails establishing who owns the box. DarkInvader's asset discovery maps the full external footprint from an attacker's perspective and visualises assets geographically, which tends to expose hosting relationships nobody remembered signing.
Public sector web forms are the highest-value data collectors on a council estate. Blue badge applications, housing benefit evidence, school placement requests, licensing submissions, complaint intake with file upload paths attached. They are also, very often, hosted outside the main CMS by a contractor on a platform chosen for its form builder rather than its security posture.
That is precisely why Glasgow's public advice focused on data submitted through forms while they were unavailable. Enumerate forms and upload endpoints separately, record what personal data each one collects, and record who hosts it. If your inventory stops at "www", you cannot answer the only question a committee will ask.
Shared supplier hosting is a duplicate-finding machine. One weak TLS configuration or one outdated component on a platform serving forty client hostnames produces forty findings. Run dual scanning across infrastructure and web applications, but insist on deduplication and auto-resolution when the underlying issue is fixed. Remediation queues that repeat the same issue across a shared host bury the one genuinely novel exposure, and that is the one that gets exploited.
A clean forensic finding is a point-in-time statement about available logs. If egress logging was partial, if the supplier's retention was 30 days, if the compromised box sat outside central monitoring, then "no evidence"describes the quality of the telemetry as much as the behaviour of the attacker. The honest formulation is the one responders use internally: nothing observed so far, monitoring continues.
So keep monitoring, and keep it running for months rather than until the press interest fades. Stolen data frequently surfaces long after an incident is formally closed.
Handle unverified claims carefully. Attackers and resellers recycle old datasets and misattribute victims constantly, and a briefing to elected members based on an unvalidated forum post is worse than no briefing at all. Collect the evidence, validate a sample against something only you could confirm, and record what you checked. OSINT and dark web monitoring that combines automated collection with human research is what makes this workable, because the step tooling alone usually misses is the connective one: seeing a subcontractor's name in a Telegram post and recognising that the same company operates three hostnames inside your own footprint.
Publicised outages create close to ideal phishing conditions. Residents already expect contact about disrupted benefits, council tax, school payments or a form that failed to submit. A message offering to resolve it lands on prepared ground, and the council's own phone lines are busy.
Domain surveillance is the practical control. Watch for newly registered and newly available domains that mimic council service names, homoglyph variants and the payment brand permutations attackers reach for first. When one appears, you want an end-to-end takedown process with evidence collection, screenshots, registrar and host contact, and a record of the timeline. An awareness email to staff does nothing about a domain targeting 600,000 residents.
Named individuals need separate cover. Once an incident is in the press, the chief executive, the section 95 officer, the head of IT and elected members become spear-phishing targets, and their exposed personal details make that easier. Our guide to who to include in executive monitoring and the mistakes that leave leaders exposed covers the selection criteria in detail.
On comms, three things help more than anything else: publish one authoritative status page and point every channel at it, state plainly which channels you will never use to contact residents (for example, that you will never text a payment link), and date every update. Undated updates during a multi-week outage destroy trust faster than the outage does.
Annual questionnaires are not assurance. They are a record that someone answered questions once, about a scope you probably did not read closely.
Certificates get read far too generously in public sector procurement. A supplier can hold an entirely valid ISO 27001 certificate whose scope statement covers their head office ISMS and their primary data centre, while the subcontracted hosting platform that actually holds your citizen data sits outside it. Ask for the scope statement every time. Track scope alongside expiry date, because accreditation tracking that only records renewal dates tells you nothing useful.
The same discipline applies to Cyber Essentials Plus and to the NCSC Cyber Assessment Framework when it appears in contract requirements. Which systems were in the assessment boundary? Were the subcontractors?
The realistic failure mode looks like this. A contract covers "hosting and support"and names no hostnames. The supplier's subcontractor is compromised at 09:00. Neither party can say within the hour which citizen-facing services or datasets are in the blast radius, and the Article 33 clock is already running.
Three fixes address most of it. Attach a named asset list to every contract and require it to be updated when anything changes. Set a supplier notification window that leaves you enough time to assess and report to the ICO inside 72 hours, which in practice means hours, not days. Rehearse an incident jointly with the supplier's responders at least annually, because the first time you exchange phone numbers should not be during containment.
Continuous supplier oversight means threat scoring that updates, exposure alerts on supplier-owned assets inside your footprint, and automatic reassessment when a supplier appears in the news or on a leak site. Pair that with ongoing asset monitoring so changes in your external estate are caught as they happen rather than at the next audit.
Reporting should survive scrutiny from people who are not technical. Weekly "what's changed"summaries for the security team, management-level reports a committee can follow, and alerts routed into Slack, Teams, Jira or your SIEM so a finding becomes a ticket with an owner rather than an email that gets read on a train. If your supplier oversight cannot produce a dated record of what you knew and when, it will not stand up after an incident.
As publicly reported, malicious activity was identified on Thursday 19 June 2025 by CGI, the council's IT supplier, affecting servers managed by a third party within the supply chain. Services were taken offline to contain it, and online forms along with several council services were unavailable for weeks. Later reporting recorded an expert review finding no evidence that customer data had been downloaded or encrypted, and Police Scotland subsequently reported no further lines of inquiry.
Public reporting states that the expert review found no evidence of data being downloaded or encrypted. That conclusion reflects the telemetry available to the investigators, which is not the same as proof that nothing was taken. The responsible position after any incident of this type is to keep leaked-credential, stealer log and dark web Telegram channel monitoring running for months, because stolen data often appears on forums and channels well after an investigation closes.
The technical detail of the intrusion has not been published, and this article does not speculate about it. What was confirmed is that the affected servers were managed by a third party in the supply chain rather than by the council directly. Supplier-operated assets typically sit outside internal asset registers and internal patching schedules, which is why ownership classification across your external footprint matters more than the size of your asset list.
Unsolicited contact claiming to relate to council services, payments or disrupted applications, in line with the council's own advice. Treat any message containing a payment link or requesting personal details with suspicion, and verify by managing to the official council website directly rather than following links. Lookalike domains and phishing attempts typically increase after an outage receives press coverage.
Map your external attack surface from the attacker's side first, using DNS enumeration and certificate transparency to find every hostname that resolves, including those hosted by suppliers. Record which supplier is accountable for patching each asset, inventory every public web form and upload path separately, and replace annual questionnaires with continuous supplier monitoring and named asset lists in contracts. Speak to the DarkInvader team if you want to see what your external footprint looks like before an attacker maps it for you.
Unlock full visibility of your external attack surface with DarkInvader’s continuous, real-time monitoring. Create your free account to discover unknown assets, detect emerging risks and stay ahead of potential threats before attackers can exploit them.
Create My Free Account
Platform 7D, New Station Street, Leeds,
LS1 4BT, United Kingdom
Mon-Fri, 9:00-17:00
Contact:
sales@darkinvader.io
+44 (0)1138805336
Last updated: 14 August 2026
©2026 DarkInvader, All Rights Reserved
