1 of 30

Inside the TU/e Cyberattack in January 2025: Crisis, Response, and Resilience

HEANET CONFERENCE 2025

Michiel van Grootel, Product Owner Compute & Storage Services & Platform Architect

Bart van Overbeeke Photography

2 of 30

Michiel van Grootel

HEAnet Conference 2025: Inside the TU/e Cyberattack in January 2025: Crisis, Response, and Resilience

2

https://www.linkedin.com/in/michiel-van-grootel-2a94ab15/

Infrastructure engineer/Project manager

Research IT-er

Technical Enterprise Architect

m.h.v.grootel@tue.nl

Product Owner CSS / Platform Architect

3 of 30

Content

Eindhoven University of Technology
Before the attack
The night of the attack
Forensics & Recovery
Lessons learned
Q & A

HEAnet Conference 2025: Inside the TU/e Cyberattack in January 2025: Crisis, Response, and Resilience

3

4 of 30

Established in 1956
4000 employees
13500 students
9 Departments
Strong focus on Engineering, Data & AI, Photonics & SemiCon, Energy and Health
Hybrid cloud IT environment

Eindhoven University of Technology

4

5 of 30

Eindhoven University of Technology

5

6 of 30

In 2019, Maastricht University was hacked and ransomware’d

Wake-up call!

Development of sectorial Security baselines.(and auditing them!)
Sectorial Security Monitoring (SURFsoc)
Creation of a TU/e Security taskforce(policies & projects)
Improved Crisis management

Before the attack

6

So, where were we at the time attack.

Maastricht

Hit on Friday before the christmas holiday, all systems encrypted including backups.

200K bitcoin, later recovered worth 500K, maybe a business model ?

Initial compromise was a phishing email.

indication that phising took place at our university and others as well.

So, that was a wakecall for the rest of us. Could just as well happened to us

Our ministery of Education, together with Surf(the Dutch version of HEAnet) create specific security baselines, consisting of other know baselines as ISO27002, NIS and CIS. And we have have made agreements with the Ministery of eduction to achieve a certain minimum score at some point. We have report

The auditing is made a little bit difficult due to the fact its not an establish framweork, since there are no proper tools available, so recently the decision was made to go to a standard baseline, probably ISO27002.

Also, in a similar fashion as HEAnet has(saw in a presentation at an earlier HEAnet Conference) SURF implemented a sector SOC SIEM service together with Fox-IT called SURFsoc.

At the TU/e we implemented a security taskforce, which was possible due to the Maastricht incident, which meant more budget was allocated for security ( of course, never waste a good crisis)

That taskforce created, among other things much needed security policies, and implementation of a NGFW, rollout of Defender Endpoint (budget to MS A3 to A5), SurfSOC, network segmentation)

All these measure were obviously not enough to precent the cyberattack, or else I would not have been standing here. It did however gave us the means to handle the attack much more effectively. In the next slides i will go deeper into a few of them and why they helped us.

7 of 30

Crisis management��

Well-defined crisis management plan Clear organisation and trained people

Clear communication channels, including Out-of-Band.

Regular exercises (OZON & NOZON)

Before the attack

7

8 of 30

Crisis management organisation

Central Crisis Team (Strategic)

executive leadership: sets priorities and risk appetite

Crisis Management Team (Tactical):

Incident command: synchronizes workstreams

Crisis Response Team(Operational):

Technical teams: execute IR, DFIR, and recovery

Decision cadence: stand‑ups, SITREPs, and documented decisions

Before the attack

8

9 of 30

Microsoft Defender for Endpoint

On most managed workstations and centrally managed servers
Connected to TU/e monitoring
Realtime!

Before the attack

9

SurfSOC

Splunk based monitoring with a 24/7 SOC managed by Fox-IT
centrally managed servers

TU/e technical measures in place

And things like network segmentation, NGFW’s, PAM, security reporting, etc.

10 of 30

The night of the attack - Saturday

21:23 MDE alert e-mail: malware activity on of the Domain Controllers

21:34 Team call with few employees

21:49 Computer Emergency Response Team called in.

22:13 Signal LIS Crisis app: we have a serious problem.

23:10 Online : Crisis Management Team (PO Security Operations Team, PAL Platforms, Dep. Dir. LIS, CISO)

23:39 Signal LIS Crisis app: Further escalation, decision made to disconnect from the internet.

The night of the attack

10

Saturday the 11^th of January this year, somewhat after 9 oclock in the evening, I was sitting on the couch when I received an email. Its was a security alert from Defender and

21:23 first MDE alert :Intial assement that a compromised user account was running CME against the Domain controller

Cat and mouse: Initial assessment that a compromised user account was running CME again. Disable accounts, isolate servers, investigate and mitigate. Blocked VPN. We thought we were on top of things. Then connections started coming from unmanaged systems.
23:39 we made the decision to close network made, was already pre-aproved by CMT. Decision had major impact, as exams were just around the corner. Once you go down, getting up again is a lot of work.

After that I hopped in my car and went to the University campus. Since i live about 40km from the university

Network shutdown anecdote, OZON few years back. I was observer.

11 of 30

The night of the attack - Sunday

00:30 Crisis Resolution Team, Crisis Management Team en CISO on campus

01:15 All network connections severed

--- IN CONTROL ---

03:00 Fox-IT team arrives on campus

09:00 Central Crisis Team meets on campus

14:00 Public Announcement

The night of the attack

11

12 of 30

Incident response approach

Goal: deny adversary’s access and minimize further damage.

Prevent them getting to know the TU/e’s infrastructure

Track what they touch

Isolating assets from the network

The night of the attack

12

13 of 30

Decision to disconnect the network��

Impact huge, but no longer possible to contain the hacker

Systems comprised that were not managed by the central IT Department

Open campus network

The night of the attack

13

14 of 30

Recovery – The network is down, now what? High Pressure to resume normal operations

Work toward the best outcome, but plan for the worst

Recover step-by-step: Isolate, restore in priority order with checkpoints/rollback,

Verify explicitly before go-live: Validate integrity and access

Communicate clearly and often to all stakeholders

Forensics & Recovery

14

15 of 30

Forensics

How did they breach our systems?

Did they get any of our data ?

How can we prevent them from doing it again

Time is not on our side

Forensics & Recovery

15

16 of 30

Forensics ��

We had help!

Collected and analyzed most relevant forensic artefacts

~1.3TB of forensic data collected with Fox IT ‘s Dissect & Acquire
~15TB of firewall logging
MDE & Splunk logging

Over 3000 logged events attributed to the adversary

28 assets were actively abused
77 assets were ‘touched’ but not abused

Forensics & Recovery

16

17 of 30

Forensics - Findings

The Bad: found 3 ”issues” that combined made the attack possible:

Process for leaked passwords failed.
No MFA on VPN
Legacy protocol enabled on DC’s

The Good: No data seems to have been taken by the hacker, nor was anything encrypted.

Forensics & Recovery

17

In piecing together the evidence, it became clear how the hacker gained Domain admin level clearance

The Account the hacker used was leaked much earlier and flagged by our security team. User was called to change the password but due to improper process he was able to reset the password to the same one he already had.

With the account the hacker was able to logon to VPN, which had no MFA security. VPN was to be replaced soon but project was delayed due to manpower issues.

The DC had NTLMv1 protocol enabled to authenticate users, due to a presence of legacy devices(Windows XP!) and applications on the network. Multiple times this was addressed but not mitigating actions were taken. With NTLMv1 a DC-SYNC attack was possible(attacked was published a year earlier!) and domain admin credentials were obtained.

Both system and network logs did not show large amounts of data exfiltration. Hacker did share discovery but failed to do much with it. This was due to the fact that from the beginning of the hack till network shutdown he was continuously hampered by TU/e personnel that isolated machines and reset accounts.

Attribution was hard since the hackers were constantly harassed by us, therefor were not able to deploy their signature tools. However, MO was clear ransomware – share scanning, backup server

Openness is akward, but necessary:

Semi- Public
Internal use, don’t downplay else not much will. change
Help others

18 of 30

Forensics & Recovery

18

19 of 30

Recovery

33 virtual servers restored to the day prior to the hack

5 physical servers reinstalled later on

Lot of work to check application data integrations consistency.

Reset a lot of stuff (accounts, KRBTGT, etc)

Forensics & Recovery

19

20 of 30

Timeline

Forensics & Recovery

20

21 of 30

What went well?

Initial response
Decisive leadership and clear prioritization of education continuity
Tight internal collaboration with empowered technical leads
Effective partnership with Fox‑IT to accelerate DFIR and recovery
Transparent communications building community trust

Lessons learned

21

22 of 30

What didnt go so well?

Prevention
Some plans and procedures were missing or not followed

Lessons learned

22

23 of 30

The human factor

Take care of your people!

Guilt
Stress
(No) Sleep
Risk of Burn-out’s

Lessons learned

23

24 of 30

Monitor for breaches

Monitor both with realtime Endpoint protection and security logging

Lessons learned

24

Improve and test your Readiness

Plan and create procedures for multiple scenarios and train your people

25 of 30

Ensure restore capability

Make sure your IT environment can be restored quickly from an immutable source

Lessons learned

25

Reduce identity theft

Monitor online exposure & implement and enforce MFA

26 of 30

Decommission

Decommission outdated and insecure (authentication) protocols

Lessons learned

26

Control your assets

Develop and enforce asset compliancy

27 of 30

Deny lateral movement

Segmentize and segregate your assets

Lessons learned

27

Contract

An Incident Response provider

28 of 30

Pentest

(Pen)Test your IT environment

Lessons learned

28

29 of 30

Thank you!

Questions

29

30 of 30

More information on the TU/e cyber attack:

https://www.tue.nl/en/news-and-events/news-overview/19-05-2025-tue-acted-well-in-cyber-attack-but-there-are-also-learning-points

Lessons learned

30