Broken chain illustration
Creative Commons attribution information
©anttoniart (edited by H2 Creative) via Shutterstock
All rights reserved

Got a security weak spot? Exercise Mercury will find it

Kieren Lovell

At last year’s Jisc security conference, keynote speaker Kieren Lovell launched Exercise Mercury, a cyberattacking exercise that aims to expose weak spots in a university’s systems that could be exploited by illegal hackers.

20 UK universities signed up to take part and Kieren returned to the conference this year to tell us how they got on and what we can all learn from the competition. Here he explains how it all began, what they discovered and where it’s going next.

What is Exercise Mercury?

Two universities are paired off and each spends a week ‘attacking’ the other using an internal team of staff and students to uncover vulnerabilities in processes, policies, procedures, technology infrastructure and the digital footprint. The idea is to use university specialists from across the board – not just cyber security experts but system administrators, PR people, open-source intelligence, office administrators – to work out what they can find out about their ‘opponent’s’ organisation.

Teams typically spend two days checking out what’s most important to the opposition (sensitive research, for example) and the remainder of the week working out how to cause the most damage. Using open source intelligence and social engineering techniques, the ‘hackers’ perform a controlled simulation of an attack with clear legal boundaries. The winning team is the one that would have made the most negative impact.

How did it start?

It began in 2016 when I was head of the University of Cambridge’s computer emergency response team (CERT) and challenged Tallinn University of Technology to test our vulnerabilities.

It became quite apparent that while Cambridge has a lot of technical expertise, it also has a very large distributed network with lots of people doing lots of things in non-typical ways, so Tallinn had a field day with us. One of the first learning outcomes that I had was that we really need to know what we have and what others can see about us. We can't just keep relying on our ability to mark our own homework.

Universities have limited resources so when they do penetration testing, they generally do it as little and as infrequently as they have to, and superficially rather than looking at the whole organisation, which is what a hacker is doing. I continued the project when I moved to head up CERT at Tallinn University and developed it into Exercise Mercury with Jisc.

What happened next?

All of the universities had within the last year passed a penetration test with a lovely tick box to say they were secure. Yet every one of them was compromised by our students.

With one target, despite the fact that it had intruder detection systems and CloudFlare set up, it took the students just 12 minutes to get the entire internal schematic of the whole university without a username or password. Ironically, when we handed it to the university, they said didn't actually have their own internal schematic. We had one, but they didn't.

So what are we all doing wrong?

It's mainly around ownership and knowing what equipment you've got. The two biggest trends are legacy equipment that's been dumped on the network from academic projects where the funding has finished but the devices are still running and not being maintained, and legacy equipment and services that have been moved to the cloud but not upgraded.

The problem has simply been moved elsewhere, which has the effect of amplifying existing problems and now they can't even see in the logs if they've been compromised or not.

There's also a lot of misconfigured AWS and Google cloud services, where they've assumed that Amazon and Google are taking the security precautions for them on that particular avenue and in reality they haven't. You can do some quite interesting AWS and Google cloud attacks in order to compromise pretty much the entire installation.

If you don't know where your equipment is, who hosts it or how to contact them, what can you do about it when it’s compromised? It's the worst type of incident. You can't even turn it off. Every university we've looked at so far has these instances, either in the cloud or in external hosting.

Why is this happening?

Give me a room of a thousand university professors, students and staff, and I will ask one question: “Please put your hand up if you've read the information security policy.” Three people will put their hands up. If I then ask, “Put your hands up if you wrote it,” it will be the same three people.

Universities, like government services, can be very slow at pushing information out and updating it, so there are usually an awful lot of outdated policies and advice on a university's website that don't provide any security at all. The update process knowledge is in deficit, so you've got people getting wrong policies that no one's reading anyway.

The way that we communicate information security to users has to change. It has to be more push than pull. They shouldn't have to look for it. We have to do it in a more fun way because no one's going to choose to read a policy document and no one is going to willingly do a one-hour training course about information security.

What kinds of action have been taken by the universities you've worked with?

Most of them have realised that rather than focusing on their shiny new technology, they need to work out what legacy technology they have, do a proper audit of what people have got on their network and find out what people are hosting in the name of their university, off their network.

We also need to make sure that everybody understands that if you are a target – as universities are – then you will be compromised and the only way you can deal with it is to work out how to be notified when it happens and how to deal with the incident as quickly and as professionally as possible.

Did Exercise Mercury throw up anything unexpected?

On one occasion we were doing basic checks on a server and it gave us 65,000 image files of peoples' passports. Which is great because they knew that it had never been compromised before, they checked on the logs and everything was fine. We'd found it before somebody else did, so it proved that mechanism works well.

They've now secured their system or – I think in this case – actually set fire to their system.

Have you got any plans to scale this up?

We've got ramp-ups starting in December, January and February, and the Global Cyber Alliance will be involved in this as well. We are also taking it a step further by writing reports of how we could break a university and then table-topping it with university senior management as a real-life exercise, so they can simulate how they would deal with the situation if somebody did press the big red button and attack.

As well as the university competition, we’re also working with a number of military organisations, figuring out how we can track warships using social media and weaknesses in procedures, plus we’ve covered government bodies and a nuclear power station. I'm going to Adelaide in two weeks' time to use the same skills to find missing people, going through hundreds of cold cases.

Despite the variety of sectors in which we’ve deployed Exercise Mercury, we find remarkably similar results in certain areas.

We want to share the information that has come out of Exercise Mercury so the whole sector benefits, including the process and rules of engagement so that every other university that would like to can run a similar exercise.