British Library Ransomware Attack: Lessons for Security Leads

Short read

This post covers the British Library ransomware attack of October 2023, using the Library's own published review. It walks through how the Rhysida gang most likely got in through a server without MFA, the early alert that seemed resolved, the 440GB that left overnight and the destruction of servers that hampered recovery.

You'll find the lessons that matter most for security leads, from full MFA coverage and network segmentation to treating even a blocked alert as the start of an investigation, and how urgentic helps make sure every alert is investigated to a conclusion.

The British Library ransomware attack of October 2023 is one of the most openly documented cyber incidents a UK organisation has ever shared. In March 2024 the Library published Learning lessons from the cyber-attack, its own account of what happened and what it would do differently. This first Breach Breakdown walks through the British Library ransomware attack using that review, and asks what a security lead can take from it.

What happened

According to the review, on Saturday 28 October 2023 it became clear that the Library had been hit by a significant ransomware attack that compromised the majority of its online systems. The attack was claimed by the Rhysida ransomware gang. It exfiltrated data, encrypted or destroyed substantial portions of the server estate and locked all users out of the network.

The timeline in the review is worth reading closely:

• 25 October, 23:29: forensic analysis later found evidence of an external presence on the network, with the first evidence of movement around it at 23:32.
• 26 October, 01:15: the IT Security Manager was alerted to possible malicious activity by the Library's monitoring system, which had automatically blocked the suspect activity at 00:21. The block was extended, a vulnerability scan came back clean and no repeat activity was seen. The IT Infrastructure team investigated, found nothing obviously malicious, reset a password and unblocked the account later that day.
• 28 October, 01:30: Jisc, which provides the Library's internet access, later identified an unusually high volume of data traffic (440GB) leaving the estate. The Library equates this with the data the attackers stole.
• 28 October, 07:35: the intrusion was first identified as a major incident, when a member of the Technology team could not access the network. The Crisis Management Plan was invoked at 09:15.

In hindsight, the Library and its advisers believe the activity on 25 and 26 October was hostile reconnaissance before the main attack.

How the attackers got in

The review is careful to say the exact point of entry cannot be confirmed, because of the damage to servers and the attackers' anti-forensic measures. However, the first detected unauthorised access was at a Terminal Services server installed in February 2020 for trusted external partners and internal IT administrators.

That server was protected by firewalls and anti-virus software, but access to it was not subject to multi-factor authentication (MFA). The Library had rolled out MFA for cloud applications such as email and Teams, but had left connectivity to its own domain out of scope. The review considers the most likely source of the attack to be compromised privileged account credentials, possibly through phishing, spear-phishing or brute force, and says the absence of MFA likely contributed.

What was taken and destroyed

The review says the attackers copied some 600GB of files, just under half a million documents, including personal data of Library users and staff. Around 60% came from wholesale copying of Finance, Technology and People team drives; around 40% came from a keyword search for names such as "passport" or "confidential". The attackers also used native administration tools to create backup copies of 22 databases and remove them.

The most damaging part, in the Library's words, was the destruction of servers to inhibit recovery. Many ageing legacy applications could not be restored at all. The Library did not pay a ransom or engage with the attackers. The US CISA advisory on Rhysida gives wider background on the group's techniques.

The lessons for security leads

The review closes with 16 lessons. Several apply to almost any security team:

• Enhance network monitoring. The Library had modern tools, but its legacy network meant they could not fully monitor or protect it.
• Fully implement MFA on all internet-facing endpoints, including supplier access, regardless of the technical difficulty.
• Enhance intrusion response. The review says an in-depth security review should follow even the smallest signs of intrusion, because attackers can quickly establish persistence and evade routine precautions.
• Segment the network, because no perimeter can be made entirely secure.
• Practise continuity plans for a total outage, not just for individual systems.
• Aggregate low-level risk. Out-of-appetite risks were escalated, but the many smaller accepted risks were harder to see as a whole.
• Retire legacy technology, because legacy systems are not only hard to secure but extremely hard to restore.
• Prioritise recovery alongside security, since no security is perfect.
• Retain external security expertise on call for speed and depth in the first hours of an incident.

The alert that came early

The detail that stands out for anyone running security operations is the night of 26 October. The monitoring system did its job: it spotted and blocked suspicious activity, and a person was alerted. The follow-up was reasonable on its face, yet the activity that looked contained was, in hindsight, reconnaissance. Two days later 440GB left the building in the early hours of a Saturday.

That is why the Library's fourth lesson matters so much. A blocked alert is not the same as a finished investigation. The real question is what else that account, host or session touched, and whether the attacker is still present somewhere else. Answering it properly takes time, context across identity, endpoint and network data, and someone available both at 01:15 on a Thursday, when the first alert fired, and at 01:30 on a Saturday, when the data left.

This is the gap urgentic is built for. The urgentic platform gives teams a full SOC capability, from detection through investigation and response, around the clock. urgentic agents are specialist AI agents that triage, investigate and respond to alerts such as lateral movement and credential misuse in under three minutes, 24/7, against one shared investigation graph. Alongside them, OpenSIEM collects, correlates and searches logs in one common format, and urgentic purple runs scenario-based tabletop exercises of the kind that test a total-outage plan before it is needed.

None of that replaces the basics the Library lists, such as MFA, segmentation and retiring legacy systems. It addresses a different problem: making sure every alert, including the quiet one at one in the morning, is investigated to a conclusion rather than closed because it looked handled.

Why this review is worth your time

The British Library chose to publish a frank account so that others could learn from it. Few organisations do. For a security lead, it is a ready-made tabletop scenario: a third-party remote access server without MFA, an early alert that seemed resolved, a large overnight data transfer and a destructive attack on legacy infrastructure. Read the full review and ask how your own team would have handled each of those moments.