Am 4. August machte das Bundesamt für Informatik und Telekommunikation (BIT) einen Angriff auf seine SharePoint-Server öffentlich. Betroffen sind Zugangsdaten zu rund 200 Benutzer- und technischen Konten. Das BIT betreibt diese Server selbst, in den Rechenzentren des Bundes.
Die Zeitachse ist der eigentliche Inhalt der Meldung. Microsoft legte die betroffenen Schwachstellen Mitte Juli offen. Das BIT schreibt, man habe umgehend mit der Installation der Updates begonnen. Am 28. Juli fielen Auffälligkeiten auf den Servern auf, am 31. Juli war der unbefugte Zugriff bestätigt, am 4. August folgte die Meldung. Zwischen der Offenlegung der Lücken und dem Tag, an dem die Auffälligkeiten entdeckt wurden, lagen also knapp zwei Wochen — und in diesem Fenster waren die Angreifer schneller als die Aktualisierung eines produktiven Systems, das nicht einfach neu gestartet werden kann.
Wie ernst die Lücken waren, zeigt ein Detail am Rand: Die US-Behörde CISA hatte sie bereits in ihren Katalog der nachweislich ausgenutzten Schwachstellen aufgenommen. Wer eine solche Lücke offenlässt, wartet nicht auf einen möglichen Angriff, sondern auf einen laufenden.
Was das BIT richtig gemacht hat
Es wäre bequem, hier auf Behördenversagen zu zeigen. Die Reaktion war aber genau das, was ein Notfallplan leisten soll — und sie ist deshalb die brauchbarere Lehre:
Der Angriff wurde überhaupt bemerkt. Nicht von Dritten gemeldet, nicht durch eine Erpressung sichtbar geworden, sondern durch eigene Auffälligkeiten auf dem System.
Der Internetzugriff auf SharePoint wurde umgehend blockiert. Erreichbarkeit wurde der Eindämmung geopfert, nicht umgekehrt.
Alle betroffenen Passwörter wurden zurückgesetzt — bei kompromittierten Zugangsdaten die einzige wirksame Reaktion.
Die Server werden neu aufgesetzt, nicht bereinigt. Das ist die unbequeme, aber richtige Entscheidung: Nach einem bestätigten Einbruch weiss niemand mit Sicherheit, was zurückgeblieben ist.
Die technischen Indikatoren gingen an das Bundesamt für Cybersicherheit und an Betreiber kritischer Infrastrukturen weiter, damit andere in ihren eigenen Systemen nachsehen können.
Diese fünf Punkte sind übertragbar, unabhängig von der Grösse. Nur: Sie setzen voraus, dass jemand hinsieht, dass jemand entscheidungsbefugt ist und dass ein Wiederaufbau überhaupt möglich wäre.
Die Schweizer Ausgangslage
Wie es damit in kleineren Betrieben aussieht, hat BDO im Juni zusammengetragen: 2025 wurden dem BACS 104 Ransomware-Angriffe gemeldet, der durchschnittliche Schaden für ein KMU lag bei rund 84'000 Franken. Rund 25'000 KMU wurden nach dieser Erhebung Opfer eines schweren Angriffs. Nur 30 Prozent verfügen über einen Notfallplan, nur 20 Prozent haben je ein Sicherheits-Audit durchführen lassen, und 42 Prozent fühlen sich ausreichend vorbereitet. Diese Zahlen stammen aus einer Beratungspublikation, nicht aus einer amtlichen Statistik — die Richtung deckt sich aber mit dem, was das BACS in seinen Halbjahresberichten ausweist, und mit unseren eigenen Beobachtungen der letzten Wochen, zusammengefasst in der Bedrohungslage 2026.
Ein Notfallplan bei 30 Prozent heisst im Umkehrschluss: In sieben von zehn Betrieben wird im Ernstfall improvisiert — an dem Tag, an dem am wenigsten Zeit dafür ist.
Selbst betreiben, betreiben lassen — oder das Schlimmste dazwischen
Der Vorfall beim BIT betraf eine selbst betriebene Anwendung auf eigenen Servern. Das ist ein legitimes Modell; für ein Bundesamt mit eigenem Sicherheitsteam ist es das richtige. Der Preis dafür ist die Betriebslast: aktualisieren, beobachten, im Notfall handeln.
Problematisch ist ein dritter Zustand, den wir in der Praxis am häufigsten sehen: Ein eigener virtueller Server, irgendwann von einem Dienstleister aufgesetzt, seither ohne festen Zuständigen. Formal selbst betrieben, tatsächlich von niemandem. Solche Systeme laufen jahrelang unauffällig — bis eine Lücke wie die oben genannte kommt. Dann fehlt beides: die Aktualisierung und das Hinsehen.
Wer diese Last nicht selbst tragen will, muss sie abgeben. Wir bieten dafür zwei Wege an, und beide gehen über unser eigenes Hosting-Panel.
Was unser Panel dabei abnimmt
Hostsys ist die deutschsprachige Alternative zu Plesk, cPanel und DirectAdmin, entwickelt und betrieben von Cyberdine Systems. Wir haben es gebaut, weil wir über zehn Jahre mit den englischsprachigen Panels gearbeitet haben und deren Schwachstellen kennen. Details zum Aufbau stehen im Beitrag zum Launch von Hostsys.
Fünf Dinge daraus zahlen sich in genau der Lage aus, die das BIT gerade durchlebt:
Versionierte, verschlüsselte Backups mit borgbackup. Dedupliziert und mit Historie — entscheidend, weil ein einzelnes Backup nach einem Einbruch oft schon den kompromittierten Zustand enthält. Warum eine Kopie nicht genügt, steht in unserem Beitrag zur 3-2-1-Strategie.
Audit-Log. Wer hat wann was geändert. Ohne diese Spur ist «Auffälligkeiten entdeckt» kein realistischer Satz.
Fail2ban und UFW-Firewall. Serverseitige Härtung gegen automatisierte Anmeldeversuche — der häufigste Weg hinein führt über gültige Zugangsdaten, nicht über eine exotische Lücke.
Let's-Encrypt-Auto-SSL für alle Domains, auch Wildcard über DNS-01. Zertifikate erneuern sich ohne Zutun. Das wird wichtiger, je kürzer die Laufzeiten werden — siehe Let's Encrypt und die 6-Tage-Zertifikate.
Mail-Stack mit Postfix, Dovecot, Rspamd und ClamAV. Spam- und Virenschutz auf dem Server, nicht als Zusatzabo.
Dazu: vollständig Open Source, kein Cloud-Zwang, Datenhaltung nach nDSG und DSGVO, und eine durchgehend deutsche Oberfläche statt halb übersetzter Begriffe.
Zwei Modelle stehen zur Wahl. Bei den Panel-Lizenzen installieren Sie Hostsys auf Ihrem eigenen Server und behalten die Kontrolle — den Betrieb übernehmen Sie. Bei den Managed Servern übernehmen wir ihn: Betriebssystem und Dienste aktualisieren wir, wir beobachten die Systeme und melden uns, wenn etwas auffällt. Genau das, was im Fall des BIT die entscheidende Rolle gespielt hat.
Und die ehrliche Abgrenzung: Ein Panel aktualisiert kein SharePoint und kein WordPress-Plugin. Es sorgt für die Serverebene und dafür, dass Abweichungen auffallen. Die Anwendung darüber braucht ihre eigene Betreuung — dafür gibt es Wartungsverträge mit Monitoring. Wie still ein Kernupdate scheitern kann, haben wir am Beispiel von WordPress 7.0.3 beschrieben.
Vier Fragen, die Sie heute beantworten können
Wer ist zuständig, wenn morgen eine Lücke wie diese bekannt wird — namentlich, nicht «die IT»?
Wie schnell würden Sie merken, dass jemand drin ist? Beim BIT waren es Auffälligkeiten im eigenen System. Was wäre bei Ihnen das Äquivalent?
Wie alt ist Ihre älteste Sicherungskopie, und wann wurde sie zuletzt zurückgespielt?
Wenn Sie einen Server neu aufsetzen müssten wie das BIT gerade — wüsste jemand, wie?
Wenn Sie bei einer dieser Fragen zögern, sehen wir uns Ihre Umgebung an und sagen Ihnen, wo Sie stehen. Bei einem konkreten Verdacht führt der Weg über die Hack- & Malware-Bereinigung, die den Einbruchsweg sucht und nicht nur die Version hochzählt.