PowerWare-ransomware doet zich voor als Locky-variant

Beveiligingsonderzoekers van Unit 42, onderdeel van Palo Alto Networks, hebben een nieuwe versie van ransomware ontdekt die zich voordoet als de bekende Locky-variant. De malware versleutelt bestanden echter maar gedeeltelijk en is eenvoudig te verwijderen.

De onderzoekers schrijven dat de ransomware bestanden voorziet van de 'locky'-extensie en ook de mededeling overneemt, waarin Locky om losgeld vraagt. Door zich voor te doen als een bekende soort ransomware hopen de criminelen achter deze variant dat slachtoffers alsnog tot betaling overgaan. Volgens Unit 42 heeft de PowerWare-variant vaker andere malware geïmiteerd.

Deze vorm van ransomware blijkt echter alleen de eerste 2048 bytes van bestanden op de computer van het slachtoffer te versleutelen met 128bit-aes. Daarnaast is de sleutel voor decryptie aanwezig in de broncode van de malware. Daardoor is het eenvoudig de infectie ongedaan te maken. De onderzoekers hebben voor dat doel een tool online gezet.

De infectie door PowerWare vindt plaats via een .NET-bestand dat een Powershell-script uitpakt, waarmee naar bestanden op de pc van het slachtoffer wordt gezocht.

De waarschuwing die slachtoffers te zien krijgen

Reacties (27)

[FREAKJAM]

Dit is al de 2de locky-variant in een paar weken tijd. Recent is ook de Zepto variant opgedoken, die min of meer hetzelfde doet met je bestanden.

Voor ons systeembeheerders kun je een hoop voorkomen door met File Screening te werken. Met FSRM kun je bijvoorbeeld de extensie .locky, .zepto etc blokkeren en scheelt je dat een hoop ellende mocht je virusscanner/anti-malware je in de steek laten. Handig blogje met meer instructies over hoe FSRM in te stellen inclusief file screens vind je hier. Er is ook een handig powershell script die de hele riedel voor je instelt.

[henk717]

Ik ben zelf op een betere methode over gegaan en heb onze consultants kunnen overtuigen het te implementeren bij een aantal klanten. Wij noemen het de Tripwire. Je monitored simpelweg lok bestanden op de server, bestand weg? Server dicht. Simpel concept maar zeer effectief!

Er is zelfs een gratis tool mocht je niet je eigen variant willen bouwen. Toch raad ik dit wel aan om de malware een stap voor te blijven.

Het voordeel van lok bestanden boven de bovenstaande methode is het feit dat dit zeer toekomst bestendig is. Wij gebruiken diverse file names met een steek woord. Aangezien het een zelf gebouwde methode is (Gebasseerd op de tool die ik heb gelinked) kunnen malware vendors niet achterhalen welke triggers wij gebruiken. In mijn tests zijn ongeveer 6 bestanden ge-crypt voordat de file sharing service werdt uitgezet.

[Reactie gewijzigd door henk717 op 25 juli 2024 08:50]

[Bor]

Ik ben zelf op een betere methode over gegaan en heb onze consultants kunnen overtuigen het te implementeren bij een aantal klanten. Wij noemen het de Tripwire. Je monitored simpelweg lok bestanden op de server, bestand weg? Server dicht. Simpel concept maar zeer effectief!

Zeer effectief inderdaad, je hebt hiermee namelijk een erg makkelijke manier geïntroduceerd voor een denial of service. Immers is nu het weggooien van een bestandje voldoende om de server dicht te gooien. Leuk bedacht maar de introductie van een nieuw security gat kan ik nauwelijks effectief noemen.

Hiernaast werk deze aanpak alleen echt als de malware de trigger bestanden als eerste aanpakt. Dat zal in de praktijk vrijwel altijd anders uitpakken waardoor je alsnog te laat bent.

Update; de maker van de tool verklaard zelfs dat de geteste cryptolockers voorbij de initiële witness file kwam. Niet tot zeer beperk nuttig dus en zeker niet iets wat je bij klanten wilt implementeren.

[Reactie gewijzigd door Bor op 25 juli 2024 08:50]

[DeMoN]

Als ik het goed begrijp werkt dit alleen als de cryptolocker inderdaad bovenaan de lijst begint met encrypten, op alfabetische volgorde dus. Wat als de cryptolocker onderaan begint, of zelfs willekeurig? Of snap ik iets niet?

Overigens zeg ik niet dat het geen nut heeft, bescherming tegen cryptolockers bestaat uit meerdere maatregelen en alle kleine beetjes bij elkaar maakt het dat een netwerk op een acceptabel niveau komt wat betreft cryptolockerbestendigheid.

[Bor]

Dat snap je inderdaad goed. Dit soort oplossingen werkt alleen wanneer je kunt voorspellen waar de cryptolockers begint, en met welk bestand. In de praktijk weet je dat echter niet. Op een fileserver met een grote bestandsstructuur is het al helemaal ondoenlijk om dit op voorhand te vooorspellen met enige betrouwbaarheid.

Update; ik heb het net even getest. Een dergelijke 'oplossing' maak je met een paar regels Powershell. Praktisch gezien werkt het met een grote dataset inderdaad niet goed. Er is al veel verloren voor de server zijn diensten staakt. Het weggooien of aanpassen van een trigger bestand is voldoende voor een denial of service zoals eerder gemeld.

[Reactie gewijzigd door Bor op 25 juli 2024 08:50]

[henk717]

Dan ben ik erg benieuwd hoe je dit hebt getest Bor. Ik heb namelijk met 6 verschillende crypto families getest en de lok files zijn dan ook op elke mogelijke sorteringen geplaatst. In mijn praktijk tests is tot nu toe 100% detectie behaald zonder grote loss.

De DoS heb je gelijk in dit is de voornamenlijkste reden dat we dit maar bij een select aantal bedrijven hebben toegepast. Deze bedrijven hadden veel te maken met crypto infecties en de medewerkers zijn ingelicht en herkennen het bestand. Onze variant mailt direct zodat wij snel ter plaatsen zijn. De server herstellen bij fals alarm is zo gebeurd. Een volledige share restoren kost een aantal uur waarin een bedrijf plat licht. Je kunt zo je overwegingen maken wat je het liefste hebt. Voor deze klant was dat het risico dat iemand het bestand weg gooit.

Wil je een effectieve test doen zal je een mix bestanden moeten hebben in de root van de shared drives beginnend met elke sortering. Cryptovirussen slaan bestanden soms over die niet echt lijken. Het is dan ook nodig dat je echte files gebruikt en geen enkele regel text in .txt .

[henk717]

Met deze scenario's hebben wij rekening gehouden met de implementatie. De lok files staan op verschillende niveau's met elke mogelijke sortering. Daarvoor heb ik dan ook alle crypto families grondig bestudeerd. In de pratijk gaan de meeste op alfabetische volgorde al maken sommige hier geen onderscheid van bestanden en mappen.

Onze lok files zijn :
- Diverse extenties met echte inhoud gemacht aan de extentie
- Beginnend met A
- Beginnend met Z
- Beginnend met een cijfer
- Beginnend met een speciaal teken
- Verstopt in een diep pad
- Verstopt in de root
- Bewust niet verborgen maar wel duidelijk gemarkeerd voor de gebruiker

Tevens zijn er wat extra lok files aanwezig met afwijkende namen zodat er geen patroon herkenning kan worden gedaan. In mijn simulaties zijn op de dag van vandaag de lok files als eerste er uit gefist. Er is getest met Locky, Teslacrypt, Virlocker, willikeurige andere families te vinden op de diverse virus verzamel sites.

[narimantos]

Kan je uitleggen wat File Screening doet? En wat de nadelen hier van zijn?

[Reactie gewijzigd door narimantos op 25 juli 2024 08:50]

[CMD-Snake]

File Screening is een functionaliteit voor Windows Server gebaseerde fileservers. Je kan dan bepaalde bestandsextensies blokkeren op je fileshares. Bijvoorbeeld dat mensen geen .exe of .vbs op de netwerkshares kunnen plaatsen. Als ze dat doen wordt het geblokkeerd.

Door .locky of .zepto toe te voegen kan de malware de bestanden op de fileshares niet aanpassen, de nieuwe extensie wordt geblokkeerd.

Voor meer informatie:
https://technet.microsoft...ry/cc732074(v=ws.11).aspx
https://redmondmag.com/ar...ns-in-windows-server.aspx

[Bor]

Ook dit soort maatregelen zijn maar in beperkte mate effectief. Moderne cryptolockers gebruiken random extenties die systeemafhankelijk zijn of passen de extensie helemaal niet meer aan (padden bv een paar bytes ter identificatie). In dergelijke gevallen helpt een filescreen op basis van bestandsextenties niet.

[Verwijderd]

AppLocker oké, ik weet dat daar ook een manier is om omheen te komen (vergeef me dat ik even niet link gezien ik dat zo even niet paraat heb op m'n foon in bed), maar ik heb het laatste jaar dat al letterlijk honderden uitbraken zien voorkomen.

[ro8in]

Niet om het een of ander hoor, maar al eens gedacht aan gewoon een goede backup oplossing? Worst case scenario zijn je bestanden van de dag weg..

[Reactie gewijzigd door ro8in op 25 juli 2024 08:50]

[FREAKJAM]

Waar geef ik aan in mijn tekst dat je geen gebruik moet maken van een backup? Backup's inrichten doet een systeembeheerder by default (aanname). FSRM hanteert niet iedereen.

Als je backup's midden in de nacht draaien en een ransomware doet zich midden op de (volgende) dag voor op je netwerk, ben je toch echt wel data kwijt, een gaat een backup je niet 100% volledig redden.

[ro8in]

Dan worst case ben je data van de dag ervoor ook kwijt. Maar nog steeds geen drama.

[Bas1234567]

Dan ben je dus symptonen aan het oplossen ipv het probleem in eerste instantie te voorkomen. Backups zijn inderdaad een must, maar ik zie geen reden waarom je het niet zou proberen te voorkomen.

Bovendien, er zijn genoeg bedrijven waar een dag aan data wel degelijk een drama kan zijn.

[bbc]

Je hebt offline backups nodig om goed te doen en/of snapshots. Het probleem met het laten infecteren van een hele fileserver is dat je aardig wat tijd bezig bent met het restoren. Bovendien kan je pas beginnen restoren als je infectie verdwenen is.

Als je een infectie oploopt is er iets mis met je security of loop je tegen een 0-day exploit aan. Het crypten van die bestanden is dus niet het grootste probleem, tenzij je geen backup hebt natuurlijk.

[dakathefox]

Maar in dat geval moet je alsnog de backup terugzetten. Je kunt ook overstappen naar een OS wat minder kwetsbaar is voor cryptolocks.

[ro8in]

Dat ben ik sowieso met je eens. Echter is natuurlijk in theorie elk OS kwetsbaar en zullen de jongens van de theorie er wel weer wat voor te zeggen hebben.

Roep al jaren dat security vanuit praktijk vorm gevoerd zou moeten worden. Merk je dat een bepaald OS of software veel vaker doelwit is dan zou je zeggen dat het uitwisselen van dit OS of software praktisch gezien je systeem een stuk veiliger zouden maken. Maar dan heb je altijd de theorie jongens die dan roepen ja security through obsecurity etc.. Ja vast maar de praktijk laat toch echt wat anders zien en is dat niet wat uiteindelijk telt?

[NLWildcard]

Thx voor de tip!

[JFTE]

FSRM kost wel resources van de server. Hebben 3 keer infectie gehad. Elke keer doordat een gebruiker een attachement opende. Nu op de mailserver ingesteld dat uitvoerbare bestanden uit de mail worden verwijderd.
1e keer alleen lokale werkplek omdat de versie niet met DFS shares overweg kon.
2e keer beperkt tot eigen homedirectory van gebruiker.
3e keer deel van data van gedeelde mappen. Toen dfs offline en bron opgespoord. Daarna back-up terug van de middag. gelukkig maar 2 uur werk weg.

Uitgebreid op intranet uit de doeken gedaan. Daarna veelvuldig vragen van gebruikers of iets wel vertrouwd is. Heeft dus goed geholpen.

[Reactie gewijzigd door JFTE op 25 juli 2024 08:50]

[Bor]

Ook met deze oplossing introduceer je een erg makkelijk exlploiteerbaar denial of service mogelijkheid. Simpelweg veel changes genereren (wat ook legitiem kan gebeuren) is al voldoende om de services uit de lucht te halen. Je probeert je te wapenen tegen een kwetsbaarheid door de introductie van een andere?

[duderuud]

Bedrijven die RES WSM gebruiken kunnen Appguard aanzetten. Daarmee moet je executables whitelisten, in het begin even werk maar daarna in principe 0% kans op infectie.

[Bor]

Tot op zekere hoogte helpt dat inderdaad maar een 100% failsafe is het zeker niet. De applicaties die je in Res Workspace Manager whitelist mogen alles binnen hun omgeving. Pas als de applicatie een andere applicatie start kan er weer geblokkeerd worden. Een meer fijnmazige controle is er niet. Zo kan een vba script binnen bijvoorbeeld Word gewoon zijn gang gaan. Ook exploits worden niet of niet altijd gestopt. Dat risico is ook nog eens afhankelijk van de shell die je gebruikt binnen de Workspace. Ik heb al meerdere besmettingen met ransomware meegemaakt bij bedrijven die Res WM gebruiken helaas.

[lagefrequentie]

Kijk ook echt uit met het delen van je nas schijven of het laten zien / auto connect naar je nas schijven.
Deze worden ook "hostage" gehouden.

[powerboat]

Ik appguard van RES draaien zodat alleen geauthoriseerde processen gestart mogen worden.

[tsjaar]

Wij gebruiken nu een poosje FSRM icm auditing. Past iemand veel bestanden in korte tijd aan op een file-share, dan krijgt hij een mail notificatie. Worden het er extreem veel, dan gaat de server service uit met slack notificatie naar systeembeheer (en evt user uit domein halen). Af en toe wat false positives, maar dat houdt ons scherp. En uiteraard off-line backups/toegankelijk vanaf een bepaald systeem/user. We gebruiken eventsentry (er is ook een gratis variant), duidelijke handleiding ; http://www.eventsentry.co...eventsentry-auditing.html

Lets defeat them all.

[Reactie gewijzigd door tsjaar op 25 juli 2024 08:50]