Full Report
Recently, the ICO fined Capita £14m for their Black Basta ransomware incident — the largest amount ever fined by the Information Commissioners Office. It ruled Capita were “negligent” when it comes to cybersecurity.They also noted that Capita bill themselves as a primary supplier to the UK government, and sell a Managed SOC (Security Operations Center) service — when the SOC was the primary failure identified in the report.The fine was originally supposed to be the maximum fine available under GDPR legislation… however this was reduced as, amongst other things, Capita couldn’t afford to pay that much money.I think it’s important to dig into what businesses can learn from the judgement, as it clues organisations into the ICOs thinking. This isn’t to say the ICOs judgement is bad. It isn’t — it’s really good, and actually holds an organisation to account publicly for negligent cybersecurity practices.Some brief backgroundI’d covered the Capita ransomware situation as it first unfolded extensively on this blog. In fact, many of the findings in ICO’s judgement back up my prior blogs on the situation, from April 2023:Black Basta ransomware group extorts Capita with stolen customer data, Capita fumble response.Russian hackers exfiltrated data from Capita over a week before outageI’d had to cover it extensively at the time as Capita tried to pretend it was a “technical issue” with “Microsoft 365” for days on end to customers, despite them knowing full well it was ransomware deployment and having a prior major security incident running at Capita in the background. They had specifically told customers — I was one at the time — that it was not security related. This was a lie.Capita’s CEO told The Times after the incident that their incident response “will go down as a case history for how to deal with a sophisticated cyberattack”.The TimesCapita’s CEO has since left the business, and Capita have the largest fine the ICO has ever imposed on any business. It will not go down as a case history for how to deal with a sophisticated cyberattack — in fact, the attack wasn’t sophisticated and Capita fumbled almost every element of preparation and response.Initial accessInitial access was via Qakbot, as detailed on my blog at the time:The ICO’s report on CapitaThe initial alerts for patient zero had terms like “Threat Alert High”, “Credential access” and “Lateral movement”:Capita’s internal SLA said they would pick up 95% of P2 alerts within 1 hour… however nobody responded to the alert for over 58 hours.The ICO note that in the prior 6 months, Capita had never met its SLA for P2 tickets in the SOC:It also notes only 1 SOC analyst was on shift at any one time for the duration of this 50+ hour period.Capita challenged this element of the fine, saying its internal SOC SLA targets are not within the ICOs remit to judge. It said it had set the targets high to encourage teams to meet them. The ICO disagreed it isn’t in their remit, and it marks the primary finding by the ICO regarding the fine.Capita also tried to challenge the idea the alert wasn’t actioned, saying Trellix’s EDR tool immediately contained the system. However, the ICO asked for evidence of this — given the lateral movement and domain administrator access — to which Capita did not provide evidence.The ICO also note their belief that the alert was miscategorised as a P2, and should have the highest priority available:Key learnings:If you set and measure internal SOC targets, you need to be able to meet them or risk regulatory fines, even if you disagree with said regulators.Classify CobaltStrike and other ransomware related tools to the highest alert classifications, and empower the SOC leadership to contain every system generating true positive alerts from the rest of the network.Properly investigate for all forms of lateral movement from any contained hosts — in particular, look for access to domain admin and service accounts.Loss of dataCapita had the data of over 6 million people exfiltrated. It does not know the exact details of this still.The data exfiltrated included:Criminal records checks. Sexual orientation. Political briefs. Biometrics. This is the definition of data that can cause harm.The ICOs report notes almost one terabyte of data was taken on March 30th, during a period of thing where Capita was already — unknown to customers — running a major cybersecurity incident:On Capita’s own website, 5 days later, Capita wrote “there is no evidence of customer, supplier or colleague data having been compromised.”, which was false.It also said the issue was “primarily impacting access to internal Microsoft Office 365 applications.” — which was also false, given by this point their internal Active Directory had been compromised and they’d lost access to every employee account and internal system.Update on cyber incidentYou may notice there’s a pattern here of sweeping things under the carpet from customers.The report notes that SystemBC was used for exfiltrating data, along with rclone (a data copy tool). It also notes BloodHound was deployed, an Active Directory tool to look for security flaws.The report ultimately finds Capita had failed to implement measures to prevent lateral movement and privilege escalation within its environment — more on this in a bit:One of the other findings is that although Capita claim none of the exfiltrated data was available on the dark web (this is false by the way, read my prior blog – The Times actually spoke directly to victims via data on BlackBasta’s portal) the ICO judges that the risk of harm was still present.The take away here is that paying the ransom (Capita quietly did) and then pretending the threat actor has deleted the data – Capita termed this “securing the data” – does not fly with the ICO. All that paying ransomware groups does is fund serious organised crime.Key learnings:Keep an eye on endpoint security alerts for suspect tools — for example, Microsoft Defender for Endpoint will alert for things like suspect usage of rclone out of the box.If you have capability, monitor for all unauthorised usage of rclone — in particular, rclone traffic to internet hosts.Ideally rclone shouldn’t travel straight out to the internet — you should have firewalls blocking it.If you collect firewall logs, look for suspect large volumes of data transfer.In the early days of a major cyber incident — this was really a crisis — do not attempt to describe it as an “IT issue” in public and to public, then try to blame Microsoft 365 via the media. Communicate updates directly, loudly from your own website — and flood the zone with your own comms if it looks to be a major media story.Do not declare “there is no evidence of customer, supplier or colleague data having been compromised” a week into the incident when you know this probably isn’t even true, it’s just asking for the statement to haunt you later.Paying ransomware groups does not remove liabilities around data exfiltration.VulnerabilitiesCapita said it used Nessus for vulnerability scanning of the business units which had personal data exfiltrated:It was unable to provide evidence the specifically impacted systems were ever penetration tested, nor evidence of internal audit of the security of those systems.In the years prior to the incident, the wider organisation did have multiple penetration tests which highlighted issues around Active Directory, for example from their own report:“There are no policies preventing domain admins logging onto standard member servers, which means users with effective domain administrative privileges can use their accounts to logon to member servers. This presents a risk that should a host be compromised; the attacker may be able to obtain the password hashes for a high privilege account and gain privileged access to the domain.”This was highlighted in multiple penetration tests as different findings over multiple years, but never remediated. This specific issue was the same technique the threat actor went on to use for lateral movement around the organisation.Key learnings:If you are storing vast amounts of personal data, it is not okay to just run a Nessus scan once a week.You need to penetrate test systems processing personal data, and have oversight with internal audit.If you have penetration tests run on Active Directory, you need to remediate findings.Overall learningsThe report is 136 pages long, and worth a read if you want to clue yourself into the ICO’s thinking:https://medium.com/media/a61c139ffa43ed651e748054de44abfc/hrefCyber incidents happen. Everybody understands that, including the ICO, who have been very fair over the range of judgements I’ve read over the years. Customers also largely understand, too.What’s important is the steps taken beforehand to prepare — from penetration tests to audits to crisis planning — and the steps taken to deal with the initial stages of the incident and to stop it spiralling.When you get into serious trouble, call in external help and listen to them.My overall take aways would be for organisations to concentrate focus on seven pillars:Have a properly staffed SOC with audited targets they can meet, and empower them to isolate systems at any sign of major trouble.Block all outbound internet access by default, then allow access as needed via web proxies or application aware firewalls. You don’t need random-server doing 1 terabyte of rclone traffic to a random internet host — stop drinking the zero trust Kool-Aid and block it by default, as the risk is too great.Identify systems processing and storing large volumes of personal data, and have external penetration testing of said systems.Microsoft Active Directory security can make or break your business. It needs to be robust. Have it tested by an external party, and fix findings.Have a workable crisis plan, including transparent comms to customers.Create a cybersecurity culture where, when people are aware of perceived risks, they have a route to raise them both casually and formally. Make it safe to call out when something doesn’t seem right.Lastly, pre-emptively and honestly test the plans and the technical controls. You will likely already employ people who can casually check if they can rclone out data from your network and run Bloodhound undetected, things like that.Overall, get the skeletons out of the closet and try to protect your customers from harm in a matter like you’d like to be protected.What organisations can learn from the record breaking fine over Capita’s ransomware incident was originally published in DoublePulsar on Medium, where people are continuing the conversation by highlighting and responding to this story.
Analysis Summary
# Incident Report: Capita Black Basta Ransomware & ICO Fine
## Executive Summary
Capita suffered a significant ransomware attack by the Black Basta group, resulting in the exfiltration of nearly one terabyte of sensitive customer data. The incident exposed severe negligence in their cybersecurity posture, particularly within their Security Operations Center (SOC), which failed to respond to critical initial alerts for over 58 hours. Consequently, the ICO imposed a record £14 million fine for negligence, highlighting failures in incident preparation, response, and post-breach communication.
## Incident Details
- **Discovery Date:** Initial alerts triggered detection mechanisms, but the formal incident response (beyond initial containment) was severely delayed.
- **Incident Date:** Data exfiltration occurred around March 30th (prior to wider outage/public acknowledgment).
- **Affected Organization:** Capita
- **Sector:** IT Outsourcing / Managed Services Provider (including UK Government contracts)
- **Geography:** UK
## Timeline of Events
### Initial Access
- **Date/Time:** Pre-outage period, alerts noted over 58 hours before action.
- **Vector:** Initial compromise was via **Qakbot** malware infection, leading to patient zero alert with terms like "Threat Alert High" and "Credential access."
- **Details:** Initial alerts suggesting credential access and lateral movement were categorized as P2 tickets. Capita's SOC SLA required response within 1 hour for 95% of P2 alerts, but the initial alert went unaddressed for over 58 hours, with only one analyst on shift during that period.
### Lateral Movement
- **Details:** Attackers achieved **domain administrator access**. The ICO noted failure in implementing controls to prevent lateral movement following initial compromise. Pre-existing, un-remediated penetration test findings related to lax domain admin logon policies directly facilitated this movement.
### Data Exfiltration/Impact
- **Details:** Confirmed exfiltration of almost one terabyte of data on March 30th. Data included highly sensitive categories such as criminal records checks, sexual orientation, and political briefs affecting over 6 million people. Attackers used tools including **SystemBC**, **rclone**, and **BloodHound** during the operation.
### Detection & Response
- **Detection:** EDR (Trellix) generated high-priority alerts ("Threat Alert High") that went unactioned for two days due to SOC staffing and SLA failures.
- **Response Actions:** Capita initially described the event publicly as a "technical issue" impacting Microsoft 365, which was deemed false. They later paid the ransom (quietly) in an attempt to "secure the data." The overall response was judged as fumbled, with initial communications being misleading to customers.
## Attack Methodology
- **Initial Access:** Qakbot infection.
- **Persistence:** Implied via established domain access.
- **Privilege Escalation:** Achieved domain administrator access, facilitated by unaddressed AD security weaknesses (e.g., allowing domain admins to log onto standard member servers).
- **Defense Evasion:** Not explicitly detailed, but the failure of the SOC to respond to initial alerts indicates successful evasion of timely intervention.
- **Credential Access:** Implied through Qakbot activity and subsequent privilege escalation.
- **Discovery:** Use of **BloodHound** to map Active Directory security flaws.
- **Lateral Movement:** Facilitated by domain admin access; specific techniques not fully detailed but reliant on poor internal security hygiene.
- **Collection:** Use of **rclone** for data staging/collection.
- **Exfiltration:** Use of **SystemBC** and **rclone** was noted for sending nearly 1TB of data out to the internet.
- **Impact:** Large-scale extortion/data theft, operational disruption, and significant regulatory penalty (£14m fine).
## Impact Assessment
- **Financial:** £14 million fine imposed by the ICO (reduced from the maximum GDPR fine). Potential costs associated with remediation and litigation unknown, plus business impact from the CEO departure.
- **Data Breach:** Exfiltration of nearly 1TB of data belonging to over 6 million individuals, including highly sensitive personal and criminal data. Capita falsely communicated no data compromise occurred shortly after the exfiltration.
- **Operational:** Significant disruption, leading to a public outage and loss of access to internal systems/M365.
- **Reputational:** Severe damage, evidenced by the record fine and public criticism of their handling, contrasting sharply with their CEO's initial claims of handling a sophisticated attack well.
## Indicators of Compromise
*Note: Indicators provided are tool names mentioned in the context, not actionable artifacts.*
- **Network/Behavioral:** Significant large-volume data transfer traffic originating from systems executing **rclone**. Unauthorised outbound **rclone** traffic to external hosts.
- **File/Utility:** Presence of **Qakbot**, **SystemBC**, **rclone**, or **BloodHound**.
## Response Actions
- **Containment:** The initial containment, possibly via Trellix EDR, contained the patient zero system, but this appears to have been insufficient or too late to stop lateral movement entirely before data staging/exfiltration.
- **Eradication/Recovery:** Capita paid the ransom, followed by recovery activities (unspecified).
- **Communication:** Initial response involved misleading statements to customers (blaming M365, denying data compromise), later necessitating significant reputational repair following the ICO ruling.
## Lessons Learned
1. **SOC Readiness is Regulatory:** Internal SOC Service Level Agreements (SLAs) are subject to regulatory scrutiny, especially if breached during an incident. Under-resourcing (e.g., one analyst on shift) for defined service levels is a major compliance risk.
2. **Prioritization Matters:** Alerts related to ransomware/credential access must be classified at the highest priority, overriding standard P2 classification if necessary.
3. **Ransom Payments vs. Liability:** Paying a ransom does not absolve an organization of liability concerning data exfiltration and regulatory notification requirements.
4. **Communication Credibility:** False or misleading initial public statements regarding the nature (technical issue) or scope (data compromise) of the breach severely amplified regulatory consequences.
5. **Remediate Known Risks:** Failure to remediate findings from previous penetration tests (especially highly critical AD flaws) directly contributed to the severity of the incident.
## Recommendations
1. **Audit SOC Capabilities:** Staff SOC functions adequately to meet self-imposed SLAs. Empower SOC leadership to override standard processes for high-severity threat alerts (e.g., CobaltStrike/Credential Access alerts).
2. **Network Segmentation/Blocking:** Implement strict default outbound firewall policies, blocking unusual utilities like **rclone** traffic destined directly for the internet, especially from internal servers processing sensitive data.
3. **Vulnerability Management:** Ensure systems storing vast volumes of PII/sensitive data undergo regular external penetration testing, not just automated scanning (Nessus). Critical findings, such as AD domain admin restrictions, must be prioritized and remediated immediately.
4. **Crisis Preparedness:** Develop and rehearse a transparent crisis communication plan that mandates accurate disclosure to customers regarding potential data impact early in the incident lifecycle.
5. **Active Directory Hardening:** Conduct frequent, independent testing on Active Directory security controls and ensure policies prevent high-privilege accounts from logging onto standard member servers.