Ein kompromittierter Account oder Server fühlt sich in kleinen Teams schnell wie ein Kontrollverlust an. Plötzlich ist unklar, ob nur ein Passwort abgegriffen wurde, ob E-Mails mitgelesen werden, ob ein Angreifer noch aktiv ist oder ob schon Daten abgeflossen sind. Genau in dieser Phase entscheidet nicht das beste Security-Tool, sondern die Reihenfolge der nächsten Schritte. Wer hektisch alles gleichzeitig macht, vernichtet Beweise, übersieht Persistenz oder schaltet Systeme ab, bevor klar ist, was betroffen ist.
Incident Response muss für KMU und kleine IT-Teams deshalb pragmatisch sein. Es geht nicht um ein 80-seitiges Konzernhandbuch, sondern um einen Ablauf, der auch an einem Freitagabend funktioniert: Ruhe herstellen, Zugriff stoppen, Schaden eingrenzen, Beweise sichern, Kommunikation ordnen und den Betrieb kontrolliert wieder aufnehmen. Dieser Artikel beschreibt, was nach kompromittierten Microsoft-365-Accounts, Admin-Zugängen oder Linux-Servern sofort passieren muss.
Die erste Stunde: stabilisieren statt improvisieren
Die wichtigste Regel lautet: nicht blind löschen. Viele Teams ändern sofort Passwörter, löschen Mails, starten Server neu oder deaktivieren ganze Dienste. Manche dieser Maßnahmen sind richtig, aber nur in der passenden Reihenfolge. In der ersten Stunde sollte zuerst geklärt werden, welcher Zugang oder welches System konkret betroffen ist und ob der Angreifer noch aktiv sein könnte.
Bei einem kompromittierten Benutzerkonto heißt das: Sessions widerrufen, Passwort ändern, Mehrfaktor-Authentifizierung prüfen, Weiterleitungsregeln suchen und verdächtige OAuth-Apps entfernen. Bei einem Server heißt es: Netzwerkzugriff begrenzen, Snapshots oder Images für spätere Analyse sichern und laufende Prozesse sowie Logdateien erfassen. Für Microsoft-365-Vorfälle passt als Vertiefung der bestehende Leitfaden Microsoft 365 Incident Response, weil dort typische Postfach- und Tenant-Schritte genauer behandelt werden.
Rollen klären, bevor technische Maßnahmen eskalieren
Auch kleine Teams brauchen in einem Sicherheitsvorfall klare Rollen. Eine Person koordiniert, eine Person arbeitet technisch, eine Person hält Entscheidungen und Uhrzeiten fest. Wenn niemand protokolliert, gehen wichtige Details verloren: Wann wurde der Vorfall bemerkt? Wer hat welchen Account deaktiviert? Welche Systeme waren erreichbar? Welche Kunden oder Partner könnten betroffen sein?
Diese Dokumentation muss nicht schön sein. Eine laufende Notiz mit Zeitstempeln reicht am Anfang. Wichtig ist, dass technische Entscheidungen nachvollziehbar bleiben. Das hilft später bei Datenschutzbewertung, Versicherung, externer Unterstützung und interner Nachbereitung. Für Unternehmen ohne klare IT-Verantwortung lohnt sich generell eine schlanke Struktur wie in IT-Betreuung für KMU beschrieben: Zuständigkeiten sind im Ernstfall kein Luxus, sondern Teil der Betriebssicherheit.
Wenn ein Account kompromittiert wurde
Bei kompromittierten Accounts ist das Ziel, den Angreifer aus allen aktiven Sitzungen zu werfen und seine Hintertüren zu entfernen. Nur das Passwort zu ändern reicht nicht. Moderne Angriffe nutzen Token, App-Berechtigungen, Mailregeln oder delegierte Zugriffe. Deshalb sollte die Checkliste mindestens diese Punkte enthalten:
- Alle Sessions widerrufen: aktive Logins und Refresh-Tokens beenden.
- MFA neu bewerten: unbekannte Authenticator-Geräte entfernen und MFA erzwingen.
- Mailregeln prüfen: Weiterleitungen, Löschregeln und versteckte Regeln suchen.
- Delegationen kontrollieren: Postfachzugriffe, Shared Mailboxes und App-Zustimmungen prüfen.
- Umfeld scannen: ähnliche Logins bei weiteren Benutzern oder Admins suchen.
Danach beginnt die Frage nach Auswirkungen. Wurden Rechnungen manipuliert? Gab es Phishing an Kunden? Wurden Dateien heruntergeladen? Diese Prüfung sollte nicht auf den einen Benutzer beschränkt bleiben, denn kompromittierte Accounts werden oft als Sprungbrett genutzt.
Wenn ein Server betroffen ist
Bei Servern ist die Versuchung groß, einfach neu zu starten oder Updates einzuspielen. Das kann Spuren zerstören und hilft wenig, wenn der Angreifer bereits einen SSH-Key, Cronjob oder Dienst hinterlegt hat. Zuerst sollte der Server kontrolliert isoliert werden: nur notwendige Management-Zugriffe erlauben, keine öffentlichen Dienste weiter exponieren und ein Abbild oder zumindest relevante Logs sichern.
Dann folgen die klassischen Prüfpunkte: neue Benutzer, SSH-Keys, ungewöhnliche Prozesse, geplante Jobs, veränderte Systemdienste, offene Ports, Webshells, Deploy-Keys und verdächtige ausgehende Verbindungen. Für Linux-Systeme ist es sinnvoll, nach der Bereinigung nicht nur den ursprünglichen Fehler zu schließen, sondern die Basishärtung insgesamt zu prüfen. Die Linux Server Hardening Checkliste 2026 bietet dafür eine gute technische Grundlage.
Beweise sichern: genug für Entscheidungen, nicht für Perfektion
Kleine Teams müssen keine forensische Spezialabteilung ersetzen. Trotzdem sollten sie die wichtigsten Beweise sichern, bevor Systeme bereinigt werden. Dazu gehören Login-Historien, Admin-Aktionen, Mail-Trace, Firewall-Logs, EDR- oder Antivirus-Meldungen, relevante Webserver-Logs und Screenshots aus Admin-Portalen. Entscheidend ist, dass diese Daten unverändert abgelegt werden und klar ist, wann sie exportiert wurden.
Diese Beweise helfen bei drei Fragen: Wie kam der Angreifer hinein? Wie weit ist er gekommen? Ist er wirklich wieder draußen? Ohne Logs bleibt nach dem ersten Aufräumen oft nur ein Bauchgefühl. Das ist für Datenschutz, Kundenkommunikation und technische Nachbesserung zu wenig.
Wiederanlauf: nicht alles sofort zurück ins Netz
Der Wiederanlauf sollte kontrolliert passieren. Bei Accounts heißt das: betroffene Benutzer neu absichern, riskante Regeln entfernen, Kennwörter nicht wiederverwenden und Admin-Rollen überprüfen. Bei Servern heißt das oft: lieber aus einem sauberen Image neu aufbauen als ein unbekannt kompromittiertes System kosmetisch zu reparieren. Daten werden aus geprüften Backups zurückgeholt, nicht aus einer verdächtigen Umgebung kopiert.
Genau deshalb sind Backup-Tests so wichtig. Im Vorfall zählt nicht, ob irgendwo ein Backup-Job grün war, sondern ob ein Restore schnell und vollständig funktioniert. Der Artikel Backup-Tests richtig machen zeigt, wie kleine Teams Restore-Drills so aufsetzen, dass sie im Ernstfall nicht zum ersten Mal üben.
Kommunikation: intern knapp, extern belastbar
Incident Response ist auch Kommunikation. Intern brauchen Geschäftsführung, IT, Support und betroffene Fachbereiche denselben Stand. Extern darf erst kommuniziert werden, wenn die Faktenlage ausreichend klar ist. Zu frühe Beruhigung ist riskant, zu spätes Informieren kann Vertrauen kosten. Besonders bei personenbezogenen Daten muss geprüft werden, ob eine Meldung an die Datenschutzbehörde oder eine Information an Betroffene nötig ist.
Eine gute Kurzmeldung enthält keine Spekulation, sondern Fakten: Was ist passiert? Welche Systeme sind betroffen? Welche Maßnahmen laufen? Was sollen Mitarbeitende jetzt tun? Für Kunden oder Partner sollte nur kommuniziert werden, was geprüft ist. Wenn Rechnungsbetrug oder Phishing möglich ist, muss die Warnung konkret genug sein, damit Empfänger handeln können.
Nachbereitung: aus dem Vorfall einen besseren Betrieb machen
Nach dem Wiederanlauf beginnt der wichtigste Teil: die Nachbereitung. Viele Teams schließen das Ticket, sobald die Systeme wieder laufen. Damit bleibt die Ursache oft bestehen. Eine saubere Nachbereitung beantwortet mindestens diese Fragen: Was war der initiale Einstieg? Welche Kontrollen haben gefehlt? Welche Warnung wurde übersehen? Welche Entscheidung hat zu lange gedauert? Welche Maßnahme verhindert eine Wiederholung?
Aus diesen Antworten entsteht ein kleiner Maßnahmenplan: MFA überall erzwingen, Admin-Konten trennen, Logging verlängern, Backups testen, Server härten, Awareness verbessern oder Dienstleister-Zuständigkeiten klären. Wer nicht weiß, wo er beginnen soll, kann mit der IT-Checkliste die wichtigsten Basisthemen priorisieren, bevor teure Speziallösungen eingekauft werden.
Fazit
Incident Response für kleine Teams muss einfach, wiederholbar und ehrlich sein. Die ersten Schritte entscheiden darüber, ob ein Vorfall begrenzt bleibt oder sich zu einem langen Blindflug entwickelt. Accounts müssen vollständig aus aktiven Sessions entfernt werden, Server dürfen nicht vorschnell bereinigt werden, Logs müssen gesichert und Entscheidungen dokumentiert werden.
Der beste Zeitpunkt für Vorbereitung ist vor dem Vorfall. Der zweitbeste ist direkt danach, solange die Schwachstellen sichtbar sind. Wer aus jedem Incident einen besseren Ablauf, klarere Rollen und härtere Basissysteme ableitet, reduziert nicht nur das nächste Risiko, sondern gewinnt im Ernstfall wertvolle Zeit.
Ich unterstütze KMU in Oberösterreich und im DACH-Raum bei IT-Automatisierung, Infrastruktur und pragmatischer IT-Betreuung — praxisnah und DSGVO-konform.