Wenn der virenschutz nichts meldet: wie unternehmen cyberangriffe auf mehreren ebenen rechtzeitig erkennen

Wenn das Antivirenprogramm grün leuchtet, fühlt sich vieles erledigt an, dabei ist genau das heute das Problem. Moderne Angreifer arbeiten mehrstufig, nutzen legitime Werkzeuge, kapern Identitäten und bewegen sich unauffällig durchs Netzwerk, oft wochenlang, bevor Daten abfließen oder Systeme verschlüsselt werden. Für Unternehmen wird frühe Erkennung zur Managementfrage: Welche Signale sind belastbar, welche Kennzahlen zählen, und wie organisiert man Detection so, dass sie nicht nur auf Malware springt, sondern auf das Verhalten dahinter?

Der Alarm bleibt aus, der Angriff läuft

Warum ist „nichts gefunden“ kein gutes Zeichen mehr? Weil ein großer Teil aktueller Vorfälle nicht mit klassischer Malware beginnt, sondern mit Zugangsdaten, die bereits im Umlauf sind, oder mit Täuschung, die Sicherheitssoftware bewusst umgeht. Laut dem Verizon Data Breach Investigations Report (DBIR) 2024 gehört „Use of stolen credentials“ seit Jahren zu den häufigsten Einstiegspunkten, parallel sind Phishing und Social Engineering weiterhin dominierende Muster. In der Praxis bedeutet das: Ein kompromittiertes Konto meldet sich ganz regulär an, nutzt Multifaktor-Umgehungen wie „MFA fatigue“, greift auf Cloud-Dienste zu, lädt Daten herunter, und kein Virenscanner sieht dabei zwingend etwas, weil nichts eindeutig „böse“ aussieht.

Hinzu kommt, dass viele Angriffe „living off the land“ betreiben, also Bordmittel wie PowerShell, WMI oder Remote-Management-Funktionen missbrauchen. Das erschwert die Unterscheidung zwischen Admin-Arbeit und Angriff, wenn Unternehmen keine sauberen Baselines haben. Auch Ransomware ist längst nicht mehr nur ein Verschlüsselungsereignis am Ende, sondern oft der Schlusspunkt einer Kette aus Aufklärung, Privilegienausweitung, lateraler Bewegung und Exfiltration. Der DBIR beschreibt immer wieder, dass die Zeit bis zur Entdeckung stark variiert, und dass die ersten Signale häufig in Logs versteckt sind, die zwar existieren, aber nicht aktiv ausgewertet werden, weil Zuständigkeiten fehlen oder Datenquellen nicht zusammengeführt sind.

Früherkennung heißt deshalb: nicht auf „Schadcode-Fund“ warten, sondern auf Abweichungen im Verhalten. Ungewöhnliche Anmeldezeiten, neue Geräte, atypische Zugriffe auf sensible Datenspeicher, massenhaft fehlgeschlagene Logins, plötzliche Änderungen an Weiterleitungsregeln in E-Mail-Postfächern, und die Nutzung von Admin-Tools außerhalb von Wartungsfenstern sind keine Kleinigkeiten. Sie sind oft die einzigen sichtbaren Spuren in den ersten Tagen, und wer sie nicht sieht, sieht den Angriff erst, wenn es teuer wird: Stillstand, Vertragsstrafen, Rechtskosten, Forensik, Kommunikation, und nicht zuletzt Reputationsschäden.

Welche Signale wirklich belastbar sind

Welche Indikatoren haben Substanz, wenn klassische Signaturen versagen? In der Detection-Praxis haben sich zwei Kategorien bewährt: Identitäts- und Zugriffsauffälligkeiten sowie Datenbewegung. Bei Identitäten sind besonders aussagekräftig: „Impossible travel“ (Anmeldung aus geografisch unplausiblen Regionen), neue Geräte oder Browser-Fingerprints, auffällige OAuth-Consent-Vorgänge in Cloud-Umgebungen, und die Vergabe oder Aktivierung privilegierter Rollen außerhalb definierter Prozesse. Gerade in Microsoft-365-, Google-Workspace- oder AWS-Setups sind Angreifer zunehmend erfolgreich, indem sie Tokens, API-Schlüssel oder App-Registrierungen nutzen, die wie normale Automatisierung wirken.

Bei Datenbewegung zählen Muster, nicht einzelne Ereignisse. Massendownloads aus SharePoint, OneDrive oder internen Fileshares, plötzliche Komprimierung großer Datenmengen, ungewöhnliche Ausleitungen zu selten genutzten Domains, und neue, nicht dokumentierte Synchronisationspfade sind rote Flaggen. Auch DNS-Tunneling und die Nutzung legitimer File-Transfer-Dienste tauchen in Incident-Reports immer wieder auf, weil sie im Alltag ohnehin vorkommen. Eine belastbare Erkennung setzt daher auf Kontext: Welche Abteilung arbeitet wann mit welchen Daten, welche Systeme sprechen typischerweise miteinander, und welche Service-Accounts dürfen welche Aktionen ausführen?

Hilfreich sind messbare, organisatorische Leitplanken, die sich in Monitoring übersetzen lassen. Viele Security-Teams orientieren sich am MITRE-ATT&CK-Framework, das Taktiken und Techniken systematisiert, und leiten daraus Detection-Use-Cases ab: etwa „Credential Dumping“, „Lateral Tool Transfer“, „Remote Services“, oder „Exfiltration over Web Service“. Der Vorteil: Statt abstrakt „mehr Security“ zu fordern, lässt sich konkret prüfen, welche Techniken im eigenen Umfeld erkennbar wären, welche Log-Quellen dafür nötig sind, und welche Alarme mit vertretbarer Fehlalarmquote funktionieren. Gute Detection ist letztlich Handwerk, und sie beginnt mit der ehrlichen Frage: Welche drei Angriffswege sind bei uns am wahrscheinlichsten?

Vom Log-Dschungel zur klaren Lage

Wie kommt man von Millionen Events pro Tag zu einer Lage, die Entscheider verstehen? Der erste Schritt ist weniger technisch als strukturell: Unternehmen müssen festlegen, welche Systeme „Crown Jewels“ sind, also die Daten und Prozesse, deren Ausfall oder Abfluss existenzielle Folgen hätte. Daraus folgt die Priorisierung der Telemetrie. Wer alles loggt, aber nichts auswertet, gewinnt nur Speicherprobleme. Wer hingegen Identitäts-Logs, EDR-Telemetrie, Netzwerkdaten, Cloud-Audit-Logs und kritische Applikationslogs in einem SIEM oder einer vergleichbaren Plattform korreliert, kann Muster erkennen, die jede Quelle für sich verschleiert.

In der Praxis machen ein paar Grundlagen den Unterschied. Erstens: saubere Zeitquellen, konsistente Asset- und Identitätsinventare, und eine minimale Datenhygiene bei Hostnamen, Tags und Rollen, sonst sind Korrelationen wertlos. Zweitens: Alarmregeln, die nicht nur „Event X“ abbilden, sondern Sequenzen, etwa „neues Gerät“ plus „Privilegienänderung“ plus „Zugriff auf sensibles Repository“. Drittens: eine klare Trennung zwischen „Noise“ und „Signal“, was ohne Baselines nicht geht. Baselines müssen nicht perfekt sein, sie müssen nutzbar sein, etwa durch definierte Wartungsfenster, Admin-Jump-Hosts, und standardisierte Remote-Zugänge.

Ein oft unterschätzter Hebel ist die konsequente Protokollierung von Identitätsereignissen, denn viele Angriffe sind heute Identity-first. Dazu gehören MFA-Events, Conditional-Access-Entscheidungen, Token-Ausgaben, und Änderungen an Gruppenmitgliedschaften. Wer zusätzlich Endpoint Detection and Response (EDR) so konfiguriert, dass auch Skript-Ausführung, Credential-Access-Versuche und verdächtige Parent-Child-Prozessketten sichtbar werden, erhöht die Chance auf frühe Stopps. Entscheidend ist, dass die Informationen nicht in Silos bleiben. Ein Angriff ist selten eindimensional, und genau deshalb muss die Erkennung über Ebenen hinweg funktionieren: Identität, Endpoint, Netzwerk, Cloud, und Daten.

Detection braucht Tempo, nicht nur Tools

Was nützen Alarme, wenn niemand reagiert? Viele Unternehmen investieren in Produkte, aber nicht in Abläufe, und das rächt sich im Ernstfall. Frühzeitige Erkennung ist nur so gut wie die Fähigkeit, innerhalb von Minuten zu triagieren, zu isolieren, und die richtigen Personen zu aktivieren. Das beginnt bei definierten Schweregraden, Rufbereitschaften, und Playbooks, die nicht im Wiki verstauben, sondern geübt werden. Tabletop-Übungen mit IT, Security, Legal und Kommunikation sind kein Luxus, sondern die einzige realistische Probe dafür, ob Entscheidungen unter Zeitdruck funktionieren.

Auch Kennzahlen helfen, den Reifegrad zu steuern. „Mean Time to Detect“ (MTTD) und „Mean Time to Respond“ (MTTR) sind klassische Größen, entscheidend ist aber, sie mit Qualität zu füllen: Wie viele Alarme sind echte Incidents, wie hoch ist die False-Positive-Rate, und wie oft werden Fälle zu spät eskaliert? In vielen Branchen steigen zudem regulatorische Anforderungen. Die EU-Richtlinie NIS2 verschärft Pflichten für zahlreiche Sektoren, parallel setzt DORA für den Finanzbereich Standards beim ICT-Risikomanagement. Der Druck wächst also nicht nur durch Angreifer, sondern auch durch Compliance, und wer Detection belastbar aufstellt, reduziert beides: Risiko und Haftungsflächen.

Für kleinere und mittlere Unternehmen ist das kein Argument gegen gute Erkennung, sondern für kluge Skalierung. Managed Detection and Response (MDR) kann 24/7-Fähigkeit liefern, wenn intern Ressourcen fehlen, gleichzeitig bleibt die Hausaufgabe: Sichtbarkeit herstellen, Zugriffe härten, Logging aktivieren, und Verantwortlichkeiten klären. Ohne saubere Kontenlandschaft, konsequenten MFA-Einsatz, Patch-Management und segmentierte Netzwerke ist auch der beste Dienstleister blind. Frühe Erkennung ist am Ende eine Kombination aus Technik, Disziplin und Entscheidungswegen, und sie lohnt sich, weil sie den Schaden typischerweise begrenzt, bevor er in den Betrieb einschlägt.

So starten Unternehmen ohne Überforderung

Wo anfangen, wenn Budget und Zeit begrenzt sind? Mit den Punkten, die am häufigsten den Unterschied machen und die sich vergleichsweise schnell umsetzen lassen. Erstens: Identitäten absichern und überwachen, also MFA konsequent erzwingen, riskante Legacy-Authentifizierung abschalten, privilegierte Konten strikt trennen, und Alarme auf Rollenänderungen sowie ungewöhnliche Logins einrichten. Zweitens: E-Mail und Collaboration schützen, weil Phishing und Kontoübernahmen dort starten, inklusive Monitoring von Weiterleitungsregeln, OAuth-App-Zustimmungen und massenhaften Download-Mustern. Drittens: Endpunkte härten und sichtbar machen, mit EDR auf allen relevanten Systemen, inklusive Servern, und mit klaren Isolationsmöglichkeiten, damit ein kompromittierter Rechner nicht stundenlang weiterfunkt.

Parallel lohnt sich eine pragmatische Use-Case-Liste, die zu den eigenen Top-Risiken passt. Ein mittelständischer Maschinenbauer braucht andere Prioritäten als ein Onlinehändler, dennoch ähneln sich Grundmuster: RDP- und VPN-Missbrauch, kompromittierte Admin-Konten, Datenabfluss über Cloud-Speicher, und laterale Bewegung über schlecht segmentierte Netze. Wer dazu ein kleines Set an Detection-Regeln etabliert, regelmäßig nachschärft, und die Ergebnisse in eine Lageübersicht für die Geschäftsführung übersetzt, baut Schritt für Schritt eine belastbare Früherkennung auf. Wichtig ist der Rhythmus: wöchentliche Reviews der wichtigsten Alarme, monatliche Tests der Reaktionswege, und vierteljährliche Anpassungen anhand neuer Bedrohungslagen, denn Angreifer entwickeln sich schneller als Jahrespläne.

Am Ende ist die entscheidende Kulturfrage simpel: Dürfen Teams schlechte Nachrichten früh melden, oder werden sie dafür abgestraft? Unternehmen, die Early Warning ernst nehmen, schaffen ein Umfeld, in dem Auffälligkeiten nicht wegerklärt werden, sondern untersucht. Genau dort kippt die Statistik zugunsten der Verteidiger, weil aus einem „komischen Login“ ein gestoppter Angriff werden kann, statt ein Vorfall, der erst in der Presse auftaucht. Und wer das vermeiden will, braucht weniger Helden, dafür mehr Routine.

Praktisch planen: Budget, Hilfe, Buchung

Planen Sie für Grundschutz und Monitoring realistisch, viele Unternehmen kalkulieren dafür pro Jahr mindestens einen niedrigen bis mittleren sechsstelligen Betrag, je nach Größe, Toollandschaft und 24/7-Abdeckung. Prüfen Sie Fördermöglichkeiten wie „go-digital“ oder Programme der Bundesländer, und bündeln Sie Maßnahmen, damit Logging, EDR und Identität zusammenwirken. Buchen Sie MDR oder Incident-Response-Retainer früh, im Krisenfall sind Dienstleister oft ausgebucht, und jede Stunde zählt.