Datatyven Vidar gjemmer tekststrengene sine bak en egen virtuell maskin

Zscaler ThreatLabz beskrev 21. september 2026 hvordan datatyven Vidar har endret måten den skjuler tekststrengene sine på. Forskerne fulgte utviklingen fra mai til tidlig i september 2026, fra enkel XOR, via ChaCha20 i intern versjon 1.5 og videre til en endret ChaCha20 fra versjon 1.8. Fra intern versjon 2.0 leser en liten virtuell maskin bytekode fra filen og regner strengene ut under kjøring. Bytekoden gir enten strengen direkte, eller den gir nøkkelen og noncen som et eget strømchiffer bruker til å dekryptere den egentlige strengen. Opkodene, konstantene og oppslagstabellene er ikke de samme fra bygg til bygg.

Analysen dekker interne versjoner fra 2.0 til 3.3, og fire filsummer er oppgitt som kjennetegn. Zscaler oppsummerer det slik at obfuskeringen er laget for å se forskjellig ut fra bygg til bygg mens den gjør den samme jobben. Algoritmene og grensesnittene i verktøyet er enkle og stabile, skriver forskerne, mens konstantene og mikrooperasjonene som statiske signaturer hviler på, byttes ut fortløpende.

Vidar ble først sett i 2018. Malpedia beskriver programmet som en avledning av Arkei, og antar at det var en av de første datatyvene som også hentet informasjon om tofaktorprogramvare og Tor-nettleseren. Obfuskeringen er ikke den eneste delen som utvikles. Gen Digital beskrev 18. juni 2026 hvordan Vidar leter gjennom minnet til en Chromium-nettleser etter hovednøkkelen bak App-Bound Encryption, og deretter bruker APC-injeksjon inne i den kjørende nettleseren for å få nøkkelen dekryptert. Med hovednøkkelen er informasjonskapsler og lagrede passord lesbare.

Bytekode i filenopkodene skifter per byggVirtuell maskingir nøkkel og nonceEget strømchifferkonstantene skifter per byggStrengen i klartekstsamme streng, ny oppskrift
Figur: Bytekoden ligger i filen, og den virtuelle maskinen tolker den under kjøring. Tolkningen gir nøkkelen og noncen som strømchifferet bruker til å dekryptere en egen kryptert bytesekvens, og der ligger selve strengen.

Hva det betyr for deg som eier deteksjonsreglene

Signaturer som leter etter kjent tekst inne i en fil, har lite å gripe fatt i her. Strengene finnes ikke i filen før programmet selv har regnet dem ut, og oppskriften er ny i hvert bygg. Har du bygget deteksjonen på tekst i binærfilen, altså navn på nettlesere, stier til lommebøker eller faste HTTP-headere, mister du treffet selv om oppførselen er den samme.

Vår vurdering er at dette flytter tyngdepunktet mot atferd. Det utvikleren ikke kan bytte ut med tilfeldige verdier, er at programmet må åpne nettleserprofilene, lese i minnet til en annen prosess og til slutt sende byttet ut av maskinen. Blir en regel stille, er det ikke noe bevis for at trusselen er borte, og ingenting i regelen selv forteller deg om den fortsatt treffer.

Berigo anbefaler

  • Test deteksjonsreglene dine mot et nytt bygg av samme skadevarefamilie, ikke bare mot prøven regelen ble skrevet på.
  • Flytt vekten fra tekst i filen til atferd, og varsle på prosesser som åpner nettleserprofiler eller leser i minnet til nettleseren.
  • Gjør en stjålet informasjonskapsel mindre verdt: bind økten til enheten, og kort ned hvor lenge den lever.
  • Krev phishingsikker pålogging med passnøkler eller FIDO2 der kontoen betyr noe, slik at et stjålet passord ikke holder.
  • Behandle en infisert klient som en kontosak: bytt passordene og trekk tilbake øktene, ikke bare vask maskinen.

Sikkerhet som forstås, styres og virker.

La oss hjelpe dere å gjøre sikkerhet til et fortrinn, ikke en kostnad. Ta kontakt for en uforpliktende samtale om hvor virksomheten står, og hva som bør prioriteres først.

Ta kontakt