--- title: "Case study: ransomware, without paying the ransom | Avepto" canonical_url: "https://avepto.ch/en/case-studies/ransomware-recovery" last_updated: "2026-09-13T20:46:31.611Z" meta: description: "After ransomware hit several sites, Avepto rebuilt dozens of virtual machines and restored dozens of terabytes of data without paying the ransom." "og:description": "After ransomware hit several sites, Avepto rebuilt dozens of virtual machines and restored dozens of terabytes of data without paying the ransom." "og:title": "Case study: ransomware, without paying the ransom" "twitter:description": "After ransomware hit several sites, Avepto rebuilt dozens of virtual machines and restored dozens of terabytes of data without paying the ransom." "twitter:title": "Case study: ransomware, without paying the ransom" --- Cybersecurity # Rebuilding after ransomware Without paying the ransom. A multi-site Swiss company’s systems encrypted in broad daylight. Three weeks to restore essential services across every site, without paying the ransom. [Book a call](https://avepto.ch/en/appointment)
Client
Swiss company Anonymised at its request
Locations
Several sites Switzerland and abroad
Scope
Full infrastructure Servers, email, data, apps
Solution
Complete rebuild Backups and detection
01 The client ## A Swiss company established across several sites. The company’s teams work across several sites, in Switzerland and abroad. Its file servers, email and business tools were administered in-house, on hardware it owned. Several modernisation projects had already been identified: replacing the firewalls, updating certain systems, segmenting the sites more strictly. The attack arrived before they were deployed. 02 Executive summary ## A silent intrusion, then encryption in broad daylight. The first visible sign came when several virtual machines refused to start. At the same moment, file extensions began changing before the team’s eyes: the encryption was under way. The instruction was immediate, isolate the equipment and physically cut the network connections. That reaction preserved part of the estate. The core of the infrastructure had already been reached, however: the central directory, the virtualisation platforms and the backups reachable from the production network. 03 Challenge ## The most likely intrusion scenario. What the analysis pieced together is not a technical feat, but a chain of four weaknesses, each of them ordinary on its own. 1. ### A booby-trapped message as the way in The incident analysis identified a booby-trapped message as the most likely point of entry. The person who opened it held no administrative rights; their workstation nonetheless gave the attackers a first foothold in the environment. 2. ### Privileged credentials used to move on From that compromised workstation, the attackers appear to have captured and then replayed the NTLM hash of an account with extended rights, a technique that authenticates without ever knowing the password. In the detection setup then in place, no usable signal flagged this progression before the encryption. 3. ### Sites that were not segmented enough The sites communicated over permanent links. Once the necessary rights were obtained, the attackers could use those connections to move from one site to the next without meeting a sufficient security boundary. 4. ### Backups segmented, but not isolated enough Each site held local backups on VLANs separate from production, and the essential data was consolidated at head office. That segmentation limited ordinary access without offering real containment against an attacker holding privileged rights: the administration paths still permitted reached the backup systems, which became unavailable in turn. 04 Solution ## Isolate, restart from a clean base, rebuild. ### Isolate before rebuilding The first priority was not to switch the servers back on, but to stop the spread and take back control of the environment. The links between sites were cut, sensitive accounts locked and equipment examined step by step. Before anything went back into service, we had to confirm that no active access remained and that no compromised system would be reintroduced into the rebuilt infrastructure. That phase demanded method: preserve what the analysis needed, identify the usable data sources, set a rebuild order, and reconnect each component only after checking it. ### Find a usable directory again At a remote site, a secondary directory controller had been offline for several weeks and had escaped the attack that way. Once its integrity was verified, that directory, slightly older than the incident, became the basis of the rebuild. The most recent changes had to be reconstructed, but this recovery point spared us recreating every account, group and access right from nothing. The server was not reconnected as-is to the compromised environment: it supplied a controlled working base from which the directory was restored. ### Rebuild the systems, restore only the data The operating systems, the directory, the virtualisation platforms, the file servers, the databases and the business tools were all rebuilt on fresh foundations. No compromised system disk went back into production: several dozen virtual machines were rebuilt. The off-site replication, synchronised every five to ten minutes, had not been reached. Several dozen terabytes of data were restored, checked and reintegrated into the rebuilt environments, prioritising the services the business could not run without before handling secondary functions. - Central directory - Virtualisation platforms - File servers - Databases - Business tools - Email, moved to the cloud ### Save the email The internal email server had been encrypted along with the rest of the infrastructure. The workstations, however, still held usable local copies of some mailboxes. That data was extracted machine by machine, then reimported into a new cloud email service, which has been kept since so that email stays separate from the local infrastructure. ### Resume operations without paying the ransom The attackers demanded several hundred thousand dollars. The ransom was not paid. A usable off-site replica, the rebuilt systems and the technical understanding gained during the engagement let the company restart without depending on the attackers or on their decryption promises. Refusing to pay did not make the recovery any easier. It made three things matter more: the quality of the preserved data, the order of the rebuild, and the ability to keep working in a degraded environment for weeks. 05 Results ## Three weeks to restore, three months to stabilise. ### Ransom paid 0 The attackers demanded several hundred thousand dollars. Nothing was paid: the systems were rebuilt on clean foundations and the data restored from an off-site replica the attack had not reached. ### Essential services restored 3 weeks Three weeks between the encryption and services reachable again across every site, in a still-degraded environment. Three months were needed to reach a stabilised infrastructure. Before the incident Today Privileged accounts compromising one account with extended rights opened the way admin accounts separated from daily ones, NTLM exposure reduced Local administrators management was not individualised enough unique passwords, rotated automatically Detection and response about two weeks of presence with no usable alert endpoints and servers monitored continuously, confirmed threats isolated automatically Firewalls replacement was recommended, but had not happened equipment replaced and managed across every site Segmentation permanent links made moving between sites easy sites better segmented, inter-site flows controlled Backups several copies stayed reachable from the production network immutable off-site copies, with access separate from production Directory a controller left offline by a favourable circumstance an isolated standby kept and verified by a controlled procedure Email a local server, hit during the attack hosted in the cloud, protected and backed up separately No setup can guarantee that an attack will be stopped at its first move. What the new architecture does is raise the odds considerably: spot abnormal activity earlier, contain the machines involved, and preserve the copies a restoration depends on. 06 Impact ## Operations restart, on an architecture that holds. ### For the business #### The risk, before A ransom of several hundred thousand dollars demanded, three weeks of degraded operations across every site, and three months of work before the environment was stable again. #### The benefit, since Nothing was paid to the attackers: rebuilding on clean foundations, with the preserved copies, made the ransom irrelevant. ### For the infrastructure #### The risk, before About two weeks of presence with no usable alert, firewalls whose replacement was still pending, permanently linked sites, and backups reachable from the administration paths. #### The benefit, since Endpoints and servers monitored continuously, a confirmed compromise isolated automatically, and critical copies held off site and immutable. 07 ## Testimonial > “The morning the files started changing names, we unplugged the cables ourselves. What struck me afterwards was the calm: isolate, rebuild, in a precise order. Today I know what is monitored, what is backed up and where the copies are. *Management Multi-site Swiss company* 08 Conclusion ## From luck to a recovery architecture. - A cyberattack is not handled with tools alone. During the crisis, technical decisions, communications and priorities have to follow one clear chain. - The response was organised around central control: isolate, preserve what the analysis needs, rebuild in a defined order, and manage what gets shared. That organisation kept contradictory actions out of the way. - The inventory and mapping carried out from the start of the engagement made the dependencies between sites and systems legible, and set a rebuild order matched to how the business actually runs. At the time of the attack, the only usable directory had been preserved by a favourable circumstance. That luck is no longer the strategy: the standby directory is isolated and maintained by a controlled procedure, the critical backups have immutable off-site copies, administration access is separated and the sites are better segmented. The company no longer depends on a coincidence to restart. [Our service Cybersecurity Protection, identity, recovery ](https://avepto.ch/en/cybersecurity) [Case study Pain Fromage Studio, four hours of downtime Disaster recovery ](https://avepto.ch/en/case-studies/pain-fromage-studio-server-failure) [From the blog MFA enabled, account compromised: why two-factor is no longer enough Identity and detection ](https://avepto.ch/en/articles/mfa-not-enough-session-theft-siem-edr) Your exposure ## Start by measuring the exposure. Exposure, access, backups. Three things to look at before deciding anything. No commitment. [Book a security audit](https://avepto.ch/en/contact)