Scenario context — a mid-sized university
The following scenario is based on analysis of real ransomware incidents in the education sector and presents a typical attack progression against a fictional mid-sized European university with 12,000 students and 2,000 staff members.
The university maintains infrastructure typical of a public institution: on-premise servers running administrative systems (student information, ERP, email), a Moodle platform for e-learning, a campus network with student Wi-Fi, several computer labs, and a server room housing research data. The IT budget allows for basic infrastructure maintenance but not advanced security solutions. The university has a two-person IT team and a part-time DPO.
The attack takes place in October — the beginning of the academic year, when systems are loaded with enrollment, course registration, and new student account configuration. The IT department is operating under maximum pressure. This is not coincidental — attackers deliberately choose moments when institutional response capability is at its lowest.
The attack is carried out by a ransomware group operating the double extortion model: encrypting data and threatening its publication. Their operational model follows a pattern seen in groups actively targeting the education sector.
Day 1, 9:00 AM — Entry vector: spear phishing
The attack begins with a carefully crafted spear phishing email directed at Professor Anna Smith from the Computer Science Department. The message impersonates a national research funding agency, announcing a new grant competition with a submission deadline in 10 days. The email contains a link to a “preliminary qualification form” on a convincing lookalike domain registered the day before.
Professor Smith, actively applying for grants, clicks the link. The page looks identical to the legitimate grant management system. She logs in with her credentials — the system displays an error message and asks her to log in again. In the background, her credentials have already been captured and transmitted to the attackers’ server.
At 9:15 AM, the attackers log into Professor Smith’s email account. Their first action is configuring a forwarding rule — a copy of all messages is sent to an external address. They then browse her inbox searching for IT infrastructure information, credentials for other systems, and contact lists.
At 10:30 AM, a message is sent from Professor Smith’s account to five department colleagues — “Please urgently review this paper before tomorrow’s deadline” — with a .docx attachment containing a macro that downloads a backdoor. Two people open the file and enable macros. The attackers now have three footholds in the university network.
Days 1-3 — Reconnaissance and lateral movement
Over the next 48 hours, the attackers conduct quiet reconnaissance of the campus network, using tools like BloodHound to map the Active Directory structure, Mimikatz to extract credentials from infected workstation memory, and PsExec for remote command execution.
Day 1, 2:00 PM: The backdoor on Dr. Brown’s workstation (one of two staff who opened the infected file) escalates privileges to local administrator level, exploiting an unpatched Windows CVE. The domain account password hash is extracted from the lsass.exe process memory.
Day 1, 6:00 PM: Attackers discover that Dr. Brown is a member of the “Department IT Administrators” group in Active Directory, granting extended privileges to departmental servers. Using these privileges, they access the department file server containing research data, theses, and grant documentation.
Day 2, 2:00 AM: During nighttime hours (when monitoring is minimal), attackers scan campus networks. They discover that network segmentation is rudimentary — the departmental network can reach the administrative segment. They identify the student information system, ERP server, Exchange mail server, and Moodle instance.
Day 2, 11:00 AM: Using Pass-the-Hash techniques, attackers gain access to the domain administrator account. They now have full control over the entire university Active Directory infrastructure. From this point, no data is safe.
Day 3: Attackers methodically exfiltrate data — 2 TB of research data, student databases with records of 50,000 students (current and former), employee HR data with national ID numbers, and financial documentation. Data is transferred to external servers through encrypted tunnels, in fragments, to avoid raising suspicion.
Day 4, 3:00 AM — Ransomware detonation
On Friday at 3:00 AM — when the campus is empty and the nearest on-call IT staff member is unavailable — attackers launch the ransomware payload on all controlled machines simultaneously.
3:00-3:15 AM: Ransomware spreads rapidly through Active Directory, using Group Policy Objects for distribution to all workstations and servers in the domain. The encryption process begins with the highest-value files — databases, documents, research files — and proceeds to less critical resources.
3:15-3:30 AM: The student information system, ERP, Moodle, and Exchange mail servers are encrypted. Backups on the backup server — connected to the same domain — are also encrypted. Attackers deliberately identified and destroyed backups as a priority.
3:30 AM: Ransom notes appear on all computer desktops: 50 BTC (approximately 3.5 million EUR) for the decryption key and guarantee of not publishing stolen data. Deadline: 7 days. After that, the price doubles, and after 14 days, data goes on the dark web.
4:00 AM: The server room monitoring system generates alerts about service unavailability, but they arrive at the encrypted email server. The only signal is an SMS from the monitoring system sent to the IT manager, who is asleep at this hour.
6:30 AM: Campus security reports that the building access control system is not functioning. This is the first visible symptom of the attack.
Day 4 — Response and chaos
7:00 AM: The IT manager arrives at the university and discovers the scale of the disaster. All systems are unavailable. Ransom notes are displayed on server room monitors. First reaction: attempt to restore from backups — but the backup server is encrypted.
7:30 AM: The IT manager informs the Vice-Rector for IT. An emergency leadership meeting is convened. No one knows what data has leaked, how broad the attack scope is, or whether attackers still have network access.
8:00 AM: The university contacts the national CERT team. The recommendation is immediate disconnection of all systems from the internet and engaging an Incident Response team.
9:00 AM: Students discover they cannot log into Moodle, the student information system, or university email. Photos of the ransom note, taken by staff on their phones, begin circulating on social media. Local media pick up the story.
10:00 AM: The university engages an external cybersecurity firm to conduct forensic investigation. Simultaneously, the rector must decide on communication — concealing the incident is pointless since students already know. An official statement is prepared.
12:00 PM: Dean’s offices cannot serve students — no access to data, grading systems, or documentation. Make-up exams scheduled for next week are at risk. Financial administration cannot process payments — including staff salaries.
Where defenses could have stopped the attack
Analysis of the scenario reveals at least six points where appropriate safeguards could have stopped or significantly limited the attack.
Point 1 — Phishing (Day 1, 9:00 AM): Implementing DMARC with reject policy for university domains, awareness training with phishing simulations, and advanced anti-phishing filters detecting newly registered domains could have blocked the initial vector.
Point 2 — Macro execution (Day 1, 10:30 AM): Macro blocking policy for documents from external sources (Attack Surface Reduction Rules in Windows), attachment sandboxing, or EDR detecting suspicious macro behavior could have prevented backdoor installation.
Point 3 — Privilege escalation (Day 1, 2:00 PM): Regular system updates (patching the CVE), removing local administrator privileges from standard employee accounts, and monitoring privilege escalation attempts could have stopped lateral movement.
Point 4 — Lateral movement (Day 2): Proper network segmentation preventing access from the departmental network to administrative systems, NDR monitoring detecting anomalous network traffic patterns, and protocol restrictions (disabling SMB, RDP outside designated stations).
Point 5 — Data exfiltration (Day 3): DLP monitoring detecting mass outbound data transfers, alerts on unusual nighttime network traffic, and restricting internet access from critical servers.
Point 6 — Backups (Day 4): Offline (air-gapped) or immutable backups, inaccessible from the AD domain, with regular recovery testing — this is the only guarantee of data recovery without paying the ransom.
Lessons learned and recommendations
This scenario illustrates several fundamental lessons for universities planning to strengthen their cybersecurity posture.
First: the attack does not begin with ransomware. Data encryption is the finale of a multi-day operation that starts with simple phishing. Investment in phishing prevention — training, filters, phishing-resistant MFA — is many times cheaper than handling a ransomware incident.
Second: network segmentation is not a luxury but a necessity. The lack of segmentation allowed attackers to move from a single workstation to all critical university systems. Proper segmentation limits attack impact to a single segment.
Third: backups must be ransomware-resistant. A backup connected to the AD domain is as vulnerable to encryption as production data. The minimum is one offline copy, tested regularly.
Fourth: the incident response plan must exist BEFORE the incident. The university in the scenario had no developed procedures — decisions were made ad hoc, wasting precious hours determining who was responsible for what.
Fifth: a dwell time of 3 days is actually short — in the education sector, the average exceeds 45 days. Active monitoring and SOC (internal or external) enable detection before the detonation phase.
nFlo helps universities implement all mentioned safeguards — from security audits through network segmentation, SOC monitoring, to training and incident response planning. Contact us before this article’s scenario becomes reality at your institution.
Cybersecurity for Your Industry
Learn more about cybersecurity in your industry:
