Status message
This page has been automatically translated from Dutch. Read in Dutch.
Case study
Maastricht University ransomware: behind the scenes
The ransomware attack at Maastricht University "will remain in the collective memory of the university," said Nick Bos, vice-president of the CvB, during the symposium on the attack that took place in December 2019. Bart van den Heuvel is corporate information and security officer (CISO) at UM. He was involved from the beginning.
Night work
On 23 December, half past 10 in the evening, I received a call that something was up. A few hours later, I was also on site, as it turned out to be a serious incident: ransomware. The CERT team had already shut down the network and the key stakeholders were informed, including the board. We were in contact with SURFcert until late at night, but also with Fox-IT, to find out what exactly was going on and how best to act.
The next day, we immediately set up a crisis management team. As CISO, I focused on risk assessment, additional measures and professional communication. Throughout the process, I maintained contact with, for example, SURFcert, the NCSC, the police and also the police's Team High Tech Crime.
Bart van den Heuvel, CISO at Maastricht University
Portrait photo of Bart van den Heuvel
It was immediately clear that this was a large-scale ransomware attack. The big question was whether we would be able to decrypt our data ourselves, or whether we would have to contact the hostages to do so. We decided after a few days that we wanted to. The contact was via my private email address, as my work email was unavailable due to the hostage situation. All communication with the hackers was done in consultation we had with the board, our lawyer and the communications department. We always had to assess how the hostage-takers would react. Sometimes we decided to gain time by asking technical questions ourselves.
Will we get the key?
The decision to pay posed an ethical and moral dilemma; the board in particular debated it for a long time. But in the end, it appeared that there was no other option; too much was at stake for our students and researchers. The assessment was that the hostage takers would provide us with a working key after payment. These criminals benefit from keeping their promise, otherwise when the next action comes, no one will pay. We had to rely on that. First, we sent a few more encrypted test files, which they sent back unencrypted. That way we knew they were not bluffing. Then we paid - with bitcoins - and were indeed given the key with which to decrypt our files.
In the end, there was no option but to pay, there was too much at stake.
Sharing information
Throughout the incident, we shared as much information as possible with SURFcert and our operational security community SCIRT. For example, by providing tips and sharing IOCs (indicators of compromise; potential risks). Unfortunately, we could not share all information immediately, including with SURFcert; we always had to weigh up a number of interests. Fortunately, this was understood in the community.
From this incident, we naturally drew a number of lessons. The most important:
- The logging and monitoring of our systems needs to improve. To this end, we are setting up a security operating centre (SOC). Two people had already been freed up for this. They were supposed to start on 1 January, but were forced to start a week earlier.
- Back-ups will be better organised. Contrary to what appeared in the press, by no means all our backups had disappeared, but a significant number had. In addition to the online back-ups, which can be deployed quickly, we will also set up back-ups that are protected in another way. Those backups are not always really offline, for instance on tape, but can't just be hit when the operational system is under fire.
- We are going to improve our configuration management database (CMDB) so that we have a better overview of which systems are all in our network. Many systems are decentralised, and now we don't always have a good overview of them centrally.
- We are going to segment the network even better, for instance through micro-segmentation, where each server is behind its own firewall. But also by better separating admin accounts, so that an administrator can no longer automatically access everything.
- Security by design and by default is a must. We are already redesigning our network, for instance when deploying firewalls.
Never waste a good crisis
The crisis also allowed us to accelerate some measures that were already planned. For instance, we were about to require students to provide their university account with a long, secure password. We were already preparing a communication campaign, but now everyone had to change their passwords anyway. So we immediately enforced that all new passwords are long.
The crisis also allowed us to accelerate some measures already planned.
Togetherness
What I found special was the togetherness I experienced during this incident. Everyone did their utmost to make all our systems accessible again as soon as possible. We also kept a constant eye on people, for example by releasing everyone on 1 January, despite the tight deadlines. In addition, we received help from fellow institutions and from SURF: for example, SURF set up a temporary mail server for us in no time, so that we could quickly communicate properly again with our students, staff and contacts outside the university.