Last week the Information Commissioner's Office reprimanded two organisations over a ransomware attack in November 2024. One was a Welsh public-sector data body. The other was the IT provider that ran part of its network. The way in was an account called Test2. It had existed for more than twelve years, and for all of that time its password was Password1.
The attackers encrypted 182.7GB of data and took 42GB. The stolen data included personal information about roughly 3,300 people, most of them children, from two projects supporting children and families.
The headline writes itself, and the ICO's line ("Password1 is not an appropriate password, it is a wide-open door") is a good one. But "use better passwords" isn't the lesson. The more interesting finding is that the regulator reprimanded both parties, for different failures, and that neither of them could say clearly who owned the account.
What the ICO actually found
The IT provider created the account. The ICO found it used a weak password, didn't enforce adequate password rules, didn't regularly audit the accounts it created, and left local administrator accounts with unchanged passwords for over twelve years.
The data controller owned the network. The ICO found it had no compliant data processing contract with the provider, that responsibility for the Active Directory services was unclear, that it never removed the dormant account, and that its account reviews were ad hoc and incomplete.
Put those together and you get the real problem. The provider made the account and assumed the customer would review it. The customer owned the directory and assumed the provider was looking after its own accounts. The account sat between the two for twelve years, owned by nobody.
Every estate has a Test2
I'd be surprised if any organisation of a reasonable size has none of these. The usual suspects:
- Test and build accounts created for a migration or a proof of concept and never removed.
- Supplier accounts for a support contract that ended, or an engineer who moved on.
- Service accounts that nobody dares disable because nobody knows what they run.
- Leavers' accounts kept "for the mailbox" or "for a handover".
- Bind and integration accounts used by firewalls, VPNs, printers and HR systems to read the directory.
They have the same traits: no named owner, no MFA, a password that never changes, and nobody watching them. Attackers like them for the same reasons. Password sprayers try Password1 first because it still works (we explain why in What is password spraying?). And a sign-in from an account nobody uses doesn't trouble anyone, because nobody is expecting anything from it.
We see the same pattern in this week's threat research. In the k0t campaign, a firewall's directory bind account was the bridge from the edge into Active Directory. In the INC and Gentlemen intrusions, one reused password opened the VPN, servers, remote management, backups and security tools.
Ownership is a contract question, not just an IT question
The part of the reprimand I'd want every IT director to read is the contract finding. The ICO's recommendations include setting out security responsibilities clearly in contracts with IT providers and sub-processors. That's a polite way of saying "who reviews the accounts?" needs a written answer before something goes wrong, not after.
If you outsource any part of your estate, ask your provider these four questions this month:
- Which accounts in our directory did you create, and which of them still exist? Ask for a list, not reassurance.
- Who reviews them, and how often? Get a named role and a frequency.
- What happens to an account when your engineer leaves, or when a project ends?
- Which of your accounts are excluded from MFA, and why?
Then ask your own team the mirror-image question: which accounts do we think the provider is looking after? The gap between the two answers is where the next Test2 lives. Our third-party risk work starts from exactly this kind of mismatch.
What good looks like
- Every account has a human owner recorded against it, including service and supplier accounts. No owner, no account.
- Dormancy has a rule. For example, disable after 60 days without a sign-in, delete after 90 unless an owner justifies it. Microsoft Entra access reviews and inactive-user reports make the cloud side easy. On-premises AD needs a script and a calendar reminder.
- Weak passwords are blocked, not discouraged. Entra Password Protection with a custom banned list, extended to on-premises domain controllers.
- Remote access requires MFA for every account, with exclusions that are named, owned and reviewed.
- Local admin passwords are unique and rotated with Windows LAPS rather than set once by whoever built the machine.
What a SOC can see that a review can't
Account reviews happen quarterly if you're lucky. Attackers don't wait for the next one. Between reviews, the signal is behaviour: an account that hasn't signed in for a year suddenly authenticating, a test account touching file servers, or a supplier account active outside any support window. In a Microsoft estate those events are in the sign-in and directory logs already. The question is whether anyone looks at them in time.
That's part of what our 24/7 SOC does. CYBERSHIELD AI investigates each incident as it arrives and a senior analyst signs off by default on the managed service, so "a dormant account just woke up" gets a verdict in minutes, not at the next quarterly review. Our identity threat detection and response service focuses on exactly these signals.
You probably already know where your Test2 is. If you'd rather find out before an attacker does, talk to us or book a demo.