Megalodon besteht laut SafeDep aus zwei Komponenten. Die primäre Schadsoftware fügt eine bösartige YAML-Datei namens „SysDiag" hinzu, die bei jedem Push oder Pull-Request einen neuen Workflow anlegt. Die zielgerichtetere zweite Komponente ersetzt vorhandene Workflows durch einen Auslöser vom Typ „workflow-dispatch", der als verdeckte Hintertür dient: Er entgeht der Erkennung und erzeugt bis zur Aktivierung keine sichtbaren CI-Durchläufe.
„Das macht die Hintertür inaktiv. Sie erzeugt keine sichtbaren Durchläufe im Actions-Tab, keine fehlgeschlagenen Builds, keine Warnsignale in der CI-Historie", erklärte das Unternehmen in seinem Blog. Ein Angreifer könne die Hintertür über eine GitHub-API aktivieren.
Den ersten Hinweis lieferte ein Treffer der Malysis-Engine im npm-Paket @tiledesk/[email protected] der Chatbot-Plattform Tiledesk. Es zeigte sich, dass Tiledesk neun mit einer Hintertür versehene Repositories besaß.
Warum die Kampagne nur sechs Stunden dauerte, ist unklar. Abhisek Datta, Sicherheitsingenieur bei SafeDep, sagte gegenüber Dark Reading, das Forschungsteam habe bei der Analyse kein zeitlich begrenzendes Verhalten beobachtet. „Unsere Hypothese ist, dass die Kampagne gültige Zugangsdaten nutzte, um die Repositories zu infizieren", so Datta. Diese stammten vermutlich aus früheren Angriffen auf die Lieferkette, die sich gegen Entwickler richteten; die Angreifer hätten in dem Zeitfenster wohl alle Zugangsdaten ihrer Liste aufgebraucht.
OX Security veröffentlichte kürzlich ergänzende Forschungsergebnisse und bestätigte, dass rund 3.500 GitHub-Repositories die bösartige YAML-Datei trugen. „Die Zahl der infizierten Repositories ist seit der vergangenen Woche sogar leicht gesunken – von etwa 3.500 auf rund 2.900 –, doch das bedeutet, dass fast 83 Prozent mehr als eine Woche nach dem Angriff weiterhin infiziert sind", sagte Moshe Siman Tov Bustan, Sicherheitsforscher bei OX und Autor des Blogbeitrags, gegenüber Dark Reading. Das Angriffsfenster sei zwar nach etwa sechs Stunden geschlossen worden, GitHub habe die betroffenen Repositories aber noch nicht vollständig bereinigt.
Die Kampagne folgt auf mehrere aufsehenerregende Angriffe auf die Lieferkette, viele davon das Werk einer aufstrebenden Gruppe namens TeamPCP. Megalodons Infektionen ereigneten sich einen Tag, bevor TeamPCP einen großen Einbruch bei GitHub für sich reklamierte, bei dem Code aus rund 4.000 internen Repositories gestohlen wurde.
Ob Megalodon das Werk von TeamPCP ist, bleibt offen. Siman Tov Bustan verwies darauf, dass alle Megalodon-Commits ein fest einprogrammiertes Datum – den 17. September 2001 – sowie gefälschte Bot-Identitäten ([email protected] oder [email protected]) aufweisen, ähnlich dem Verhalten im selbst geleakten Quellcode von TeamPCPs Shai-Hulud-Wurm. Dabei handle es sich jedoch um „oberflächliche Ähnlichkeiten"; es gebe derzeit keine direkten Verbindungen, keine identifizierenden Kompromittierungsindikatoren (IOCs) und kein Bekennerschreiben, das TeamPCP mit Megalodon verknüpfe. Ein aussagekräftiges Signal wäre die Verwendung desselben öffentlichen Schlüssels zur Verschlüsselung gestohlener Daten über mehrere Angriffe hinweg, da nur die Gruppe selbst entschlüsseln könnte.
Datta stimmt zu: Es gebe keine Übereinstimmung technischer Indikatoren, und Payload wie Taktiken, Techniken und Vorgehensweisen (TTPs) sähen anders aus. Angesichts der Hypothese gestohlener Zugangsdaten wolle er eine Zusammenarbeit zwischen TeamPCP und verwandten Gruppen, die Zugänge teilen, jedoch nicht völlig ausschließen. TeamPCP hatte Anfang des Jahres ein offizielles Bündnis mit Vect, einer aufstrebenden Ransomware-Bande, geschlossen.
OX Security rief Organisationen dazu auf, Verbindungen zum C2-Server von Megalodon zu blockieren, ihre GitHub-Repositories auf die Schadsoftware und bösartige YAML-Dateien zu prüfen und bei verdächtiger Aktivität alle Zugangsdaten, SSH-Schlüssel, API-Schlüssel und sonstigen Geheimnisse zu widerrufen und zu erneuern.