They didn't hack the Department for Education, they rang the helpdesk
Somebody in your business can reset a password, change the email address on an account, or look up a customer's details, on request, over the phone. They do it many times a week because that is the job. Now ask two questions. What are they required to check before they do it, and who wrote that down?
If the answer is "they use their judgement", that is the whole subject of this filing.
The Department for Education has disclosed a breach of more than 600,000 records, taken through an external-facing helpdesk used by school and university staff and local authorities. Not a vulnerability, not a phishing email, not ransomware. A social engineering attack on the service desk itself.
What was taken, and what was not
The data is contact information: full names, email addresses, and phone numbers belonging to government and university staff, and senior school officials including headteachers. The Times reported the leak first, found dark web postings from people claiming to be a group calling itself ExfilSquad, and verified some of the data as genuine.
The DfE's statement is worth reading closely, because it is doing careful work. "We have robust processes in place to protect information and took swift action to contain this incident. The information involved is limited to customer service contact details relating to individuals and organisations. No other data has been accessed."
That is probably accurate, and it is also the least reassuring kind of accurate. No financial data, no pupil records, no passwords. Just a verified list of 600,000 named people in education, with their work email addresses and phone numbers, sorted by role.
Which is precisely the raw material for the next attack. Jake Moore of ESET put it plainly: criminals can piece together a data jigsaw and build convincing follow-up emails from it. A phishing email to a headteacher, using their real name and real role, referencing the department they genuinely deal with, is a different proposition from a generic one. Contact data is not the prize. It is the tooling for the prize.
The department has pulled several systems offline and is in contact with the Information Commissioner's Office, the National Crime Agency, and the National Cyber Security Centre. Worth noting what is not confirmed: no ransomware has been confirmed, little is known about ExfilSquad, and the same name has claimed an unverified breach at Microsoft in recent days. Treat the group's own claims with the caution they have earned.
The bit that transfers to you
Ignore the scale. Six hundred thousand records is a government department's number, not yours. The mechanism is what transfers, and it is not exotic.
A service desk exists to be helpful to people it cannot see. Every control that makes it secure makes it slower and more irritating, for callers who are usually genuine and often in a hurry. That tension is permanent, and it does not resolve itself. It gets resolved, quietly, by whoever is on the phone at 4:50pm on a Friday with somebody insistent on the other end.
Most smaller organisations have this exposure and have never framed it as a security question at all. Your version might be the person who handles customer enquiries, the office manager who administers Microsoft 365, the finance assistant who updates supplier bank details, or your outsourced IT provider's own helpdesk. Each of them can be talked into something by somebody who sounds legitimate, is in a rush, and knows a few true details about your business, details that are increasingly easy to find, and easier still after a breach like this one.
This is the same failure as the IT engineer who turns up and isn't the IT engineer, moved from the front door to the phone line. The attacker is not defeating a control. They are using the process exactly as designed, having established that they are somebody they are not.
What to do this quarter
Write down what verification is required, and for what. Not a policy document. A short list: to reset a password we require X. To change an account's email address we require Y. To change bank details on a supplier record we require Z, and the answer to Z should involve calling a number you already hold, not one supplied in the request. Fifteen minutes of writing removes the need for anyone to improvise.
Say out loud that slowing down is allowed. The most useful sentence you can give a service desk is that nobody will be in trouble for making a caller wait while they verify. Most social engineering runs on manufactured urgency, and urgency only works on people who believe delay will be held against them. That permission has to come from a manager, in a way people believe, or the written process gets abandoned exactly when it matters.
Pick your highest-consequence action and add a second person to it. Usually changing where money goes, or granting access to a system. One approval from someone else, out of band, is unglamorous and stops most of this.
Ask your IT provider the same question about their desk. If your MSP can reset your staff's passwords, then their verification process is your verification process. Ask what it is. This is the question their answer tends to reveal the most.
Then test it. Have someone your team does not recognise ring up and ask for something they should not get. This costs an afternoon and tells you more than any document. If they get it, that is a finding, not a firing.
How Steelwise can help
Working out what your service desk is allowed to do, writing the verification rules down in plain English, and then testing whether they hold up is exactly the kind of review that costs little and prevents this. Get in touch.
Further reading
- NCSC: Phishing and social engineering guidance
- ICO: Personal data breaches, a guide
- NCSC: Ten Steps, managing user privileges