Am 28. April 2026 veröffentlichte Check Point Research eine technische Analyse der Verschlüsselung von VECT 2.0 (CPR-2026-0428). Das Ergebnis ist eindeutig: Die Verschlüsselung von VECT weist eine bestimmte Schwachstelle auf. Bei jeder Datei, die größer als 128 KB ist, verwendet der Prozess, der eigentlich für jeden Dateiblock einen eindeutigen Verschlüsselungsschlüssel generieren sollte, stattdessen immer wieder denselben Wert, und nur dieser letzte Wert wird gespeichert. Die ersten drei Viertel jeder großen Datei werden dauerhaft verschlüsselt. Sie sind für das Opfer nicht wiederherstellbar. Auch für VECT sind sie nicht wiederherstellbar.
Die Zahlung des Lösegelds führt nicht zur Wiederherstellung großer Dateien. Der Entschlüsselungsschlüssel ist echt. Der Datenverlust tritt ein, noch bevor der Schlüssel überhaupt zum Einsatz kommt.
Diese Erkenntnis ist an sich schon von Bedeutung. Sie ist zudem eine Folge eines eher strukturellen Problems, dem deutlich weniger Aufmerksamkeit geschenkt wurde.
Wie Ziele ausgewählt werden
ransomware meisten ransomware folgen dem gleichen Ablauf. Eine Gruppe identifiziert eine Organisation, verschafft sich Zugriff – entweder selbst oder durch Kauf – und führt dann den Angriff durch. Die Auswahl des Ziels erfolgt, bevor überhaupt Zugriff besteht. Ihr Risiko durch eine bestimmte ransomware hängt davon ab, ob diese Gruppe beschlossen hat, Organisationen wie die Ihre ins Visier zu nehmen.
VECT funktioniert so nicht. Genauso wenig wie sein Lieferkettenpartner TeamPCP.
Der am 2. Juli 2026 veröffentlichte FBI-IC3-Bericht FLASH-20260702-01 dokumentiert eine Kampagne, deren Schwerpunkt eher auf der Reichweite als auf gezielten Angriffen lag. Zwischen Februar und März 2026 manipulierte TeamPCP vier weit verbreitete Open-Source-Softwarepakete, auf die Organisationen bei der Entwicklung und bei Sicherheitsscans zurückgreifen:
- Trivy, ein Tool zum Scannen von Containern auf Sicherheitslücken: TeamPCP nutzte eine Sicherheitslücke (CVE-2026-33634) aus, um 76 von 77 Versionen des automatisierten Workflows von Trivy durch eine bösartige Kopie zu überschreiben. Dazu verwendete die Gruppe gestohlene Entwicklerzugangsdaten, die Schreibzugriff auf das Code-Repository gewährten.
- Checkmarx KICS, ein Tool, das Infrastrukturcode auf Fehlkonfigurationen überprüft: TeamPCP hat ebenfalls 35 Versionen überschrieben. Außerdem nutzten sie die automatisierungsbezogenen Zugangsdaten der jeweiligen Opferorganisationen, um ein verstecktes Repository namens
docs-tpcpim GitHub-Konto des Opfers. - LiteLLM v1.82.8, eine Softwarebibliothek mit etwa 95 Millionen Downloads pro Monat: TeamPCP hat eine Datei namens
litellm_init.pthzur Installation. Dateien mit der.pthErweiterungen werden bei jedem Start von Python automatisch gelesen und ausgeführt, unabhängig davon, welche Software Sie gerade ausführen. Dies ermöglichte es TeamPCP Anhaltende Codeausführung auf jedem Rechner, auf dem das Paket installiert war. - Telnyx Python SDK, Versionen 4.87.1 und 4.87.2: ein dreistufiger Fernzugriffstrojaner, d. h. eine Software, die Angreifern unbemerkt die Kontrolle über den infizierten Rechner verschafft.
TeamPCP ist dieselbe Gruppe, die hinter dem worm „Shai-Hulud“ steckt, der sich mithilfe kompromittierter Pakete automatisch über Entwicklerumgebungen und CI/CD-Pipelines verbreitet. Die Kampagne gegen Trivy und LiteLLM im Februar und März 2026 nutzte denselben zugrunde liegenden Mechanismus: vertrauenswürdiges Paket, automatische Ausführung, Erfassung von Anmeldedaten. „Shai-Hulud Teil 2“ behandelt die TanStack-Kampagne vom Mai 2026, bei der der worm noch einen Schritt weiter worm und gültige kryptografische Signaturzertifikate generierte, um Paketüberprüfungen zu umgehen.
Das Ergebnis: Über 500.000 gestohlene Zugangsdaten aus über 10.000 CI/CD-Pipelines (Continuous Integration and Deployment) – also den automatisierten Systemen, die Software erstellen, testen und bereitstellen. AWS-, Azure- und GCP-Token. Kubernetes-Geheimnisse. Zugangsdaten für Container-Registries. GitHub- und GitLab-Zugriffstoken.
TeamPCP wählte keine Ziele aus, sondern Pakete. Im März 2026 war das Anmeldedatenarchiv bereits vorhanden. VECT durchsuchte es und wählte aus dem Bestand ransomware aus.
Die Zielauswahl erfolgte nach dem Zugriff, nicht davor.
„Gemeinsam sind wir bereit, ransomware allen betroffenen Unternehmen zu verbreiten, die von diesen Angriffen getroffen wurden, und dabei wird es nicht bleiben.“
„Wir werden diese Sicherheitslücken nutzen, um verheerende weitere ransomware zu starten.“
Was sich dadurch hinsichtlich ransomware ändert
Bei ransomware herkömmlichen ransomware lautet die Frage: „Was müsste ein Angreifer tun, um in unsere Umgebung einzudringen?“ Diese Frage geht davon aus, dass der Angreifer sich noch nicht entschieden hat. Das TeamPCP-Modell besagt, dass diese Frage möglicherweise bereits vor Monaten beantwortet wurde – durch eine routinemäßige Paketinstallation in einer Entwicklungspipeline, die Ihr Team inzwischen vergessen hat.
Die Sophos Counter Threat Unit hat mindestens einen VECT-Einsatz bestätigt, bei dem Anmeldedaten aus TeamPCP verwendet wurden. Das FBI warnt davor, dass die gestohlenen Anmeldedaten „noch lange nach dem ursprünglichen Angriff missbraucht werden“. Ob Sie von VECT betroffen sind, hängt nicht davon ab, ob die Gruppe es auf Ihre Branche abgesehen hat, sondern davon, ob sich Ihre cloud in diesem Archiv befinden.
Warum es nicht in Ihren Protokollen erscheint
Das ist Lücke 3: Die Bewegung ist nicht sichtbar.
Die litellm_init.pth Die Persistenzdatei wird bei jedem Python-Start in der betroffenen Umgebung automatisch ausgeführt. Der Softwarepaket-Manager protokolliert eine Installation. Die CI/CD-Pipeline protokolliert die Ausführung eines Workflows, der einem bekannten Dienstkonto zugeordnet ist. Der cloud protokolliert einen authentifizierten API-Aufruf von einer erkannten Identität. Drei Prüfprotokolle, drei SOC-Tickets (Security Operations Center), ein Sicherheitsvorfall.
Kein einzelnes Protokoll zeigt den Weg vom kompromittierten Paket bis cloud auf. Um dies zu rekonstruieren, müssen der Installationszeitstempel, der Workflow-Lauf und der ausgehende API-Aufruf mit einer Liste betroffener Paketversionen abgeglichen werden – eine Liste, die die meisten Unternehmen nicht führen und die die meisten Sicherheitsüberwachungssysteme nicht automatisch überprüfen. Das gleiche Problem fragmentierter Protokolle trat im April 2026 beim Anodot/Snowflake-Vorfall in der Lieferkette auf, bei dem von einem SaaS-Integrationsanbieter gestohlene Token in mehreren Kundenumgebungen wiederverwendet wurden, wobei jedes System seinen eigenen Teil der Aktivität validierte und keines die Zusammenhänge herstellte. Der Fall VECT/TeamPCP folgt dem gleichen Muster, allerdings über die CI/CD-Ebene statt über die SaaS-Integrationsschicht.
Der Checkmarx-KICS-Vektor fügt eine weitere Ebene hinzu. TeamPCP nutzte die eigenen Automatisierungszugangsdaten des Opfers, um docs-tpcp innerhalb der GitHub-Organisation des Opfers. Das Ereignis zur Erstellung des Repositorys erscheint im Audit-Protokoll von GitHub und wird dem Dienstkonto des Opfers zugeordnet. Es sah alles ganz normal aus. Das ist Lücke 1.
Die Kompetenzlücke innerhalb des Betriebs
Die Analyse des Codes von VECT 2.0 durch Check Point ergab eindeutige Anzeichen für eine amateurhafte Entwicklung: Code zur Umgehung von Sicherheitsmaßnahmen, der zwar geschrieben, aber nie tatsächlich ausgeführt wird, eine Verschleierungsschicht, die sich selbst aufhebt, Konfigurationsflags, die flexibel erscheinen, aber tatsächlich fest codiert sind, sowie fehlerhafter Ziertext im Programm. Die Verschlüsselungslücke, die dazu führt, dass VECT die Dateien seiner Opfer dauerhaft zerstört, folgt demselben Muster . Die malware das Werk von Amateuren.
Die dazugehörige Infrastruktur ist es jedoch nicht. Das Partnerprogramm von VECT umfasst Monero-Treuhandkonten (eine auf Datenschutz ausgerichtete Kryptowährung), die Integration mit BreachForums, gestaffelte Provisionen sowie eigens dafür zuständige Verhandlungsführer, die die Gespräche über Lösegeldforderungen führen. Das am 16. April 2026 formalisierte Massen-Partnermodell von BreachForums ermöglicht Betreibern den Zugang zu dieser Infrastruktur, ohne dass sie eine eigene aufbauen müssen. Das Anmelde- und Zugangsdatenarchiv von TeamPCP ersetzt technische Exploit-Kenntnisse: Man benötigt keine Schwachstelle in den Abwehrsystemen des Ziels, wenn man bereits über dessen cloud verfügt.
Dies ist für die Verteidigungsplanung von Bedeutung. Endpoint ordnungsgemäß funktionierende Endpoint erkennt die malware. Der Übertragungsweg über Software-Lieferketten und automatisierte Pipelines löst keine Erkennung aus. Die Erkennung funktioniert zwar, ist aber unvollständig.
Was Sie jetzt überprüfen sollten
Falls in Ihrer Umgebung eines dieser Pakete vor April 2026 ausgeführt wurde, sollten Sie davon ausgehen, dass Ihre cloud für die Pipeline kompromittiert sind, bis Sie das Gegenteil nachweisen können:
- LiteLLM, genauer gesagt Version 1.82.8. Suche außerdem nach
litellm_init.pthin den Python-Installationsverzeichnissen auf allen Rechnern, auf denen LiteLLM im Februar und März 2026 ausgeführt wurde. - Trivy GitHub Action, jede Version, die während dieses Zeitraums auf die Tags 0.76.x oder 0.77.x festgelegt wurde.
- Checkmarx KICS GitHub Action, eines der 35 betroffenen Tags.
- Telnyx Python SDK 4.87.1 oder 4.87.2.
Durchsuche die Repository-Liste deiner GitHub-Organisation nach docs-tpcp. Seine Anwesenheit bedeutet, dass TeamPCP Ihre eigenen Automatisierungszugangsdaten verwendet hat, um es zu erstellen. Wechseln Sie cloud (AWS-, Azure- und GCP-Dienstkonten, Container-Registry-Token sowie GitHub- und GitLab-Zugriffstoken), die vor April 2026 in den betroffenen Umgebungen ausgestellt wurden. Überprüfen Sie Cloud AWS CloudTrail-, Azure Monitor- und GCP Cloud auf API-Aufrufe von Pipeline-Dienstkonten an Produktionsumgebungen im Zeitraum von Februar bis April 2026, insbesondere auf Aufrufe, die vor bekannten Bereitstellungen erfolgten.
Das Kapitel „Lücke 3“ in „Mind Your Attack Gaps“ behandelt die Fallstudiecloud , bei der dasselbe Problem fragmentierter Protokolle in einer anderen Angriffskette auftritt. Bei Vectra AI modellieren wir umgebungsübergreifende Bewegungen zwischen Identitäts-, cloud und SaaS-Systemen, ohne auf Korrelationen zwischen drei separaten Überwachungssystemen angewiesen zu sein. Die TeamPCP/VECT-Kampagne ist ein deutliches Beispiel dafür, warum die Transparenz innerhalb einer einzelnen Umgebung diese Art von Angriffen nicht abdeckt.
Das Anmeldedatenarchiv existiert. Falls Ihre Pipeline die betroffenen Pakete vor April 2026 ausgeführt hat, lautet die entscheidende Frage nun nicht, ob Sie ins Visier geraten könnten, sondern ob Ihre Tokens bereits dort gespeichert sind.