Cryptolockers i Sverige 2019

• 21 August 2019
• by: Frej Eriksson
• in: Datasäkerhet
• Tags: cryptolocker, cyberattack, ransomware, virus
• note: no comments

För några år sedan ringde det ibland kunder och hade den där speciella tonen på rösten som hintar om att något allvarligt har hänt. På den tiden förutsatte vi nästan att orsaken berodde på en cryptolocker av något slag.

Majoriteten av de kunder som drabbades kunde vi snabbt hjälpa genom att återställa data från snapshots. I resten av fallen fick vi återställa från backuper eller kanske replikerat data. Men vi hade aldrig en kund som drabbades av en dataförlust och tvingades betala lösensumman.
Nu har tiden gått och samtalen angående cryptolockers har minskat rejält. Både säkerhetsprodukterna och vi människor har anpassat oss till det hotet.

Häromdagen fick vi ändå ett nytt samtal gällande cryptolockers och denna gång var det illa, riktigt illa. Kunden i fråga hade upptäckt att ett konto var inloggat på servrarna som inte ska vara inloggat, samt att alla filer var konstiga, alltså krypterade.
I det här fallet fanns inga SAN snapshots. Replikering av virtuella maskiner då? Ja, men de servrar som var drabbade hade inte klassificerats och konfigurerats för replikering. Men det är ju lugnt, alla har ju backup? Ja visst, men olyckligtvis hade backupservern en utdelad katalog via vilken smittan spred sig. Det ledde till att backuperna var obrukbara.
Efter en hel del arbete stod vi inför faktum att enda utvägen var att betala den begärda lösensumman för att få backupservern återställd och därefter kunna återställa data från övriga servrar som drabbats.

Med anledning av den senaste upplevelsen där allt sket sig har jag sammanfattat ett par lärdomar som jag vill dela med mig av. Vissa saker är kanske självklarheter för somliga men jag hoppas att alla hittar något nytt:

• Låt inte någon server vara exponerad på internet via RDP och se verkligen till att du inte använder dåliga lösenord. I dag verkar den vanligaste attackvektorn för cryptolockers vara just brute force attacker mot kända konton via RDP.
• Om du har möjlighet inaktivera SMB1 protokollet och inventera dina utdelade mappar. Behöver du verkligen ha det där restore$ sharet på backup-servern tillgängligt hela tiden?
• Överväg om din backupserver verkligen ska vara medlem i ditt AD. Detta för att undvika att ett kompromissat konto kan manipulera din backupserver. Det finns andra goda effekter av detta också som att din backupserver kanske är lite gladare även om hela ditt AD är nere.
• Utnyttja snapshotteknik om du har det i ditt lagringssystem, detta är en oerhört effektiv metod för att snabbt kunna återställa stora datamängder. För hur snabbt går det egentligen för dig att återställa 10 servrar från backup? Har du inte tillgång till snapshotteknik kanske du ska byta lagringssystem?
• Om du replikerar data eller virtuella maskiner mellan flera datacenter så fundera igenom vilka maskiner som omfattas av detta. Normalt sett väljer man kanske bara det som verkligen är affärskritiskt eftersom en sekundär site driver kostnader utan att generera någon direkt nytta. En stor fördel med replikerade virtuella maskiner är att dess kopior är avstängda och bortkopplade från nätverket. Vilket är ett av de bästa skydden mot smittor. Så även om du inte anpassar din sekundära site för att kunna köra alla system bör du överväga att kunna lagra en kopia av allt data.