Fallbeispiel: Schweizer KMU nach Ransomware-Angriff

Ransomware-Angriffe treffen längst nicht nur Grossunternehmen. Auch KMU müssen damit rechnen, dass sich Angreifer über Wochen in einer Umgebung bewegen, bevor sie zuschlagen. Wenn der Angriff sichtbar wird, müssen Entscheide unter Zeitdruck fallen: Welche Systeme werden isoliert, wie bleibt der Betrieb handlungsfähig, welche Melde- und Informationspflichten greifen – und wie lässt sich die Wiederherstellung nachvollziehbar absichern. Bei Alpein Software begann dieser Prozess an einem Freitagnachmittag im Juni um 14:51 Uhr: Ein Anrufer verwies auf Instruktionen auf mehreren Desktops, kurz darauf meldeten sich die Angreifer direkt bei Mitarbeitenden mit einer Lösegeldforderung.

Freitag, 14:51 Uhr – erste Massnahmen

Der Vorfall wird akut. Während die Angreifer noch telefonieren, laufen bei Alpein bereits die Sofortmassnahmen an. In kürzester Zeit sind alle relevanten Mitarbeitenden in einer Online-Konferenz versammelt, der Notfallplan aktiviert und ein Massnahmenplan für Forensik, technische Wiederherstellung und Kommunikation erstellt. Keine zwei Stunden sind vergangen.

Gleichzeitig liefern Techniker erste Erkenntnisse und fahren Teile der Infrastruktur kontrolliert herunter. Anschliessend werden betroffene Systeme heruntergefahren und vom Netz getrennt. Das Team startet die forensische Erstanalyse.

Wochenende bis Woche 3 – Krisenmanagement und Wiederanlauf

Während das technische Team die Systeme analysiert, beginnt die rechtliche und kommunikative Aufarbeitung. Datenschutzberater werden beigezogen, erste Meldepflichten geprüft. Die zuständige Polizeidienststelle wird informiert. Datenschutz- und Compliance-Verantwortliche werden eingebunden. Parallel erfolgt per Rundmail eine erste Information an betroffene Kunden sowie an alle Mitarbeitenden.

In der ersten Woche folgt die individuelle Information betroffener Mitarbeitender. Kunden werden proaktiv über den Vorfall und die Einschätzung zur Nichtkompromittierung ihrer Daten informiert. Kundenbezogene Systeme sind bereits am Montag wieder verfügbar und arbeiten einwandfrei. Administrative Systeme sind provisorisch und nur eingeschränkt nutzbar.


In Woche 2 und 3 liegt der Fokus auf Wiederherstellung und Härtung. Die letzten drei Windows-Server weichen Linux-Systemen. LDAP und VPN werden neu aufgesetzt. Sämtliche Passwörter werden zur Sicherheit neu vergeben. Kompromittierte Systeme werden aus Backups wiederhergestellt und gehärtet. Zusätzliche Sicherheitsmassnahmen werden implementiert. Im Laufe der dritten Woche sind auch die administrativen Systeme wieder vollständig nutzbar. Alle Systeme sind wieder im Vollbetrieb. Alpein ist operativ zurück – mit gestärkter Infrastruktur und zusätzlichen Erkenntnissen.

Die Anatomie des Angriffs

Die forensische Analyse offenbarte ein zunächst professionell wirkendes Vorgehen. Die Angreifer nutzten eine Schwachstelle in der Scanner-Software als initiales Einfallstor. Über den kompromittierten System-User «Scan» verschafften sie sich Zugang zum internen Netzwerk. Nach professioneller Einschätzung war hier wohl eine Hacker-as-a-Service-­Gruppierung am Werk.

Das nachfolgende Vorgehen liess dann darauf schliessen, dass eher unprofessionell agiert wurde. Den Angreifern gelang es zwar, bekannte Windows-Schwachstellen zu exploitieren und sich dadurch Admin-Rechte zu verschaffen. Die anschliessende Etablierung einer dauerhaften Präsenz im System war jedoch (zum Glück) vergleichsweise auffällig und nicht sauber verschleiert. Dadurch konnte der Zugriff relativ schnell erkannt, nachvollzogen und unterbunden werden.


Die Angreifer exfiltrierten insgesamt rund 301 GB aus dem administrativen Storage. Dabei handelte es sich primär um interne Medien- und Mitarbeiter­daten, unter anderem Personalverträge, Lohnabrechnungen und weitere HR-­Unterlagen. Entscheidend aus Sicht eines IT-Dienstleisters ist jedoch, was nicht kompromittiert wurde: Kundendaten, produktive Systeme, Quellcode sowie Produktionsdatenbanken blieben unerreichbar und waren entsprechend nicht betroffen.

Betrieb bei Ausfall administrativer Systeme

Die gute Nachricht vorweg: Die Produktivsysteme liefen weiter. Kundenservices waren nicht betroffen, die SaaS-Plattformen arbeiteten störungsfrei. Die Netzwerksegmentierung – das von Alpein konsequent verfolgte «U-Boot-Prinzip» – hatte funktioniert. Wie bei einem U-Boot mit wasserdichten Schotten konnte der Angriff nicht auf produktive Bereiche übergreifen. Dennoch bedeuten administrative Ausfälle erhebliche Einschränkungen im Tagesgeschäft.


Die Backup-Strategie erwies sich als entscheidend. Alle betroffenen Daten lagen in verschlüsselten, für die Angreifer unerreichbaren, separaten Backups vor und konnten ohne Verzögerung für die Wiederherstellung genutzt werden. Dies war kein Zufall, sondern das Resultat einer durchdachten Backup-Architektur mit räumlich und logisch getrennten Sicherungssystemen.

Kommunikation unter Unsicherheit

Wenn ein IT-Dienstleister von einem Cyber­angriff betroffen ist, entsteht bei Kunden unweigerlich die Frage: «Sind meine Daten sicher?» Genau diese diffusen Ängste waren die grösste kommunikative Herausforderung. Die Faktenlage war beruhigend: Keine Kundendaten waren abgeflossen, produktive Systeme liefen unbeeinträchtigt. Doch in der öffentlichen Wahrnehmung verschmilzt oft alles zu einem undifferenzierten «wurde gehackt» – mit entsprechend negativen Konnotationen.

Kommunikationsstrategie

ntsprechend wichtig sind Transparenz und proaktive Information. Noch bevor Gerüchte entstehen konnten, wurden Kunden direkt informiert – mit Fakten:
- Was war betroffen? (Administrative Systeme)
- Was war nicht betroffen? (Kunden­daten, Produktivsysteme, Quellcode)
- Welche Massnahmen laufen? (Forensik, Härtung, Meldungen)

Betroffene Mitarbeitende erhielten individuelle Informationen mit detaillierter Auflistung der potenziell kompromittierten Daten, um das persönliche Risiko einschätzen zu können. Diese Offenheit zahlte sich aus: Die befürchtete Verunsicherung blieb weitgehend aus, stattdessen entstand Vertrauen durch den professionellen Umgang.
Wichtig war die Deeskalation in Einzelgesprächen. In direkter Kommunikation mit besorgten Stakeholdern liessen sich technische Hintergründe erläutern und begründen, warum spezifische Kundendaten nicht betroffen waren. In solchen Situationen hilft eine neutrale Stimme von aussen, um Sachlichkeit zu bewahren.

Wiederherstellung zwischen Tempo und Sorgfalt

Die Wiederherstellung war ein Balanceakt zwischen Geschwindigkeit und Gründlichkeit. Einerseits der Druck, schnell wieder voll operativ zu sein. Andererseits die Notwendigkeit, die Angriffsvektoren vollständig zu verstehen und zu schliessen, bevor Systeme wieder ans Netz gehen.

Dank der funktionierenden Backups war die technische Wiederherstellung keine Hürde. Die Herausforderung lag vielmehr in der forensischen Aufarbeitung: Welche Accounts waren kompromittiert? Welche Backdoors könnten existieren? Welche Schwachstellen müssen geschlossen werden, bevor restaurierte Systeme wieder produktiv gehen? Die Entscheidung fiel für einen hybriden Ansatz:


- Produktive Systeme (bereits segmentiert und nicht betroffen) liefen durchgehend weiter.

- Administrative Systeme wurden aus Backups restauriert, aber erst nach Umstellung auf Linux-Systeme und vollständiger Härtung wieder in Betrieb genommen.

- Alle Passwörter wurden präventiv zurückgesetzt.

Diese strategische Bereinigung dauerte knapp drei Wochen – eine aus Sicht eines IT-Dienstleisters vertretbare Zeitspanne, die zeigt: Schnelle Wiederherstellung ist möglich, wenn die Grundlagen stimmen.

Lehren aus dem Vorfall

1. Das U-Boot-Prinzip funktioniert – wenn konsequent umgesetzt
Die Netzwerksegmentierung hat den Schaden deutlich begrenzt. Produktive von administrativen Systemen zu trennen, Kundendaten in separaten, gehärteten Umgebungen zu halten – diese Architekturentscheidungen waren entscheidend. Segmentierung bedeutet nicht nur logische VLANs, sondern auch unterschiedliche Authentifizierungssysteme und separate Zugriffskontrollen.

2. Periphere Geräte sind Einfallstore
Scanner, Drucker, IP-Telefone – diese Geräte werden oft stiefmütterlich behandelt. Standardpasswörter, veraltete Firmware, zu weitreichende Netzwerkzugänge. Jedes ans Netz angeschlossene Gerät ist ein potenzielles Einfallstor und muss entsprechend gehärtet, segmentiert und überwacht werden.


3. Plattformstrategie überdenken
Die drei Windows-Server bei Alpein waren Relikte, die «irgendwie noch gebraucht» wurden – und wurden zum Einfallstor. Die Konsequenz: vollständiger Ausstieg aus Windows in der Infrastruktur. Eine homogene Linux-Landschaft kann Angriffsfläche und Komplexität reduzieren. Das ist nicht für jedes Unternehmen machbar; die zentrale Frage bleibt: Welche Legacy-Systeme schleppen wir mit – und warum?

4. Backup-Strategie als Grundvoraussetzung
Kein Security-Konzept ersetzt ein robustes, getestetes Backup-Regime. Entscheidend sind physisch und logisch getrennte Backups, regelmässige Restore-Tests (nicht nur Backup-Tests) und unveränderbare (immutable) Backups als letzte Schutzschicht.

5. Incident Response braucht gute Vorbereitung
Was bei Alpein funktionierte, war die vorhandene Incident-Response-Struktur. Rollen waren klar: Wer kommuniziert nach aussen? Wer koordiniert die technische Analyse? Wer kümmert sich um regulatorische Meldepflichten? Diese Klarheit verhinderte Chaos.

6. Transparenz schafft Vertrauen
Proaktive, ehrliche Kommunikation war ein wichtiger Faktor. Vorfälle zu verheimlichen oder zu beschönigen, schadet langfristig mehr als kurzfristig unangenehme Transparenz.

7. Keine Zahlung ist auch eine Option
Alpein entschied sich gegen die Lösegeldzahlung. Die Risikoanalyse ergab: Die abgeflossenen Daten (primär interne HR-Unterlagen) hatten für Dritte keinen nennenswerten Wert. Kundendaten waren nicht betroffen und Backups waren intakt. Diese Entscheidung setzt voraus, dass man die Konsequenzen tragen kann und will.

8. Externe Expertise einbinden
Forensische Spezialisten und Datenschutzberater wurden beigezogen. Externe Informationssicherheits- und Compliance-Unterstützung kann in Krisen­situationen deeskalieren und helfen, Entscheidungen nachvollziehbar zu treffen. In der Krise ist nicht die Zeit für «Learning by Doing» – hier zahlt sich Erfahrung aus.

100 Prozent Sicherheit gibt es nicht

Selbst ein spezialisierter IT-Dienstleister mit gehärteten Systemen und geschultem Personal kann Opfer eines gezielten Angriffs werden. Die Frage ist nicht ob, sondern wann – und wie gut man auf diesen Fall vorbereitet ist.

Alpein war in mehreren Punkten vorbereitet: Die Segmentierung funktionierte, die Backups waren intakt, das Team hatte klare Abläufe und kritische Kundendaten blieben unerreicht. Dennoch bedeutete der Vorfall fast drei Wochen Krisenmodus, erheblichen Aufwand sowie Kosten für forensische Analysen und Härtungsmassnahmen.

Schlussfolgerung

Der Ransomware-Angriff auf Alpein Software war eine «Live-Probe» der Sicherheitsarchitektur – und diese Probe wurde bestanden. Nicht, weil der Angriff verhindert wurde, sondern weil die Schadensbegrenzung funktionierte. Das U-Boot-Prinzip erwies sich als tragfähig, die Notfallpläne griffen, und das Team agierte professionell.

Was bleibt, sind konkrete Verbesserungen: eine konsequentere Plattformstrategie, strengere Security-Regeln für periphere Geräte sowie eine weiter gestärkte Monitoring- und Detection-Fähigkeit. Informationssicherheit ist kein statischer Zustand, sondern ein kontinuierlicher Prozess.


Eugen Wiltowski, CTO, Alpein Software fasste den Vorfall drei Monate nach Abschluss der forensischen Analysen folgendermassen zusammen: «Ein ungeheurer Kraftakt und hoher finanzieller Aufwand – zugleich die Bestätigung, dass wir unter Druck sehr professionell reagieren können.»