Angriffe zu spät bemerkt: Erkennungszeit je Signal kennen

Was die Bitkom-Studie über späte Erkennung zeigt

Für die Studie hat Bitkom Research 1.003 Unternehmen ab 10 Beschäftigten in Deutschland befragt (Bitkom). 58 Prozent von ihnen haben in den vergangenen zwölf Monaten einen Schaden durch Cyberangriffe erlitten (Bitkom). Diese 580 geschädigten Unternehmen wurden gefragt, welche Faktoren maßgeblich zum Erfolg des Angriffs beigetragen haben, Mehrfachnennungen waren möglich (Bitkom).

An der Spitze steht mit 59 Prozent die unzureichende Erkennung von Sicherheitsvorfällen (Bitkom). Dicht dahinter folgen Fehlkonfigurationen von IT-Systemen mit 57 Prozent und ein unzureichendes Identitäts- und Zugriffsmanagement mit 55 Prozent (Bitkom). Technische Schwachstellen nennen 50 Prozent, veraltete Hard- oder Software 43 Prozent (Bitkom). Ein unzureichendes Sicherheitsbewusstsein der Beschäftigten führen dagegen nur 18 Prozent an (Bitkom).

Die zweite Zahl wiegt fast schwerer, auch wenn sie weiter gefasst ist: Sie gilt für Datendiebstahl, Industriespionage oder Sabotage insgesamt, klassisch wie digital. Nur noch 67 Prozent der Unternehmen konnten einen erfolgreichen Angriff mit Sicherheit feststellen, ein Jahr zuvor waren es 87 Prozent (Bitkom). Der Anteil derer, die einen Angriff vermuten, ihn aber nicht sicher belegen können, stieg im selben Zeitraum von 10 auf 29 Prozent (Bitkom). Betroffen oder vermutlich betroffen waren insgesamt 96 Prozent der Unternehmen (Bitkom). Die Verschiebung liegt also weniger in der Zahl der Angriffe als darin, wie sicher sich Unternehmen über sie sind.

Die häufigsten Schadensursachen sind keine besonders ausgefeilten oder exotische Angriffe, sondern blinde Flecken im eigenen System. Wer Vorfälle nicht zuverlässig erkennt, kann auch nicht rechtzeitig handeln und wird am Ende womöglich nicht einmal sicher sagen können, was überhaupt passiert ist

— Dr. Wintergerst, Bitkom-Präsident, Presseinformation vom 26. August 2026

Erkennungszeit: Prüftakt plus Weg zum Menschen

Eine Manipulation an der Website meldet sich nicht von selbst. Die Zeit von der Veränderung bis zu dem Moment, in dem ein Mensch davon weiß, setzt sich aus vier Teilen zusammen. Jeder lässt sich einzeln messen und einzeln verkürzen:

1. Wartezeit bis zur nächsten Prüfung. Im ungünstigsten Fall passiert die Änderung direkt nach einer Prüfung und bleibt ein volles Intervall liegen, im Mittel ein halbes.
2. Auswertung. Die Prüfung muss die Änderung als verdächtig einstufen. Ein Hash-Vergleich entscheidet sofort, ein Bildvergleich mit Lernphase erst nach einigen Läufen.
3. Zustellung. Ein Eintrag im Changelog ist noch kein Alarm. Erst eine Meldung über einen Kanal, den jemand liest, macht aus dem Befund eine Nachricht.
4. Reaktion. Jemand muss die Nachricht lesen, einordnen und handeln, auch nachts und am Wochenende.

Der erste Teil steht in der Funktionsbeschreibung des Werkzeugs. Die übrigen drei hängen an der eigenen Organisation: an den Kanälen unter Alerting und Benachrichtigungen, an Bereitschaften und daran, wer Changelog-Einträge liest. Für Ausfälle ist diese Rechnung im Beitrag zum Uptime-Check-Intervall ausgeführt. Bei Manipulationen ist sie strenger, weil sich kein Besucher über eine nicht erreichbare Seite beschwert.

Warum Manipulationen leiser sind als Ausfälle

Ein Ausfall fällt auf, spätestens wenn Bestellungen ausbleiben. Eine Manipulation ist darauf angelegt, nicht aufzufallen. Ein Skimming-Skript liest Karten- und Adressdaten mit, während der Bezahlvorgang normal weiterläuft. Ein geänderter DNS-Eintrag leitet zunächst nur einen Teil der Anfragen um, je nachdem, welcher Resolver noch den alten Wert im Zwischenspeicher hält. Ein Zertifikat für eine nachgemachte Domain betrifft die eigene Website gar nicht, sondern bereitet die Phishing-Seite daneben vor.

Hinzu kommt, dass viele Spuren erst im Nachhinein gelesen werden. Unternehmen, die Täter oder Herkunft eines Angriffs ermitteln konnten, stützten sich dafür am häufigsten auf die Analyse von Log-Dateien, genannt von 68 Prozent (Bitkom). Logs helfen bei der Aufklärung. Für die Erkennung im laufenden Betrieb braucht es dagegen Prüfungen, die einen Sollzustand kennen und eine Abweichung als Meldung ausgeben, bevor jemand danach sucht.

Eine Website bietet dafür mehrere unabhängige Ansatzpunkte: eingebundene Skripte, Erscheinungsbild und Markup, Schutzkopfzeilen, DNS- und Registrierungsdaten sowie öffentlich protokollierte Zertifikate. Jeder wird in einem anderen Takt geprüft und sieht eine andere Art von Manipulation.

Die Signale im Überblick: was welche Prüfung sieht

Die Tabelle ordnet die Signale auf Website-Ebene nach dem Prüftakt, mit dem XICTRAQ® sie laut Funktionsseiten erfasst (XICTRAQ®). Gemeint ist jeweils die längste Wartezeit bis zur nächsten Prüfung in den kostenpflichtigen Plänen, im Free-Plan gelten längere Abstände. Zustellung und Reaktion kommen in jeder Zeile hinzu.

Skript-Hash: das schnellste Signal für Skimming

Web-Skimming verändert ein eingebundenes Skript so, dass es Eingaben im Browser mitliest und an einen fremden Server schickt. Weil sich dabei der Inhalt der Datei ändert, ändert sich auch ihr Hash. Das Script-Integrity-Monitoring lernt beim Scan einer verifizierten Website den SHA-256-Hash der externen Dritt-Skripte als Grundlinie, bis zu 12 je Scan, zusammen mit Host, Größe und Kontext (XICTRAQ®). Alle zehn Minuten ruft ein Prüflauf die überwachten Skripte erneut ab, bis zu 150 je Lauf und die am längsten nicht geprüften zuerst (XICTRAQ®).

Weicht der Hash ab, meldet XICTRAQ® den Drift einmal je Eintrag über die eingerichteten Kanäle, bis jemand ihn bestätigt oder die Überwachung des Eintrags beendet. Nach einem geplanten Update holt die Sofort-Prüfung die Skripte einer Website ohne Wartezeit erneut ab, so lässt sich eine legitime Änderung direkt als neue Grundlinie bestätigen. Dabei zählt die Reihenfolge: erst das Skript inhaltlich ansehen, dann bestätigen. Ein bestätigter Drift gilt danach als Sollzustand.

Für Händler mit Kartenzahlung ist das Thema nicht neu. Der Kartenstandard PCI DSS verlangt mit den Anforderungen 6.4.3 und 11.6.1, dass Skripte auf Zahlungsseiten autorisiert, auf Integrität geprüft und auf Manipulation überwacht werden. Beide Anforderungen gelten seit dem 31. März 2025 (PCI SSC). Welche Prüffrequenz im Einzelfall verlangt ist und ob eine Lösung die Anforderung erfüllt, klären Händler mit ihrem Acquirer oder Prüfer. Ein Monitoring-Werkzeug liefert dafür Messwerte, aber keine Bestätigung der Konformität.

Neue Einbindungen und sichtbare Änderungen erkennen

Ein Angreifer muss kein vorhandenes Skript verändern. Er kann eine neue Zeile in die Vorlage schreiben, die Code von einem fremden Host lädt, oder ein Banner über die Startseite legen. Beides sieht der Zehn-Minuten-Lauf nicht, weil er nur bekannte Skripte erneut abruft. Hier setzt der Seitenvergleich an. Das Screenshot-Changelog nimmt die Seiten je nach Plan alle 24 Stunden (kostenlos) oder alle 12 Stunden (kostenpflichtig) auf (XICTRAQ®), Visual Diff und Defacement-Erkennung gibt es ab dem Starter-Plan.

Die Defacement-Erkennung führt drei Schichten zu einem Score von 0 bis 100 zusammen: den Pixel-Vergleich mit der Grundlinie, einen Hash über das bereinigte HTML und einen Fingerabdruck der DOM-Struktur, der neu hinzugekommene externe Skript- und iframe-Hosts erfasst (XICTRAQ®). Die ersten drei Läufe bilden die Grundlinie und lösen keinen Alarm aus (XICTRAQ®). Ab einem Score von 60 legt XICTRAQ® ein Event an und alarmiert, sinkt der Score im Folgelauf unter 30, schließt sich das Event wieder (XICTRAQ®). Zugeschaltet wird die Erkennung je Website.

Für die Erkennungszeit heißt das: Eine neue fremde Einbindung oder ein sichtbares Defacement fällt in der Regel mit dem nächsten Screenshot-Lauf auf, in den kostenpflichtigen Plänen also nach höchstens zwölf Stunden plus Zustellung. Unabhängig vom Score meldet der Bildvergleich große Abweichungen über 20 Prozent sofort (XICTRAQ®). Damit Slider und nachladende Bilder nicht ständig anschlagen, nimmt XICTRAQ® eine Seite bei mehr als 3,5 Prozent Abweichung in der Regel nach 15 Sekunden ein zweites Mal auf (XICTRAQ®).

Wie eine Verunstaltung technisch entsteht und wann sie nach NIS2 meldepflichtig wird, beschreibt der Beitrag zu Defacement-Angriffen. Welche unerlaubten Inhaltsänderungen es darüber hinaus gibt, steht im Beitrag zum Erkennen von Content-Änderungen.

DNS, Registrar und Zertifikate: Signale außerhalb der Seite

Manche Angriffe verändern die Website gar nicht. Wer den DNS-Eintrag der Domain umbiegt, schickt Besucher auf einen anderen Server, während der eigene unverändert weiterläuft. Das DNS-Monitoring prüft die Einträge alle 6 Stunden, im Free-Plan alle 24 Stunden, und hält Änderungen an A, AAAA, MX, NS und TXT mit altem und neuem Wert im Changelog fest (XICTRAQ®). Wechsel bei A, AAAA und NS sind dort als Warnung markiert, weil sie auf DNS-Hijacking hindeuten können. Eine geänderte CAA-Sperre meldet XICTRAQ® zusätzlich als Alarm.

Dieser Unterschied ist für die Erkennungszeit entscheidend. Ein Eintrag im Changelog ist erfasst, aber noch nicht bemerkt. Wer DNS-Wechsel zügig sehen will, braucht eine feste Durchsicht des Changelogs, etwa jeden Morgen zur gleichen Zeit, und eine Liste der Personen, die Einträge in der Zone ändern dürfen. Wie ein Hijacking abläuft und welche Gegenmaßnahmen an Registrar und Zone greifen, steht im Beitrag zu DNS-Hijacking.

Den Registry-Eintrag fragt XICTRAQ® einmal täglich über RDAP ab (XICTRAQ®). Ein Registrar-Wechsel erscheint als Warnung im Changelog, weil er auf einen unautorisierten Transfer hindeuten kann. Ab dem Business-Plan gleicht die Certificate-Transparency-Watch neu ausgestellte Zertifikate täglich gegen Marke, Lookalike-Varianten und Marken-Keywords ab (XICTRAQ®). Ein solches Zertifikat taucht häufig auf, bevor die nachgemachte Domain überhaupt im DNS auflöst. Warum das funktioniert, erklärt der Beitrag über Certificate-Transparency-Logs.

Fehlkonfiguration und Schwachstellen: Drift in der Konfiguration

Fehlkonfigurationen stehen in der Bitkom-Studie mit 57 Prozent an zweiter Stelle der Schadensfaktoren (Bitkom). Auf Website-Ebene zeigt sich eine solche Drift oft an den Schutzkopfzeilen: Nach einem Update fehlt die Content-Security-Policy, ein vorgeschalteter Proxy entfernt HSTS, ein Plugin setzt den Frame-Schutz zurück. Der Security-Scan prüft Zertifikat und Security-Header in kostenpflichtigen Plänen alle 6 Stunden, im Free-Plan alle 24 Stunden (XICTRAQ®). Fällt der Security-Score unter den eingestellten Mindestwert, kommt ein Alarm, die Vorgabe liegt bei 50 (XICTRAQ®).

Auch die Zahl der bekannt gewordenen Lücken ist gestiegen. Im Berichtszeitraum des BSI-Lageberichts 2025 wurden im Schnitt täglich 119 neue Schwachstellen in IT-Systemen bekannt (BSI), rund 24 Prozent mehr als im vorangegangenen Berichtszeitraum (BSI); einen Teil des Anstiegs führt das BSI auf eine geänderte Melde-Policy zurück. Für die Erkennung heißt das: Eine Konfiguration, die gestern unauffällig war, kann heute eine offene Tür sein, ohne dass sich an der Website selbst etwas geändert hat.

Ein Header-Befund ist selten der Angriff selbst, verschiebt aber die Erkennungszeit an anderer Stelle. Eine Content-Security-Policy mit Meldeadresse lässt Besucher-Browser melden, wenn eine Ressource von einem nicht erlaubten Host geladen werden soll, und XICTRAQ® sammelt diese Meldungen pro Website. Fehlt die Policy, entfällt dieses Signal ganz. Wer HSTS dauerhaft festschreiben will, sollte vorher die Hinweise zum HSTS-Preload lesen.

Was keine dieser Prüfungen sieht

Prüfungen von außen sehen, was die Website ausliefert und was im DNS steht. Was dahinter liegt, bleibt unsichtbar. Das ist kein Mangel einzelner Funktionen, sondern die Grenze des Ansatzes, und sie gehört in jede Planung der Erkennungszeit:

• Dateien auf dem Server. Eine Hintertür im Dateisystem, die nichts an der Ausgabe ändert, sieht keine externe Prüfung. Eine Malware-Analyse auf Dateiebene leistet XICTRAQ® nicht, sie gehört auf den Server selbst, etwa in die Verantwortung des Hosters.
• Zugänge und Konten. Ein neues Administratorkonto im CMS oder ein abgegriffenes Passwort ändern die Seite zunächst nicht. Ein unzureichendes Identitäts- und Zugriffsmanagement nennen 55 Prozent der geschädigten Unternehmen als Faktor (Bitkom). Hier helfen Anmeldeprotokolle und eine Kontenliste mit Stichtag.
• Bedingte Auslieferung. Schadcode, der nur bei bestimmten Besuchern, aus bestimmten Ländern oder nur beim ersten Aufruf erscheint, kann einem Prüfabruf entgehen.
• Eigene Skriptdateien. Dateien vom eigenen Host fallen nicht unter den Hash-Vergleich der Skript-Integrität. Der Seitenvergleich bemerkt sie nur, wenn sie Markup, DOM oder Bild der Seite verändern.
• Abläufe hinter dem Klick. Eine manipulierte Bestellstrecke zeigt sich oft erst im Ablauf. Dafür gibt es Browser-Checks, die einen Weg Schritt für Schritt durchgehen.

Meldefristen beginnen erst mit der Kenntnis

Die Erkennungszeit hat auch eine rechtliche Seite. Liegt eine Verletzung des Schutzes personenbezogener Daten vor, etwa weil ein Skimming-Skript Adress- und Zahlungsdaten abgegriffen hat, meldet der Verantwortliche sie unverzüglich und möglichst binnen 72 Stunden, nachdem ihm die Verletzung bekannt wurde, an die zuständige Aufsichtsbehörde, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die Betroffenen (DSGVO Art. 33).

Für besonders wichtige und wichtige Einrichtungen nach dem BSI-Gesetz gelten bei erheblichen Sicherheitsvorfällen drei Meldungen mit fester Frist: eine frühe Erstmeldung spätestens 24 Stunden nach Kenntniserlangung (BSIG § 32), eine Meldung spätestens nach 72 Stunden (BSIG § 32) und eine Abschlussmeldung spätestens einen Monat nach dieser Meldung (BSIG § 32). Dauert der Vorfall bei Fälligkeit der Abschlussmeldung noch an, tritt zunächst eine Fortschrittsmeldung an ihre Stelle, und die Abschlussmeldung folgt nach abschließender Bearbeitung; auf Ersuchen des BSI kommt eine Zwischenmeldung hinzu.

Beide Fristen laufen ab der Kenntnis, nicht ab dem Angriff. Eine späte Erkennung verlängert also nicht die Zeit für die Meldung, sondern die Zeit, in der der Schaden unbemerkt wächst: Jede Stunde zwischen Manipulation und Alarm ist eine Stunde, in der ein Skimmer weiter mitlesen kann. Ob ein konkreter Vorfall meldepflichtig ist, hängt vom Einzelfall ab und gehört in die Hände des Datenschutzbeauftragten oder der Rechtsberatung. Wie Eskalationsstufen und Zuständigkeiten für den Ernstfall aussehen, beschreibt der Beitrag zu Incident Management und Eskalation.

Erkennungszeit je Signal festlegen: ein Arbeitsblatt

Aus den Bausteinen wird eine Tabelle je Website: wie lange eine Manipulation höchstens bis zur nächsten Prüfung liegen bleibt und was danach passiert. Sieben Schritte führen dorthin:

1. Schutzgüter festlegen. Checkout und Formularseiten, Startseite, DNS-Zone, Domain-Registrierung, Marke.
2. Signal zuordnen. Je Schutzgut die Prüfung, die eine Manipulation dort zuerst sieht: Skript-Hash für den Checkout, Defacement-Score für die Startseite, DNS- und RDAP-Prüfung für Zone und Registrierung, Certificate-Transparency-Watch für die Marke.
3. Prüftakt eintragen. Die längste Wartezeit laut Plan, nicht den günstigsten Fall.
4. Meldeweg prüfen. Alarm über einen Kanal oder nur ein Eintrag im Changelog? Für Changelog-Einträge eine feste Durchsicht vereinbaren.
5. Reaktionszeit vereinbaren. Wer reagiert werktags, wer nachts, und bis wann.
6. Lücken benennen. Was keine Prüfung abdeckt, bekommt einen Verantwortlichen außerhalb des Monitorings.
7. Üben. Regelmäßig einen echten Alarm auslösen und messen, wann er gelesen wurde.

website: shop.beispiel.invalid
stand: 2026-10-30
signale:
  - schutzgut: Checkout
    signal: Skript-Hash externer Skripte
    takt: 10 min
    meldung: Alarm per E-Mail und Chat
    reaktion: 30 min werktags, 2 h nachts
  - schutzgut: Startseite
    signal: Defacement-Score
    takt: 12 h
    meldung: Alarm ab Score 60
    reaktion: 2 h
  - schutzgut: DNS-Zone
    signal: Wechsel bei A, AAAA, NS
    takt: 6 h
    meldung: Warnung im Changelog
    durchsicht: werktags 9 Uhr
  - schutzgut: Marke
    signal: Certificate-Transparency-Watch
    takt: 24 h
    meldung: Treffer im Dashboard
ohne_signal:
  - Dateien auf dem Server: Hoster, wöchentliche Integritätsprüfung
  - CMS-Konten: Agentur, Kontenliste zum Monatsersten

Für einen Shop im Business-Plan heißt das: Am Checkout liegt die Wartezeit bis zur nächsten Skript-Prüfung bei höchstens zehn Minuten, an der Startseite bei höchstens zwölf Stunden, im DNS bei höchstens sechs Stunden plus der Zeit bis zur nächsten Durchsicht des Changelogs (XICTRAQ®). Ob die Kette danach trägt, zeigt nur ein Test. Wie eine solche Alarmierungsübung aufgebaut ist, beschreibt ein eigener Beitrag.

Vom Signal zur Reaktion

Ein Alarm verkürzt die Erkennungszeit nur, wenn klar ist, was danach geschieht. Bewährt hat sich eine kurze Abfolge, die für jedes Signal gleich bleibt:

Erkennungszeit als Kennzahl im Betrieb verankern

Die Bitkom-Zahlen zeigen, dass Unternehmen weniger an exotischen Angriffen scheitern als an Vorfällen, die sie zu spät oder gar nicht bemerken. Wer für jede Website die Erkennungszeit je Signal kennt, kann gezielt verkürzen: den Prüftakt dort, wo er zählt, den Meldeweg dort, wo ein Changelog-Eintrag ungelesen liegen bleibt, und die Reaktion dort, wo nachts niemand erreichbar ist. Welche Prüftakte welcher Plan mitbringt, steht auf der Preisseite.