We took the call in the morning. Staff could not log in to the TMS, ransom demand files had appeared on several servers, and the warehouse came to a stop because nobody could confirm what was going where. The company was not a regular client of ours. It reached out in emergency mode, asking whether this could still be saved.
The starting situation
The forwarder employed around 80 people and based its daily work on the transport system and warehouse operations. Both ran on servers on site. Overnight someone encrypted part of the machines and left a note demanding payment in cryptocurrency. The internal team managed to switch off a few devices, but it was not clear what was still healthy and what was not.
A backup existed. That is good news, though it has to come with a second, less comfortable fact: nobody had ever tested it. The copies were being made and the reports were green, but no one had ever checked whether a working system could actually be restored from those files.
Why it was urgent
In logistics, downtime is counted in hours and in specific trucks that will not roll out. Every day without the TMS means unfulfilled orders, contractual penalties and clients who start looking for another carrier. The pressure to simply pay and be done with it was real. Our job was to show there was a safer route, and to walk it together with the team.
How we contained the incident
We started with isolation. We disconnected the infected machines from the network to stop further encryption, and secured the data needed for analysis: logs and disk images. Only then did we determine the likely entry vector, namely a compromised account with remote access and no second authentication factor.
In parallel, recovery began. The key rule was: we do not restore anything into a dirty network. We built an isolated, clean environment, verified the most recent consistent copies and from them restored the TMS, the databases and the warehouse files. This was the moment of truth for the untested backup. It turned out to be sufficient, although we lost about one day of the most recent data, which had to be rebuilt manually from documents and confirmations.
The critical systems were back at work 22 hours after the report. The ransom was not paid.
Hardening so it would not happen again
Recovering continuity was half the job. The other half was making sure such a morning would not repeat. We deployed EDR on all workstations and servers, replacing the antivirus that had not noticed this attack at all. We closed the entry route: we enforced multi factor authentication on remote access and put the accounts in order.
Finally we dealt with what had failed most quietly, namely the backup. We built a disaster recovery plan with a clear RTO of four hours for critical systems, encryption resistant copies and a regular, documented restore test. The backup stopped being an assumption on paper.
What changed
The company went back to normal work without funding criminals. It now has a layer that really detects attacks, logins resistant to the leak of a single password and a recovery procedure that we check before it is truly needed. The client stayed with us on ongoing care: we monitor the environment and periodically test recovery, because the best time to spot a backup problem is a quiet Tuesday, not the morning after an attack.