Ende Oktober 2024 ist die Scheidt GmbH & Co. KG Ziel eines Hackerangriffs geworden und musste ihre gesamten Systeme neu aufbauen. Die SySS hat Scheidt von Anfang an, d. h. zunächst mit Incident Response und dann mit Beratung beim Wiederaufbau, unterstützt. Schließlich konnte die SySS Scheidt im Februar 2025 in einem großen Pentest ein gutes Sicherheitsniveau bestätigen.
Was war passiert? Und welche Schritte waren auf dem gemeinsamen Weg zu gehen? Im Gespräch schauen Alejandro von Fersen und Harald Schweitzer von der Scheidt IT gemeinsam mit Thomas Markloff und Julian Gruber-Roët von der SySS zurück in die aufregenden Wochen und arbeitsreichen Monate – und geben anderen Unternehmen Tipps, wie sie im Ernstfall das Schlimmste verhindern können.
Am Samstag eines langen Wochenendes arbeiten die ITler der Scheidt rund um Alejandro von Fersen und Harald Schweitzer mit einem externen Partner an ihren Systemen, um ein weiteres System in Betrieb zu nehmen. Plötzlich fragt der remote zugeschaltete Techniker: „Warum habt Ihr den Server runtergefahren?“ Als die Antwort „Hab ich nicht.“ lautet, wird schnell klar, dass noch eine weitere Partei im Netzwerk ist. Das zeigt sich auch daran, dass offenbar Dateien umbenannt werden – und zwar unerwünscht und unautorisiert. Alejandro von Fersen fährt unverzüglich in die Firma und trennt die Internetverbindung. „Damit war erstmal Ruhe.“ Allerdings war nun aber auch die komplette Firma offline, sämtliche Online-Aktivitäten liefen über einen Handy-Hotspot.
Noch am selben Tag informiert er die Geschäftsleitung von Scheidt darüber, dass „wir Opfer eines Hackerangriffs sind“. Die Geschäftsführerin Georgine Scheidt handelt schnell und organisiert IT-Forensik-Experten. Auf die SySS kam sie durch Empfehlungen. Die Kontaktaufnahme mit der SySS war unkompliziert und IT Forensic Consultant Thomas Markloff machte einen ersten Termin direkt am Sonntag möglich.
Am Anfang stehen viele Fragen. Die Betroffenen interessiert: Was ist kaputt? Was ist verfügbar? Was ist nicht verfügbar? „Das war alles in den Sternen.“, erinnern sich Alejandro und Harald.
Der Incident Responder, der in so eine Situation kommt, will als erstes wissen: Was ist passiert? Wann ist es passiert? Wie ist es passiert? Wer und was ist davon betroffen? Was wurde bis jetzt unternommen? Mit diesen Fragen verschafft sich Thomas einen ersten Überblick und leitet daraus die nötigen Erstmaßnahmen ab. Schnell ist eine Prioritäten- und Todo-Liste erstellt. Auf ihr steht u. a.:
- Prüfen, welche Backups vorhanden sind
- Waschstraße aufbauen
- Passwörter rotieren
- Images erstellen
- Festlegen, wie der Notbetrieb aufgebaut werden soll
Ganz oben steht auch: „Das, was an Daten noch da und verfügbar ist, auf Datenträger sichern.“
Der Prozess der Verschlüsselung hatte schon gestartet, ein System war bereits komplett verschlüsselt. Die Datenbanken mit den wichtigen Informationen des Unternehmens waren jedoch nicht verschlüsselt. Rückblickend war die Arbeit am Wochenende das große Glück der Scheidt GmbH & Co. KG. „Wir hatten die glückliche Fügung, dass wir überhaupt noch rangekommen sind, dadurch, dass wir es rechtzeitig gemerkt haben. Wären die Angreifer fertig geworden, hätten wir die Systeme und Daten niemals erreicht.“, meint Alejandro. Und Harald ist sich sicher: „Wenn wir am Montag in die Firma gekommen wären, wäre es zu spät gewesen.“ Aus seiner Erfahrung als Responder kann Thomas klar bestätigen, dass Angreifer sehr genau nach den Geschäftszeiten ihrer Opfer schauen. Sichtungen nehmen sie zunächst während der Geschäftszeiten vor, das Ausrollen von Malware erfolgt dann häufig am Wochenende. „Der initiale Angriff kommt meistens an einem Wochenende. Ganz, ganz bevorzugt sind Feiertage oder Ferienzeiten.“
Der zweite Tag der Incident Response ist dann wieder ein Werktag. Gemeinsam kümmern sich Alejandro und Thomas und die Meldepflichten von Scheidt, die Anzeige, die Datenschutzmeldung, und stellen die relevanten Informationen für die Stakeholderkommunikation bereit.
Außerdem werden jede Menge Festplatten gekauft. Und dann kommt die Waschstraße. „Wir haben unter Anleitung von Thomas und seinen Kollegen eine sogenannte ‚Waschstraße‘ aufgebaut, in der die Daten, die wir gesichert haben, einmal gescannt wurden, ob etwas kompromittiert ist, Makros oder sonstiger Schadcode enthalten sind.“ Sobald das ausgeschlossen ist, können die Daten freigegeben und für die Wiederherstellung verwendet werden.
Alles geht sehr zügig. Die Waschstraße steht schon nach einer Woche und ist fleißig am Scannen. Derweil entscheidet sich Scheidt für einen kompletten Neuaufbau ihres Netzwerks. Thomas erstellt ein Lastenheft für ein neues Active Directory. Er ist überzeugt: „Ein Incident ist immer auch eine Chance.“ Und hier kommt nach der Wochenendarbeit die nächste glückliche Fügung: Scheidt war gerade ohnehin im Begriff, einiges an der Netzwerkinfrastruktur umzustellen. Die Angreifer waren zwar schneller, aber Scheidt konnte aus dem Vollen schöpfen. „Wir hatten neue Server, wir hatten neue Switches – wir hatten alles da. Wir konnten sofort loslegen.“ Schon in der zweiten Woche nach dem Sicherheitsvorfall liefen die ersten Server in einem neuen, „gewaschenen“ Netzwerk.
All das wird geplant, unterstützt und überprüft von den Respondern der SySS – zuerst in täglichen Meetings, dann in Austauschterminen zweimal pro Woche und schließlich in wöchentlichen Meetings. In den ersten Wochen ist Thomas rund um die Uhr telefonisch für Alejandro und sein Team erreichbar.
Die Incident Response erstreckt sich über ca. drei Wochen. Wann gilt eine Incident Response eigentlich als abgeschlossen? „Wenn der Kunde wieder auf eigenen Beinen steht, Aufgaben selber abarbeiten kann und keine dauerhafte Erreichbarkeit mehr braucht.“, erklärt Thomas.
Bei Scheidt bedeutet das konkret, dass die Firma innerhalb von vier Wochen wieder arbeitsfähig ist. „Wir konnten produzieren, liefern, Angebote und Auftragsbestätigungen rausschicken, Rechnungen schreiben etc. Das wurde von den Kunden sehr positiv aufgenommen. Die Außenwirkung war nach kürzester Zeit ‚Wir sind wieder da!‘“
Als dieser Punkt erreicht und das neue Netzwerk aufgebaut ist, schlägt die SySS eine Art „Notfallpentest“ vor. Das Ziel ist, zu prüfen, ob das neu aufgebaute Netz den aktuellen Sicherheitsstandards entspricht. Es soll schließlich sicher in Betrieb genommen werden können. Den Test übernimmt SySS-Consultant Julian Gruber-Roët, der den Fall bislang nicht kennt. So ein Notfallpentest ist weniger umfangreich als ein normaler Test eines internen Netzwerks. Vor allem prüft Julian auf „die großen Fehler, also die low-hanging fruits für Angreifer. Das sind meist große Schwachstellen mit großen Auswirkungen, die durch kleine Konfigurationsfehler entstehen.“ Tatsächlich findet Julian genau so eine Art Schwachstelle: ein Fehler in der Standardkonfiguration einer Zertifizierungsstelle, über die Angreifer potenziell das gesamte Netzwerk übernehmen können. Die Anpassung der Konfiguration ist für Alejandro, Harald und die anderen eine Kleinigkeit – der Sicherheitsgewinn und auch der Lerneffekt sind dagegen sehr groß.
Julians Aufgabe ist es auch, das Konzept zu bewerten, damit Alejandro und sein Team noch nachjustieren können, bevor alles in die Umsetzung geht. Dem anschließenden „großen Pentest“ sieht IT-Leiter Alejandro trotz Beratung und Zwischenpentest dennoch mit Nervosität entgegen. „Der größte Feind ist zeitlicher Druck.“, meint er. „Da kann es vorkommen, dass man auf die Schnelle mal was macht, dessen Konsequenzen man nicht absehen konnte.“ Eben wie bei den Zertifikaten. Der Blick von außen, ist er sicher, bringt eine Perspektive, die intern oft fehlt, und zeigt Konsequenzen auf, die man selber nicht sieht. „Wenn man vorgeführt bekommt, was Angreifer anrichten können, ist es eventuell erschreckend, aber es öffnet einem auch die Augen, um zu sagen: ‚Bleibt wach, Jungs! Bleibt wach!‘“ Scheidt, resümiert Alejandro, „konnte auf jeden Fall von dem Pentest profitieren, vor allem, weil man da noch etwas ändern kann. Bei einem echten Angriff kann ich nichts mehr ändern. Da ist es dann zu spät.“
Bei unserem Gespräch ein Jahr später stellen wir fest, dass sich insbesondere auch bei den Mitarbeitenden viel getan hat in Sachen Awareness für IT-Sicherheit. Thomas ist begeistert von der großen Akzeptanz für starke Passwörter bei Scheidt – das kennt er auch anders. Harald berichtet, dass bei ihm weiterhin regelmäßig Nachfragen zum Öffnen von E-Mails u. ä. eingehen. „Die Kolleginnen und Kollegen sind hochsensibel.“, beobachtet er.
Ein Jahr später steht Scheidt also technisch wie auch organisatorisch gesehen besser da als vor dem Incident. Gefragt danach, welchen Anteil die SySS daran hatte, antwortet Alejandro: „Ohne die Hilfe der SySS hätten wir sicher länger gebraucht. Allein das Konzeptionelle, die Sicherheitserwägungen und Best Practices: Das hätte Ewigkeiten gedauert. Die Mitarbeit der SySS war hier Gold wert.“
14.04.2026
- 15.04.2026
Hack1/Hack2: Hacking Workshop
16.04.2026
- 17.04.2026
Hack1/Hack2: Hacking Workshop
20.04.2026
- 24.04.2026
SySS auf der Hannover Messe
21.04.2026
- 22.04.2026
Hack12: Angriffe gegen Entra ID und Azure-Umgebungen
Ihr direkter Kontakt zu SySS +49 7071 407856-9107 oder anfrage@syss.de | Sie haben einen Cybersicherheitsvorfall? +49 7071 407856-99
Ihr direkter Kontakt zu SySS +49 7071 407856-9107 oder anfrage@syss.de
Sie haben einen Cybersicherheitsvorfall? +49 7071 407856-99
Direkter Kontakt
+49 7071 407856-9107 oder anfrage@syss.de
Sie haben einen Cybersicherheitsvorfall?