Supply-Chain-Angriff aus Verteidigersicht: was das Blue Team sehen kann

Kurzfassung: Bei einem Supply-Chain-Angriff kompromittiert der Angreifer nicht das Ziel direkt, sondern einen Lieferanten: ein Software-Update, eine Bibliothek, ein Build-System, einen Dienstleister mit Zugang. Das Blue Team sieht davon oft wenig, weil die bösartige Komponente signiert und vertrauenswürdig ankommt. Was hilft, ist ein Inventar dessen, was man einsetzt (SBOM), das Beobachten des Verhaltens nach einem Update statt nur der Datei, und die Annahme, dass auch vertrauenswürdige Software sich plötzlich falsch verhalten kann. Reine Prävention gibt es nicht; die Verteidigung liegt in Sichtbarkeit, Segmentierung und der Fähigkeit, den Radius eines kompromittierten Lieferanten zu begrenzen.

Der Supply-Chain-Angriff ist die Bedrohung, bei der die übliche Verteidigungslogik versagt, weil der Angriff durch die Vordertür kommt, mit gültigem Ausweis. Nicht das eigene System wird kompromittiert, sondern etwas, dem das eigene System vertraut: der Hersteller einer Software, deren Update automatisch eingespielt wird, eine Open-Source-Bibliothek, die im eigenen Produkt steckt, ein Dienstleister mit Fernzugang. Weil die bösartige Komponente auf dem üblichen, vertrauenswürdigen Weg ankommt, oft signiert, greifen weder Signaturprüfung noch das Bauchgefühl. Dieser Beitrag ordnet die Angriffsarten ein, erklärt ehrlich, was das Blue Team überhaupt sehen kann, und beschreibt die Maßnahmen, die den Schaden begrenzen, wenn Prävention nicht möglich ist.

Die Angriffsarten

  • Kompromittiertes Software-Update. Der Angreifer dringt in den Hersteller ein und schleust bösartigen Code in ein reguläres, signiertes Update, das dann automatisch an alle Kunden verteilt wird. Das ist der Fall mit der größten Reichweite, weil ein einziger Einbruch tausende Ziele erreicht, und der am schwersten zu erkennende, weil das Update echt signiert ist.
  • Kompromittierte Abhängigkeit. Eine Open-Source-Bibliothek wird übernommen oder ein bösartiges Paket unter täuschend ähnlichem Namen veröffentlicht (Typosquatting), und Entwickler ziehen es beim nächsten Build automatisch mit. Betrifft vor allem Organisationen, die selbst Software bauen.
  • Kompromittiertes Build-System. Nicht der Quellcode, sondern der Bauprozess wird manipuliert, sodass aus sauberem Code ein verseuchtes Artefakt entsteht. Besonders heimtückisch, weil der Quellcode unverändert aussieht.
  • Kompromittierter Dienstleister. Ein IT-Dienstleister, ein Managed-Service-Anbieter oder ein Lieferant mit Fernzugang wird übernommen, und der Angreifer nutzt dessen legitimen Zugang zu vielen Kunden. Der Zugang ist echt, die Nutzung nicht.
  • Manipulierte Hardware oder Firmware. Seltener, aber am tiefsten: Schadcode in Geräte-Firmware, der unterhalb des Betriebssystems sitzt und kaum zu finden ist.

In der Cyber Kill Chain verschiebt der Supply-Chain-Angriff die ersten Phasen zum Lieferanten: Aufklärung, Waffenbau und Zustellung passieren dort, und beim Ziel beginnt die sichtbare Kette erst mit der Ausführung des verseuchten Artefakts.

Was das Blue Team sehen kann und was nicht

Die ehrliche Antwort zuerst: Den Einbruch beim Lieferanten sieht das eigene SOC nicht, und das signierte bösartige Update erkennt keine Signaturprüfung. Was das Blue Team sehen kann, ist das Verhalten der Komponente, nachdem sie im eigenen Netz aktiv wird. Eine legitime Software, die nach einem Update plötzlich etwas tut, was sie vorher nie getan hat, ist das zentrale Signal.

  • Neues Verhalten nach einem Update. Ein Prozess einer vertrauenswürdigen Anwendung baut nach einem Update erstmals eine Verbindung nach außen auf, startet eine PowerShell, liest Zugangsdaten oder schreibt in ungewöhnliche Pfade. Genau das war das Muster in den großen bekannten Fällen, und genau das zeigen Sysmon und ein EDR, wenn sie auf Verhalten statt auf Signaturen achten.
  • Ungewöhnlicher ausgehender Verkehr. Ein Server oder eine Anwendung, die nie mit dem Internet gesprochen hat, baut Verbindungen zu unbekannten Zielen auf. Der Netzwerksensor sieht das unabhängig vom Endpunkt, wie im Beitrag zu Zeek beschrieben.
  • Der Dienstleisterzugang, der sich anders verhält. Beim kompromittierten Dienstleister ist der Zugang legitim, aber die Nutzung fällt aus dem Rahmen: Anmeldung zu ungewöhnlicher Zeit, Zugriff auf Systeme, die der Dienstleister sonst nie berührt, seitliche Bewegung. Das ist die Erkennung, die im Beitrag zur seitlichen Bewegung steht, angewandt auf ein externes Konto.
  • Threat Intelligence zum Vorfall. Wird ein Supply-Chain-Vorfall öffentlich, liefert die Threat Intelligence Indikatoren: betroffene Versionen, Hashes, C2-Adressen. Die Rückwärtssuche im SIEM, ob man selbst betroffen ist, ist dann der erste Schritt.

Der gemeinsame Nenner: Das Blue Team erkennt den Supply-Chain-Angriff nicht am Eintritt, sondern an den Handlungen danach. Deshalb ist die verhaltensbasierte Erkennung aus der Serie Angriff erkennen hier die eigentliche Verteidigung: Die Technik nach dem Eintritt, das Nachladen, die seitliche Bewegung, die Persistenz, ist dieselbe wie bei jedem anderen Angriff.

Das Inventar: SBOM und Bestandswissen

Die wichtigste Vorarbeit ist zu wissen, was man überhaupt einsetzt. Wenn ein Supply-Chain-Vorfall bekannt wird, ist die erste Frage: Sind wir betroffen? Wer sie nicht in Minuten beantworten kann, verliert Tage. Eine Software Bill of Materials (SBOM) ist die Antwort: eine maschinenlesbare Liste aller Komponenten und Abhängigkeiten einer Software, mit Versionen. Für selbst gebaute Software lässt sie sich beim Build automatisch erzeugen, für eingekaufte Software verlangt man sie zunehmend vom Hersteller; regulatorisch gewinnt die SBOM an Gewicht. Aber auch ohne formale SBOM gilt: Ein gepflegtes Inventar der eingesetzten Software, ihrer Versionen und der Systeme, auf denen sie läuft, ist die Grundlage jeder Reaktion. Wer bei einem öffentlich gewordenen Vorfall die betroffene Version in seinem Inventar sucht und findet, hat den Vorsprung, der über den Schaden entscheidet.

Den Radius begrenzen

Weil der Eintritt kaum zu verhindern ist, verlagert sich die Verteidigung auf die Begrenzung des Schadens, wenn eine vertrauenswürdige Komponente sich als bösartig erweist.

  • Segmentierung. Eine Anwendung oder ein Dienstleisterzugang, der kompromittiert wird, sollte nicht das ganze Netz erreichen. Netzsegmente, die nur die nötigen Verbindungen erlauben, machen aus einem Vollkompromiss einen begrenzten Vorfall.
  • Least Privilege für Software und Dienstleister. Eine Anwendung braucht selten Adminrechte auf dem ganzen System, ein Dienstleister selten Zugang zu allem. Je enger die Rechte, desto kleiner der Radius, den ein kompromittierter Lieferant erreicht.
  • Ausgehende Kontrolle. Wenn Server nur zu den Zielen sprechen dürfen, die sie brauchen, läuft die Command-and-Control-Verbindung einer verseuchten Komponente ins Leere oder fällt als blockierte Verbindung auf.
  • Updates gestaffelt einspielen. Ein Update nicht sofort auf allen Systemen, sondern zuerst auf einer kleinen Gruppe, und diese Gruppe beobachten. Das kostet etwas Aktualität, verhindert aber, dass ein verseuchtes Update in einem Zug die gesamte Flotte trifft. Die Abwägung gegen das Risiko ungepatchter Schwachstellen ist real und gehört bewusst getroffen.
  • Lieferanten prüfen. Die Sicherheit eines Lieferanten ist Teil des eigenen Risikos. Ein Mindestmaß an Prüfung, welche Sicherheitszusagen ein kritischer Lieferant macht und wie er im Vorfall informiert, gehört in die Beschaffung, nicht nur in die IT.

Reaktion auf einen bekannt gewordenen Vorfall

Wenn ein Supply-Chain-Vorfall öffentlich wird, läuft die Reaktion in einer klaren Reihenfolge: Betroffenheit prüfen über das Inventar und die Rückwärtssuche nach den veröffentlichten Indikatoren im SIEM; bei Betroffenheit die betroffene Komponente isolieren oder abschalten, soweit der Betrieb es zulässt; nach den Handlungen suchen, die die verseuchte Komponente auf den betroffenen Systemen ausgeführt hat, also den normalen Incident-Response-Prozess mit Beweissicherung; und die Meldepflichten prüfen. Der Zeitvorteil entscheidet, und er hängt fast ganz am Inventar: Wer in Minuten weiß, ob und wo er die betroffene Version einsetzt, reagiert, während andere noch suchen.

Fazit

Der Supply-Chain-Angriff entzieht sich der klassischen Prävention, weil er das Vertrauen selbst ausnutzt, das Software-Updates und Dienstleister genießen. Das Blue Team kann den Eintritt nicht verhindern, aber es kann drei Dinge tun: das Verhalten nach einem Update beobachten statt nur die Datei, ein Inventar pflegen, das die Frage nach der Betroffenheit in Minuten beantwortet, und den Radius eines kompromittierten Lieferanten durch Segmentierung, minimale Rechte und ausgehende Kontrolle begrenzen. Damit wird aus einem potenziellen Vollkompromiss ein beherrschbarer Vorfall. Für ein Blue Team ist die Lehre, dass Vertrauen kein Sicherheitskonzept ist und dass die Verteidigung dort ansetzt, wo das Vertrauen missbraucht wird: beim Verhalten.

NH

$ whoami

Norbert Hofmann

Cyber Defense Analyst im Security Operations Center eines Managed Security Service Providers. Red und Blue Teaming, Malware-Analyse, Incident Response und Security-Awareness-Trainings. Finalist bei „Deutschlands bester Hacker“ 2022, mehrere CVE-Einträge für WordPress-Plugins.