Inleiding
Kekw blijft evolueren – Op dinsdag 24/04 merkte een collega van ons red team een post op security.stackexchange.com. De post was gemaakt op 15/04 en de gebruiker wil dat iemand de code bekijkt van de GitHub repository die gelinkt is in de post om te verifiëren of er iets vreemds is met de code. De gebruiker meldt dat het programma werkt zoals verwacht, maar dat hij waarschuwingen begon te ontvangen voor inlogpogingen voor meerdere accounts.
Enkele dagen nadat mijn collega me hierover vertelde, werd het bericht verwijderd en is het niet langer toegankelijk.
Eerste analyse
Als we het GitHub account ApfelsaftDevs (niet meer beschikbaar) onderzoeken, kunnen we zien dat het account is aangemaakt op 14 juni 2022.
Het account blijft slapend zonder repositories en begint eind februari/begin maart actief te worden. Vooral in april zien we bijna elke dag activiteit totdat het account wordt verwijderd. Zelfs in het weekend.
Het account bevatte veel verschillende repositories met tools die gebruikt kunnen worden voor allerlei verschillende doeleinden, sommige meer legitiem dan andere.
Naam en beschrijving analyse
Op basis van de naam en beschrijving kunnen we zien dat er tools zijn die een enigszins legitieme use case hebben. Bijvoorbeeld een tool voor Discord die kan worden gebruikt om directe berichten naar veel accounts tegelijk te sturen. Maar we zien ook andere repositories die duidelijk alleen maar kwaadaardige bedoelingen hebben.
Getrojaniseerd
Wat al deze tools gemeen hebben, is dat ze zijn getrojaniseerd met Kekw-malware. Deze malware wordt geladen via schadelijke Python-pakketten wanneer de tool wordt uitgevoerd. Het zijn deze schadelijke Python-pakketten die steeds worden verwijderd, meestal binnen 24-48 uur, waardoor de bedreigende actor bijna dagelijks alle repositories moet bijwerken.
Als we kijken naar een van de commits voor deze repositories, kunnen we zien dat er 2 regels zijn veranderd helemaal aan het begin van het main.py Python script. Regel nummer 2 download het kwaadaardige pakket en regel nummer 3 importeert het pakket.
De blog van Cyble Research and Intelligence Labs (CRIL) geeft een goede analyse van het schadelijke Python-pakket. De blog van Cyble vermeldt het gebruik van Anti-VM variabelen. Na een snelle analyse lijken de waarden in deze variabelen afkomstig te zijn van een “virustotal-vm-blacklist” repository op GitHub. Ik kon snel twee repositories identificeren met deze informatie.
De eerste repository is van Zed1242 en lijkt de originele repository te zijn waarop de andere is gebaseerd.
De repository van 6nz bevat veel meer informatie en wordt vaker bijgewerkt. Het ligt 1969 commits voor, maar slechts 3 commits achter op het eerste repository op het moment van schrijven, wat laat zien dat het actueler is.
Automatisering
In de commit beschrijving kunnen we ook tekenen van automatisering zien. Hoe deze automatisering werkt is iets waar ik niet naar gekeken heb en valt buiten het bereik van deze blog.
Zoals te zien is aan het begin van de blog, lijken de kwaadaardige PyPi pakketten het meest waarschijnlijk verspreid en gedownload te worden via deze tools. Dit is iets wat de blog van Cyble, tweets van beveiligingsbedrijf ESET en verschillende nieuwsartikelen(1, 2, 3, 4) niet vermelden.
Na contact met de onderzoeker van ESET waar ik de GitHub repositories noemde die werden gebruikt om de pakketten te verspreiden, werden ze op één na allemaal kort daarna offline gehaald door GitHub. Eén GitHub account bleef online (PatrickPogoda), waardoor ik deze dreiging kon blijven volgen. Dit account had dezelfde repositories als “ApfelsaftDev” en bleef bijna dagelijks updaten totdat het midden mei offline werd gehaald.
De eerste van vele
De allereerste versie die ik analyseerde was een Python script met bijna geen obfuscatie en meer dan 1700 regels code. Dit is waarschijnlijk dezelfde versie die door Cyble is geanalyseerd.
PyPi pakketnaam: pyfontingtools
Versie: 1.0.0
Een eenvoudig script als dit wordt vrij gemakkelijk gedetecteerd door de meeste bekende AV-bedrijven.
Hoe zit het met het tweede script?
Ja, dat is een verwijzing naar Lord of the Rings en geen typefout. Hobbits hebben niet alleen seconden, maar ook dreigingsacteurs.
In het script is slechts één regel code versluierd door gebruik te maken van Fernet encryptie. Aangezien deze code niet wordt geanalyseerd in de blog van Cyble, laten we hier zelf eens naar kijken.
Wanneer het gedecodeerd wordt, krijgen we een ander Python-script met slechts één functie genaamd “inject”. Het script is vrij eenvoudig zonder verduistering.
Hoe werkt het?
Het script importeert en downloadt de nodige legitieme modules.
Verschillende variabelen worden gedefinieerd en het script controleert op het bestaan van %localappdata%/exodus (C:\Users\
Als het niet bestaat, retourneert de functie en stopt het script.
Als de map bestaat, gaat het script verder en begint alle bestanden in deze map op te sommen en voegt ze toe aan de variabele “apps”.
De URL waarvan het bestand app.asar wordt gedownload en de user agent header die moet worden gebruikt, wordt gedefinieerd. Deze worden vervolgens gebruikt om het bestand te downloaden.
Het .asar-bestand is een archiefformaat dat is ontworpen voor Electron-toepassingen.
De volledige gebruikte user agent: “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, zoals Gecko) Chrome/89.0.4389.82 Safari/537.36”
Een Discord webhook wordt gedefinieerd, evenals de exodus.wallet en de locatie van een .zip-bestand dat door het script wordt aangemaakt.
Volgende stappen
Na het definiëren van deze variabelen doorloopt het script alle bestanden en mappen in de map exodus.wallet en plaatst al die informatie in het archief exoduswallet.zip dat hierboven is gedefinieerd.
Upload het zipbestand naar gofile[.]io, sla de downloadlink op in de exolink variabele en stuur die informatie naar de Discord webhook waardoor de aanvaller het zipbestand kan downloaden.
Het exodus.exe proces wordt gedood
De laatste stap van de functie is het schrijven van het app.asar bestand naar elke waarde in de apps lijst, die werd gedefinieerd op regel 16.
In dezelfde lus wordt de waarde in de khook variabele naar elke waarde in de apps lijst geschreven als een bestand met de naam LICENSE.
Na het schrijven van de functie moet deze nog worden uitgevoerd. Dit gebeurt aan het einde van het script.
Het script krijgt een lage score van 3/60 op VirusTotal.
App.asar heeft slechts 2 treffers op VirusTotal.
Het lijkt erop dat dit tweede script puur gericht is op het stelen van Exodus wallets, terwijl het eerste script een meer generiek stealerscript is. ESET was in staat om het te vergelijken met verschillende anders genoemde stealers in hun eerder gelinkte tweets, dankzij hun uitgebreide database.
Minder is meer
Verdedigers ontwikkelen hun mogelijkheden, maar aanvallers ook.
Pypi pakket pyfontingtools versie 1.0.0 bevatte het volledige kwaadaardige script. Dit script wordt gemakkelijk gedetecteerd, zoals eerder werd aangetoond (17 VT hits).
De bedreigende actor paste het uploadproces aan en veranderde het. Voor nieuwe pakketten zou de initiële PyPi 1.0.0 upload alleen een eenvoudige “Hello World” afdrukken.
Slechts enkele minuten later uploadt de bedreigingsacteur een nieuwe versie, 1.1.0. Deze nieuwe versie bevat slechts 4 regels code.
Deze keer analyseer ik v1.1.0 van het PyPi-pakket “syssqlitedbpackageV1”.
De bedreigende actor gebruikt opnieuw Fernet-encryptie om de werkelijke payload te verbergen. De hele opdracht op regel 4 bevat 96211 tekens!
Na het decoderen wordt het duidelijk waarom het Fernet commando zo lang was. Het is precies hetzelfde script als het eerste (pyfontingtools).
Laten we diff gebruiken om te verifiëren!
De uitvoer toont twee verschillende regels. Dit is waarschijnlijk een probleem door het copy-pasten van het ene script en het decoderen van het andere. Er is geen echte code verschillend.
Het veranderen van het script met de payload versleuteld doet het werk goed als het gaat om AV-detectie. 0 hits op VT.
Het is morphing tijd!
Een dag later wordt een nieuwe versie van syssqlitedbpackageV1 geüpload. Ik merkte dit toevallig kort nadat de dreigingsacteur een nieuwe versie had geüpload. Ik zweer dat ik niet de bedreigende actor ben 🙂
Niet alleen de code is gewijzigd, maar ook de auteur! Bij het analyseren van veel verschillende PyPi-pakketten die door de bedreigende actor werden gebruikt, werden altijd deze twee auteurs (Jozef M en NHJonas) gebruikt. Het account van de beheerder was bijna altijd een nieuw aangemaakt en verschillend account voor elk kwaadaardig pakket.
Versie 1.2.0 van het PyPi-pakket “syssqlitedbpackageV1”.
Laten we eens kijken naar de code voor deze nieuwe versie!
Dit keer bestaat het script uit slechts 49 regels code. Wederom inclusief een hele lange regel met Fernet gecodeerde code.
Verschillende modules worden geïmporteerd en er worden er nog meer gedownload.
De huidige gebruiker ophalen.
Loop door de map %localappdata%\Programs\Python en zoek naar mappen die beginnen met Python.
Kopieer voor elke gevonden Python-versie de map “Cryptodome” en kopieer deze naar de map “Crypto” in dezelfde bovenliggende map.
Verschillende lege coderegels worden gevolgd door het definiëren van de pl-variabele.
De subprocesmodule wordt geïmporteerd en de variabele creationflags wordt ingesteld om een nieuwe procesgroep aan te maken (om beheer van kindprocessen mogelijk te maken) en het proces wordt onzichtbaar voor de gebruiker gespawnd (CREATE_NO_WINDOW). Vervolgens wordt de nu bekende uitvoering van een Fernet gecodeerd commando gedefinieerd.
Stel de locatie van %appdata% in en voeg pl.py eraan toe Op regel 29 en 30 wordt variabele pl gebruikt om te schrijven naar het bestand %appdata%\pl.py dat hierboven is gedefinieerd.
Vlaggen
Creationflags variabele wordt opnieuw ingesteld met iets andere waarden. Deze keer worden ze buiten de pl variabele gebruikt. De “DETACHED_PROCESS” vlag maakt een nieuw proces aan, los van het bovenliggende proces. Dit wordt waarschijnlijk gedaan om detectie te omzeilen en om een incident response onderzoek moeilijker te maken.
Het vers aangemaakte Python-script pl.py wordt uitgevoerd.
Het script schrijft dan het Python-script run.py, gedownload van het kewltd[.]ru-domein, naar een van de vastgecodeerde mappen binnen %appdata%. Op regel 40 krijgt het bestand het attribuut hidden (“+h”) en wordt aangegeven dat het proces in een shell-omgeving moet worden uitgevoerd (“shell=True”).
Uiteindelijk voert het script alle run.py scripts uit die in de verschillende hardgecodeerde mappen in de variabele startup_folder staan.
Het run.py script is zwaar versleuteld en gaat mijn huidige niveau te boven om het om te kunnen keren. Als je dit leest en het wilt proberen, kun je het ophalen uit de urlscan.io scan die ik heb gedaan. De bedreiger heeft echter wel een bericht achtergelaten voor iedereen die het script onderzoekt.
Nu het leesbare script is geanalyseerd, is het tijd om in de versleutelde Fernet-code te duiken!
Fernet gecodeerde code
Om te beginnen heeft het script een paar veranderingen, maar het is grotendeels hetzelfde. Dus, wat is er veranderd?
Waar het pakket pyfontingtoolsV1 (het allereerste script) de os.system module gebruikte om alle benodigde PyPi pakketten te downloaden, gebruikt deze versie de subprocess.Popen module om cmd.exe te starten om pip install te starten om de hardcoded modules te installeren. Beide keren met creationflags variabele aan het einde (niet zichtbaar in de tweede schermafbeelding).
In deze versie van het script is de speciale Exodus portemonnee stealer niet meer versleuteld met een ander Fernet commando, maar staat het nu in platte tekst in het script.
Hoewel versie 1.2.0 mogelijk schadelijke code bevat, wordt de belangrijkste payload versleuteld met Fernet en omzeilt het met succes alle AV-detecties op VirusTotal.
PyPi komt in actie
PyPi werd zwaar getroffen door de toevloed van kwaadaardige pakketten die dagelijks werden geüpload en ondernam verschillende acties.
Op 20 mei 2023 schort PyPi de registratie van nieuwe gebruikers en nieuwe projecten tijdelijk op. Een dag later, ongeveer 30 uur na de aankondiging, is de schorsing weer opgeheven.
Registratie van nieuwe gebruikers en nieuwe projectnamen op PyPI is tijdelijk opgeschort. De hoeveelheid kwaadwillende gebruikers en kwaadwillende projecten die in de afgelopen week zijn aangemaakt op de index heeft ons vermogen om hier tijdig op te reageren overtroffen, vooral omdat meerdere PyPI-beheerders met verlof zijn.
Terwijl we ons hergroeperen tijdens het weekend, is de registratie van nieuwe gebruikers en nieuwe projecten tijdelijk opgeschort.
https://status.python.org/incidents/qy2t9mjjcc7g
Op 25 mei 2023 kondigt PyPi aan nog een stap verder te gaan en 2FA af te dwingen voor beheerders van projecten of organisaties tegen het einde van 2023.
Vandaag, als onderdeel van die lange termijn inspanning om het Python ecosysteem te beveiligen, kondigen we aan dat elk account dat een project of organisatie onderhoudt op PyPI verplicht zal zijn om 2FA in te schakelen op hun account tegen het einde van 2023.
Tussen nu en het einde van het jaar zal PyPI beginnen met het beperken van de toegang tot bepaalde functies op basis van 2FA-gebruik. Daarnaast kunnen we beginnen met het selecteren van bepaalde gebruikers of projecten voor vervroegde handhaving.
https://blog.pypi.org/posts/2023-05-25-securing-pypi-with-2fa/
Conclusie
Degene die verantwoordelijk is voor de ontwikkeling van de Kekw-malware toont veerkracht bij het updaten van de malware om detectie te voorkomen. De dreiger gebruikt waarschijnlijk ook een vorm van automatisering om nieuwe pakketten te uploaden naar PyPi en alle verschillende GitHub-repositories bij te werken. Aanvankelijk op meerdere accounts, maar na acties aan GitHub-zijde, slechts op één account.
Aan de andere kant heeft PyPi ook goed werk geleverd door de schadelijke pakketten zo snel mogelijk te verwijderen. Het tijdelijk stopzetten van registraties moet een moeilijke beslissing zijn geweest. Met de handhaving van 2FA zullen bedreigingen zoals deze waarschijnlijk minder voorkomen. Het afdwingen van 2FA heeft als bijkomend voordeel dat een compromittering van de toeleveringsketen ook wat moeilijker wordt.
Ondanks dit alles is de dreigingsacteur nog niet van de aardbodem verdwenen en maakte hij onlangs een comeback na 1-2 weken downtime.
More about that in my next blog which will come (hopefully) very soon!
