European School Bomb Threats: Two University Email Addresses Found in Old Infostealer Data

The finding is narrow. It doesn't show that anyone broke into Microsoft systems. It also doesn't show that the old stolen passwords were used to send the threats.

What Hudson Rock found​

Hudson Rock reports that two university addresses tied to the threats appear in its stolen-credential data. The Register says the first address belongs to Egypt's Kafrelsheikh University. Searching it in Hudson Rock's data matched a computer classified in the firm's Cavalier platform as infected with Vidar. The Register dates that Vidar capture to October 2021.

The second address belongs to Taiwan's Dayeh University. The Register says it was among the 284 million addresses in the AlienTXTBASE dump, dated February 2025. AlienTXTBASE is a collection of aggregated infostealer data that Troy Hunt added to Have I Been Pwned in February 2025.

The Microsoft angle comes from the Taiwanese record. Hudson Rock describes it as a matching Microsoft credential entry in AlienTXTBASE, in data it dates to more than a year before the threats. The Register adds that both universities used Microsoft for authentication. Neither source says which Microsoft service or configuration was involved. They also don't say whether multifactor authentication was on, or whether either university ever got an alert.

What the evidence does not prove​

Hudson Rock itself is cautious, and readers should be too.

• Old exposure is not proof of use. The Register reports that the researchers said the logs don't strictly mean the senders got in through the earlier compromise.
• Provider data would be needed. Hudson Rock said it would need email headers plus sign-in events and audit records from the email providers. Those could show who sent the messages and from which session.
• Authentication wouldn't settle it either. Hudson Rock assesses the Taiwanese record as infostealer-derived. Even so, confirming that the sender logged in could rule out simple spoofing without proving a stolen password was used. The researchers noted there are many ways around password-based authentication.
• Scope is limited. Hudson Rock's findings concern only these two addresses. They don't establish a common operator or an infostealer link for every contemporaneous threat.

Attribution is also unsettled. The Register says theories range from a compromised teacher's email in the Philippines to a Russia-backed disruption operation. Neither is confirmed, and Russia denies involvement.

The campaign behind it​

The Register reports that around 6,300 of Italy's 7,476 state schools received the emails between November 11 and 12. Only around 390 evacuated. The messages carried violent language and claimed a remotely triggered explosive. They were signed "Mikhail Andropov, leader of the Vilayat of Misoginistan", which The Register calls a fictitious region.

Similar emails reached schools in France, Ireland, Northern Ireland and Scotland. None of the police forces involved considered the threats credible. In Ireland, RTÉ evacuated its Donnybrook campus. Police Scotland said around 1,000 schools were affected.

The Journal reported that the Irish threats were sent from different email addresses. That fits Hudson Rock's own limit: two addresses should not be generalised to the whole campaign.

Italian Prime Minister Giorgia Meloni said there was no evidence of concrete danger. She said the aim was to spread fear and chaos.

Why IT admins should care​

Hudson Rock's wider point is that a credential exposure matters beyond fraud and data theft. In its words, an account tied to an ordinary university user can become a way to reach schools, frighten families and consume emergency resources. A trusted institutional domain also makes a hoax look more credible to recipients.

For anyone running a Microsoft 365 or Entra tenant, the response Hudson Rock recommends is simple. When a credential shows up in infostealer logs, contain the account, revoke its access, rotate secrets, and look for suspicious activity.

The sources don't give a Microsoft-specific procedure. As general practice, an admin could map those steps to the following checks (my own suggestions, not from the reporting):

1. Review sign-in and audit logs for the affected account, looking for unfamiliar locations, devices or mail activity.
2. Revoke active sessions and tokens, not just reset the password. Infostealers can also take session cookies and tokens, as Security Affairs notes.
3. Check for mail rules, forwarding or newly registered authentication methods.
4. Clean the infected endpoint. Resetting a password from a machine that still has the malware just hands the new password to the attacker.
5. Preserve the original messages and headers if the account was used to send abuse.

The takeaway​

The Register's account notes that infostealer logs are now highly visible to threat intelligence. In its words, universities and Microsoft had "ample time" to act on accounts they should have known were appearing in those logs. That is a fair criticism of the response, but it is not proof of causation. The window between exposure and abuse was long, and acting on it is cheap compared with explaining a continent-wide hoax.

Investigators still have to establish who sent the emails and how. Until the headers and provider logs are examined, the safest reading is that these two addresses were exposed long before the threats and may or may not have been abused through that exposure.