Six days from one HR email to ransomware

Day 0: a message from HR that looked routine

An email that appeared to come from Human Resources announced a change in shifts and in how hours are calculated. Employees had to confirm their data before Friday. The link led to a copy of the employee portal, identical to the real one.

The store clerk entered a username and password. That portal did not ask for two-step verification. It had been judged unnecessary, because the portal was "only accessed from the store." The same credentials worked from outside, and that night someone used them. Nobody reported anything.

‍

Days 1 to 3: a map of who matters

A store clerk's account cannot do much, but it can look around. The internal systems of any company hold, by design, a guide to the organization: names, roles, employee numbers and who has permissions over what.

In three days the attacker had identified the small group of people who administer every system in the company. From that point the target stopped being the network and became one of those people.

‍

Day 4: four minutes on the phone

The attacker called the support desk and posed as one of those administrators, with their name, role and employee number. The story was urgent and believable: they were in a store, had lost their phone and could not validate their access.

The agent did exactly what the procedure asked. They checked name, role and employee number, and all three were correct. They restored the access. Half an hour later the attacker administered the company's systems with the same permissions as the person they had impersonated.

The call lasted less than four minutes. Nobody was negligent, because the procedure verified data the attacker already had.

This pattern is documented well beyond one case. Mandiant tracks groups such as UNC3944 that target IT help desks to bypass multifactor authentication and gain initial access (Mandiant M-Trends 2026, March 2026). The Center for Internet Security describes attackers posing as employees to get help desk staff to reset passwords. Others ask them to move MFA enrollment to a device the attacker controls (Center for Internet Security, August 2026).

‍

Days 4 and 5: the copy before the lock

Before breaking anything, the attacker spent a day and a half copying information out of the company: employee records, loyalty program customers, contracts and accounting. The data left during office hours, through a channel that looked like a routine synchronization from the inside.

Almost nobody expects this step, and it is the one that stops backups from being the answer.

‍

Day 6: everything stops at once

Overnight, from a single administration point, the attacker disabled the backups and encrypted the systems. It did not happen machine by machine. Everything fell at the same time.

Tills, inventory, logistics, payroll and email stopped right before opening hours. The stores that could switched to paper, and the rest did not open. Every screen showed the same message: an identifier, a contact address and a deadline.

‍

The extortion: two clocks, one script

The note set two clocks. One counted down to the moment the ransom would double, and the other to the publication of the stolen data. That same morning the company activated its crisis plan and called its incident response firm, its insurer and the authorities.

On the other side there was no fanatic. There was an operator with working hours and a script. Their argument was not the encryption but the information they had taken two days earlier. Encryption paralyzes, and the data is what gets charged for. On the third day they published a sample with the company's name, so the deadline also ran in public.

The company did not pay. It restored from the backups that had stayed safe, and it took weeks because nobody had rehearsed the order in which to bring systems back. The data was published anyway. Then came the notification to the data protection authority, notices to customers and employees, and a file that lasted far longer than the outage.

Paying would not have prevented any of that. Once the information is outside, a ransom only buys a promise.

‍

Why the attack worked

The attack had five links, and none of them needed advanced tooling. Each one exploited a reasonable decision that nobody had revisited.

The target was the most accessible person, not the most important one. The clerk handled no valuable data. They had valid credentials and no reason to distrust the message.

An exception opened the door. Skipping two-step verification for store staff made sense the day it was decided. Nobody reviewed it when those same credentials began to work from outside.

The help desk is a security control. It is the only point in the organization whose explicit job is to give access back to someone who says they lost it. It is rarely trained as one.

The signals existed but never met. An outside connection at midnight from a store account. An unusual data transfer over two days. Each signal reached a different place, and nobody put them side by side.

Annual training does not survive the moment of decision. Months pass between the course and the email. Between the email and the click, seconds pass. The knowledge stayed intact, and it never switched on under pressure.

‍

The margin was all before the negotiation

The negotiation was the only stage of the incident where the company had no room left. All the room had been earlier: in the email nobody reported and in the call nobody questioned.

That changes where a security leader should look. The usual question is how to stop the encryption. A more useful one is which ordinary decisions, made by which roles, a stranger with a plausible story can trigger.

Seen this way, the clerk and the support agent were two people making routine decisions with the information in front of them. The process around them assumed that information was private. Behavior is the system to improve, and in this case it could have been measured long before the incident.

‍

What this means for security teams

Start with the help desk. A verification procedure built on name, role and employee number only checks what an attacker can collect from the first compromised account. Testing it with a realistic call, using a real employee, a correct data point and a reasonable urgency, shows whether the procedure holds or only looks like it does.

Review exceptions on a schedule, not only when they are created. A rule that was safe when credentials worked only inside the store stops being safe when the context changes. The same applies to any control skipped for a group of staff because the risk looked low.

Treat reporting as a result you measure. How many people reported the HR email, and how fast, tells you more about your exposure than how many people clicked. A single early report would have given the company several days to react, not hours.

Train by role, at the moment it matters. A store clerk and a help desk agent face different attacks through different channels. A program that only simulates email phishing would have caught the first link of this attack and stayed blind to the one that closed it.

This is the part of the incident that we can measure, train and reduce at Zepo. The attack had five links and the encryption was the last one. The two that opened and closed it were people doing their jobs with the information they had.

‍

FAQ

What is vishing? Vishing is voice phishing: an attacker calls a target and uses a believable story, often with real names and employee data, to obtain access or information. Mandiant ranked it as the second most common initial infection vector in 2025, at 11% of intrusions (Mandiant M-Trends 2026, March 2026).

How do attackers get past help desk verification? They collect the details the procedure asks for, such as name, role and employee number, from a compromised account or public sources. The agent then verifies data that the attacker already holds, so a correct answer proves nothing.

Why are backups not enough against ransomware? Attackers often copy data before encrypting it. Restoring from backups recovers the systems, but it does not recover the stolen information, which the attacker can still publish or sell.

How do you test whether a help desk resists social engineering? Run a realistic call simulation with a real employee identity, correct verification data and a plausible urgent reason. Measure whether the agent restores access, escalates or asks for a second channel of verification.