FakeGit keert terug met 17.610 kwaadaardige GitHub-repo's
De malwareoperatie FakeGit is weer actief op GitHub, en is nu groter dan voorheen. Onderzoekers tellen 17.610 nep-repository's die de SmartLoader-malware verspreiden. De campagne dook eerder deze maand weer op om de infostealer StealC te verspreiden.
De bevindingen komen van Apiiro, een bedrijf dat zich richt op de beveiliging van de softwareketen. Volgens de onderzoekers werd FakeGit op 4 oktober weer actief.
De meeste accounts achter de repository's lijken wegwerpprofielen die speciaal voor de campagne zijn aangemaakt. De onderzoekers vonden echter ook minstens 700 accounts die van echte ontwikkelaars lijken te zijn.
Een loader vermomd als download
De opzet is eenvoudig. Elke kwaadaardige repository bevat een README-bestand met verzorgde instructies en een downloadknop. Die knop leidt naar een ZIP-archief met SmartLoader, de payload van de eerste fase. SmartLoader haalt vervolgens andere malware binnen en installeert die op het systeem van het slachtoffer.
Dit soort activiteit, met wisselende payloads, wordt al sinds minstens januari waargenomen. De naam FakeGit kreeg de operatie in juli, toen Island, maker van een browserplatform voor bedrijven, rapporteerde over 7.600 nep-repository's op GitHub die SmartLoader verspreidden.
In dat rapport meldde Island dat 800 van de repository's zich voordeden als AI-skills of MCP-servers. MCP-servers zijn componenten waarmee AI-assistenten verbinding kunnen maken met externe tools en data. Deze neppe items verschenen in openbare AI-registers en -catalogi, waar ontwikkelaars naar uitbreidingen zoeken.
13.000 repo's omgebogen in 34 uur
Volgens Apiiro ging de nieuwste golf razendsnel. Binnen 34 uur voerde FakeGit wijzigingen door in meer dan 13.000 repository's. Op het hoogtepunt bewerkte de operator 2.999 repository's per uur.
De wijzigingen waren klein en gericht. "In de commits die we hebben bekeken, raakte 97% alleen de README aan, en liet 88% de 'Download'-knop verwijzen naar een ZIP die SmartLoader installeert", aldus Apiiro.
Dat detail is belangrijk. De aanvaller hoefde voor deze ronde geen nieuwe infrastructuur op te zetten.
"Niemand hoefde ook maar één nieuwe repo aan te maken. De vloot was er al. Die werd gewoon opnieuw gericht", legden de onderzoekers uit.
Waarom verwijderen niet werkt
Apiiro verbindt het uithoudingsvermogen van FakeGit met de manier waarop verwijderingen worden aangepakt. Repository's worden op basis van lijsten offline gehaald, en die lijsten dekken slechts een deel van de kwaadaardige vloot.
Ook het blokkeren van de payloads volstaat niet. Bestanden op een blocklist en hun reservekopieën blijven vaak bereikbaar, waardoor de operator de downloadlink kan aanpassen en dezelfde repository online kan houden.
Ook threat-intelligencefeeds liepen achter. "71% van de vloot ontbrak in URLhaus vóór ons rapport, en een DNS-blocklist op domeinniveau kan geen enkel bestand op GitHub blokkeren zonder GitHub zelf te blokkeren", merkt Apiiro op. URLhaus is een openbare database die URL's bijhoudt die worden gebruikt om malware te verspreiden.
De kwaadaardige archieven stonden op veel plekken binnen GitHub. Onderzoekers vonden ze in forks, oudere bestanden, release-assets, bijlagen bij issues en aparte repository's die alleen dienden om downloads te hosten. Telkens één link verwijderen helpt weinig tegen zo'n verspreiding.
"Verwijder één bestand en de operator kan het lokaas naar een reservekopie laten wijzen: een fork, een oudere ZIP, een release-asset of een bijlage bij een issue", aldus de onderzoekers.
Wat Apiiro aanraadt
De onderzoekers raden gebruikers aan te controleren wie de eigenaar van een repository is voordat ze er iets van downloaden. AI-skills en MCP-servers moeten alleen uit officiële registers of uit de eigen repository's van de leverancier komen.
Wie vermoedt dat SmartLoader op zijn systeem is uitgevoerd, moet dat behandelen als een mogelijke compromittering van zijn GitHub-account. Dat betekent actieve sessies en toegangstokens intrekken en overstappen op passkeys om in te loggen.
Onze analyse
FakeGit laat zien dat het zwakke punt niet langer alleen de malware zelf is, maar het vertrouwen dat ontwikkelaars stellen in een vertrouwd platform. Een GitHub-pagina met een nette README en een downloadknop oogt routineus, en daar rekent de operator precies op. Lopend werk aan verdediging aan de kant van het platform, zoals de push protection-functies van GitHub, richt zich op andere risico's en lijkt niets te doen tegen lokaas dat in README-bestanden zit.
De campagne past ook in een breder patroon waarin aanvallers ecosystemen voor ontwikkelaars als distributiekanaal gebruiken, vergelijkbaar met kwaadaardige npm-pakketten die bedoeld zijn om programmeurs rechtstreeks te bereiken. Het gebruik van neppe AI-skills en MCP-servers wijst erop dat aanvallers ontwikkelaars volgen naar nieuwere, minder volwassen catalogi waar de controle mogelijk minder streng is.
De 700 accounts die van echte ontwikkelaars lijken te zijn, springen eruit. Als die accounts zijn gekaapt, kunnen gestolen inloggegevens de groei van de operatie aanwakkeren. Dat maakt het advies om tokens in te trekken en passkeys te gaan gebruiken des te dringender, ook al blijft de invoering van passkeys achter bij beveiligingsprofessionals.
Het is de moeite waard om te volgen of GitHub verandert hoe het dit soort content verwijdert, en overstapt van verwijderingen op basis van lijsten naar het in één keer opschonen van forks, release-assets en bijlagen. Tot die tijd kan de vloot simpelweg opnieuw worden gericht.