Unit 12: Auditing and hardening · Lesson 7 of 7 · 18 min

Case file: the server left out of MFA

One remote access server excluded from MFA let a ransomware group into a national library. Find your exceptions.

mission

You are
You are auditing remote access.
Situation
The MFA policy and October's logons for the terminal servers are in /srv/cases/remote-access.
Goal
Find every exception, check whether it is still justified and who uses it.
Hand in
The exception, its age, and the accounts that rely on it.

case file

British Library Ransomware Attack

British Library · 2023

On October 28, 2023, the Rhysida ransomware group attacked the British Library, copying about 600GB of data (later leaked when the Library refused to pay) and encrypting or destroying servers. The first detected unauthorized access was on a Terminal Services server used by third parties and IT staff that lacked MFA. Although backups existed, legacy systems could not be restored, forcing a lengthy 'Rebuild & Renew' programme.

What went wrong

A remote access server excluded from the MFA rollout, a flat legacy network that prevented segmentation, and legacy applications that could not be restored from backup onto new infrastructure.

What would have stopped it

  • Enforce MFA on every remote access path, including third-party and administrator terminal servers.
  • Segment networks so remote access hosts cannot reach the whole estate.
  • Retire or plan migration for legacy systems, and test full restores onto new infrastructure, not just backup completion.
  • Investigate early warning alerts fully rather than relying on an automated block.

What defenders could have seen

  • Suspicious reconnaissance activity days before the attack (seen 25-26 October but not fully investigated).
  • Unusual logins on the third-party terminal server outside normal hours.
  • Large outbound data transfers from internal file servers.

sourcesbl.uksecurityweek.com

How an exception becomes a door

  1. Approved2021, with a review date
  2. Review missed2022 comes and goes
  3. Used dailyBy third parties without MFA
  4. Entry pointOne stolen password is enough
01

Read the policy

learner@root-lab
cat mfa-policy.yaml
policy: require-mfa
applies_to:
  - group: all-staff
  - group: it-admins
  - group: third-party-support
exclusions:
  - host: ts-legacy01
    reason: vendor application does not support the MFA agent
    approved: 2021-03-15
    review_by: 2022-03-15

you should see One host excluded since 2021, with a review date long gone.

02

Who logs in without MFA

learner@root-lab
grep -c mfa=skipped logons-2026-10.log
15
grep mfa=skipped logons-2026-10.log | grep -oE 'user=[a-z0-9.-]+' | sort | uniq -c
      4 user=it-k.lee
      3 user=it-p.shah
      2 user=vendor-acme1
      6 user=vendor-acme2

you should see Fifteen logons, most of them by third-party vendor accounts.

03

Compare with the other servers

learner@root-lab
grep -c 'mfa=ok' logons-2026-10.log
45

you should see Everyone else uses MFA. The exception is the weak point.

defender tip Every exception gets an owner, an end date and a compensating control such as a jump host with MFA in front.

An exception

As written
host: ts-legacy01
reason: vendor app
review_by: 2022-03-15

Expired review, used daily by outsiders

Managed
host: ts-legacy01
reach only via MFA jump host
owner: it-ops
ends: 2026-12-31

Still legacy, no longer a door

What a defender takes away

  1. 1Exceptions are where attacks start; list them first.
  2. 2Every exception has an owner and an end date.
  3. 3Third-party access deserves the strongest controls, not the weakest.

Questions

0 of 3 solved

Answer each one from what you find on your lab machine.