Eine gross angelegte Kampagne nutzt kompromittierte GitHub-Konten, um sich in Tausenden Repositories einzunisten. Die Angreifer fokussieren dabei nicht bloss auf Code-Sabotage, sondern auf die wertvollen Geheimnisse, die Entwickler oft fahrlässig in ihren Projekten speichern: API-Schlüssel, Cloud-Anmeldedaten, Zertifikate und Zugriffstoken für AWS, Azure und andere Cloud-Plattformen.
Das Ziel der Kampagne ist perfide: Sobald Hacker diese Credentials erbeuten, können sie nicht nur sofort auf Produktionssysteme zugreifen, sondern auch gezielt Hintertüren in Cloud-Infrastrukturen installieren, Persistenzmechanismen, die auch nach einem Token-Reset Zugang gewähren. Das bedeutet: Selbst wenn ein Unternehmen bemerkt, dass die gestohlenen Geheimnisse kompromittiert sind und alle Schlüssel austauscht, können Angreifer längst wieder Zugang haben.
Für Entwicklungsteams in KMU ist das eine kritische Warnung. Erstens: Geheimnisse gehören niemals ins Git-Repository, nicht mal ins Private-Repository. Stattdessen sollten Umgebungsvariablen, versionskontrollierte Konfigurationsdateien und Secret-Management-Tools (wie HashiCorp Vault oder AWS Secrets Manager) verwendet werden. Zweitens muss GitHub selbst abgesichert sein: starke Passwörter, Zwei-Faktor-Authentifizierung auf allen Konten, regelmässige Überprüfung von Collaborator-Rechten.
Drittens sollte jedes Unternehmen ein Incident-Response-Playbook haben: Wenn ein GitHub-Konto oder Cloud-Token kompromittiert wird, muss nicht nur der Token gesperrt, sondern auch die Cloud-Infrastruktur selbst überprüft werden auf verdächtige Ressourcen, Rollen, Policies oder Netzwerkkonfigurationen, die ein Angreifer hinterlassen haben könnte. Ohne diese tiefergehende Forensik ist der Schaden nicht vollständig behoben.