De nachtmerrie van iedere ICTer – Full Disk Cryptolocker

Je wekker gaat veel te vroeg maar toch sleep je jezelf het bed uit. Een volle agenda vandaag dus chop chop aan de slag. Alles gaat lekker. De kinderen werken prima mee, het ontbijt staat ook al klaar en de vaatwasser staat niet zo vol. Even eten en dan op naar het werk. Je geeft je familie een kus en zegt “tot vanavond” niet wetende dat je ze vanavond niet meer zal zien. Je stapt de auto in en dan komt dat ene telefoontje. Help! Er is Trouble in paradise en je hoort ze zeggen “in beeld staat “to decrypt contact”… En nu herinner je jezelf het moment dat je je ogen open deed en je niets liever zou doen dan terug in bed kruipen. Dit kan niet goed zijn. Je trapt het gaspedaal in en rijdt “full throttle” naar de klant. De dag is begonnen…and it’s gonna be a long day.

Hierboven schets ik mijn ochtend op de dag dat de klant getroffen is door een cryptolocker. Deze post beschrijft de infectie, inspectie en nasleep van deze ransomware. Dit kan iedereen gebeuren en is dus helemaal geen fictie. Hopelijk haal je een aantal handvaten uit deze post waarmee je zelf verder komt in een soortgelijke situatie.

Dag 1 – Reddingszwemmen

Aangekomen bij de klant is dit de eerste foto die ik maak:

Niet leuk. Ok… een ransomware infectie dus. Maar dit is een cliënt, misschien zelfs wel de bron? Wellicht dat de schade op de server wel meevalt. Maar bij de server aangekomen blijkt de schade identiek te zijn. Een snelle inventarisatie telt 5 cliënts alsmede de server. Alle overige cliënts lijken normaal te functioneren.
En hoe nu verder? Allereerst zijn er 1000 vragen. Wat is de bron? Wie heeft het geïnfecteerd? Wanneer is de infectie begonnen? Kunnen we de schade herstellen? Etc. De angst die de boventoon voert is de angst dat de bron nog aanwezig is en dat deze het netwerk opnieuw besmet of zelfs overslaat naar andere delen van het netwerk. Er zijn dus een aantal zaken die je eerst moet gaan doen.

1. Op het moment dat je überhaupt het vermoeden hebt dat er ransomware actief is moet je ervoor zorgen dat je het netwerk in quarantaine zet. Zorg ervoor dat de ransomware NIET kan overslaan op andere segmenten van je netwerk. Trek de internetkabel eruit, disable een poort op de switch of haal desnoods de stroom van de switch of de router.

2. Nu ga je zorgen dat de ransomware zich ook niet binnen het netwerk kan verspreiden. Haal alle netwerkkabels uit de PC’s! Ik heb ervoor gekozen om de PC’s aan te laten staan zodat vreemde activiteit op een individueel werkstation meteen waargenomen zou worden.

3. Zorg dat je van de versleutelde PC’s een memory dump maakt en opslaat voor later forensisch onderzoek. Doe dit voor je de PC’s uitschakelt of zelfs herstart. De kans is groot vitale informatie terug te vinden in het actieve RAM geheugen.

4. Begin ondertussen met het herstellen van data uit back-ups. Een goede back-up is het ENIGE en BESTE redmiddel welke overblijft in een soortgelijke situatie. Het herstellen van data duurt meestal een lange tijd, dus begin hier meteen aan.

5. Kijk op de ransomware website van de politie (No More Ransom) om te kijken of de ransomware bekend is en of er wellicht een decryptiesleutel beschikbaar is. In ons geval is deze helaas niet aanwezig.

Ok, dat was de eerste damage control. We hebben ervoor gekozen om alle geïnfecteerde systemen los te koppelen en te verzamelen. Voor de beschadigde cliënts besloten we nieuwe cliënts te plaatsen. De server however was een volledig ander verhaal. Dit was een groot probleem. Bij deze klant zijn +/- 60 werknemers werkzaam en bestaat ook nog over een aantal satelliet vestigingen welke remote werkte op deze omgeving. De business op dit moment staat zo goed als stil.

Een klein pluspunt is dat de server op de vervanglijst stond voor volgend jaar. De server was al afgeschreven en er was dus budget vrij gemaakt om deze te vervangen. Gaan we dat meteen doen? Laten we eerst kijken wat er nog te redden is van de oude server. Via Hirens – WinXP Mini – DiskGenius merken we dat we flarden van plain data zien. De hele disk is dus niet crypted.

Omdat de data zo random is kunnen we deze in de huidige staat niet herstellen. We missen o.a. de directorystructuur en dus vermoeden we dat de MFT (Master File Table) defect is. Omdat de volledige disk versleuteld is en we ook niet in Windows komen kunnen we eveneens aannemen dat de MBR (Master Boot Record) overschreven is door de cryptolocker. Niet zo mooi!

Gelukkig zien we dat de backups van afgelopen nacht geen sporen van encryptie hebben en we feitelijk beschikken over een goede up-to-date dataset van de klant. Met als enige uitzondering een aantal bestanden die wat minder belangrijk zijn. Omdat ik deze toch graag terug heb (en uit pure interesse) besluit ik toch een mailtje te sturen naar STAR100@scriptmail.com. Helaas krijg ik hierop de volgende reactie:

Darn… de provider heeft dit e-mailadres al offline geplaatst. Daarmee vervalt mijn laatste strohalm op een snelle recovery.

Had ik betaald als ik wel contact gekregen had? Goede vraag! Deze vraag had ik uiteraard weggelegd bij het management met het advies om niet te betalen. De data die verloren is gegaan waren geen persoonsgegevens en was overigens ook zeer weinig. Als we het wel over persoonsgegevens hadden gehad die verloren gegaan waren dan was mijn advies toch anders geweest. Betalen aan dieven is hetzelfde als het in stand houden van deze malafide praktijken. Het verliezen van mijn belangrijkste business dat echter vanuit het oogpunt van het bedrijf nog erger. Dit weten uiteraard de makers van ransomware maar al te goed. Dat is ook de reden dat de providers websites en e-mailadressen zo snel mogelijk uit de lucht halen. Zo worden de criminele activiteiten alsnog gestopt. Dit zorgt wel voor een ander vraagstuk. Op deze manier blijven bedrijven gedupeerd achter zonder de mogelijkheid op herstel van data. Vergelijk dit eens met een bankrover welke mensen in gijzeling neemt en justitie besluit om niet te onderhandelen met deze persoon. Als gevolg schiet de bankrover 4 mensen dood en wordt daarna zelf doodgeschoten. Hooray… we onderhandelen niet met bankrovers en dus heeft de misdaad hier niet gezegevierd. Helaas kosten dit aan 4 mensen het leven. Een moeilijke discussie voor een andere keer…

Op dit moment is er geen andere keuze. Snel een server invliegen en beginnen aan een volledige migratie / herstel.

Dag 2 – Wederopbouw

Vandaag is de data uit de backup weer aanwezig en starten we de installatie van een nieuwe server. Het nadeel is dat we wel software en installatiesleutels verloren zijn gegaan en dus wordt het ook een beldagje. Daarnaast hebben we op het eerste gezicht geen rare activiteiten gezien op de “normaal werkende” PC’s en dus wordt het tijd om ze te gaan scannen. We kiezen voor MalwareBytes en HitmanPro. Een hele klus voor zoveel PC’s maar absoluut nodig alvorens ik de netwerkkabels terug aan durf te sluiten. Na afloop geen interessante malware op de PC’s gevonden en dus kunnen we ook aan de slag met werkende PC’s. Zo langzamerhand bouwen we de infra weer terug en gaan de systemen weer werken.

We weten dat de encryptie ’s nachts gedraaid heeft en dat een aantal systemen die nacht aangestaan hebben. Al deze systemen zijn versleuteld behalve eentje. Dat is interessant. Als we deze PC’s beter bekijken zien we al snel de eerste sporen. Namelijk:

Deze bestanden bevinden zich in “C:\Program Files\dcrypt” en dateren exact van moment van infectie. Daarnaast vinden we DCrypt terug in het configuratiescherm. Interesting!

Wat Googelen leert ons dat Mamba gebruik maakt van DCrypt ofwel HDDCryptor en dat het hier waarschijnlijk de “januari” variant van Mamba betreft. Het vreemde is dat niet alle karakteristieken exact overeenkomen. Wachtwoorden die we achterhalen zoals “WinterSnow2086”, “12345”, “-p” en “0000” werkte niet. Mamba ziet er als volgt uit:

Er zijn dus wel wat overeenkomsten zoals het gebruik van DCrypt voor de infectie en de melding om via e-mail contact op te nemen. Er zijn ook verschillen zoals:

• Ander e-mailadres
• Andere melding (tekstueel)
• Wij hebben geen unieke ID ontvangen (wat zou betekeken dat het een gerichte aanval is OF dat deze ransomware slechts 1 statisch wachtwoord heeft)

Aangezien de data van de klant “ongeautoriseerd aangeraakt” is moeten we dit voorval ook melden bij de “Autoriteit Persoonsgegevens”. Dus ook dit in orde gemaakt op dag 2. Hierin vermeld dat we in eerste instantie niet de klanten op de hoogte stellen omdat het “lekken van data” geen karakteristiek is van de Mamba ransomware.

Tenslotte de huidige firewall eens flink nagekeken en aangescherpt waar mogelijk.

Dag 3 – Online

Na 2 hele lange dagen zijn we weer een stuk verder. De primaire systemen draaien weer en de werkzaamheden kunnen hervat worden. De derde dag wordt gebruikt om de puntjes op de (spreekwoordelijke) i te zetten. Ook worden de satelliet vestigingen weer gescand en aangesloten. Na de derde dag is 95% operationeel en wordt er een vierde dag ingepland voor de laatste puntjes en persoonlijke gebruikersinstellingen.

Wat weten we op dit moment?

• DCrypt is waarschijnlijk gebruikt voor het versleutelen van de hard disks. DCrypt is een legitieme applicatie voor full-disk encryptie.
• Encryptie is niet volledig succesvol omdat we met recover tools leesbare (plain tekst) data terugvinden.
• MBR en MFT zijn beschadigd / overschreven of verplaatst
• De waarschijnlijkste bron is een Windows XP pc welke gebruikt werd bij de prikklok. Deze had al lang vervangen moeten zijn maar dat was niet gebeurt. Aangezien dit systeem ook aan stond is dit een logische bron voor infectie. Windows XP is natuurlijk zo lek als een mandje.
• Uit gegevens van het alarmsysteem blijk dat er niemand ’s nachts in het pand is geweest.
• Het vermoeden bestaat dat iemand vanuit intern medeplichtig is. Dit is puur een vermoeden gebaseerd op ontevredenheid van deze medewerker (disgruntled employee) en op bepaalde vragen en opmerkingen die deze persoon geplaatst heeft in de dagen na infectie.

De dagen erna – aftermath

Een week na het maken van de melding ontvangen we een brief retour van de autoriteit persoonsgegevens wat op zich opmerkelijk is. De meldingen die we eerder bij de autoriteit gedaan hebben bleven altijd onbeantwoord. In de brief staat feitelijk dat we alle klanten op de hoogte moeten stellen als we niet met 100% zekerheid kunnen bewijzen (d.m.v. logs o.i.d.) dat er geen data naar buiten gelekt is. En dat is in dit geval lastig…

Een korte inspectie op de firewall bevestigd het vermoeden dat de logging mogelijkheden beperkt zijn en sowieso uit staan. Geen logs uit de firewall dus. De managed anti-virus geeft ons ook geen sluitende log bestanden. Er zijn dus nog maar een paar mogelijkheden om te bewijzen dat er geen data naar buiten gelekt is:

• De encryptie kunnen kraken (of eromheen werken) om de VHD van de server te bemachtigen. Wellicht is de virtuele server waar de data op stond niet geraakt door de ransomware.
• Een sample van de malware achterhalen en deze reverse-engineeren om er zeker van te zijn dat deze geen functie heeft om data naar buiten te sturen.

Een sample achterhalen gaat het beste vanaf de bron PC (waar de ellende begonnen is). Echter is deze ook versleuteld en dus is het beste om de encryptie te kraken of er omheen te werken.

Talk Forensics

Laten we eerst eens wat beter kijken naar de infectie. Is het wel Mamba? Naar wat zoeken komen we onze vermelding nog 1x tegen op het internet, namelijk op http://www.forospyware.com/t533539.html. Zie hieronder de screenshot:

Deze pagina biedt echter geen verdere informatie. Maar er blijken meer overeenkomsten te vinden zoals de Samanta@scryptmail.com malware en de ZAX1001@scryptmail.com infectie.

Een mogelijke oplossing is de RakhniDecryptor tool van Kasperski. Echter snapt deze helemaal niks meer van de schijfindeling en is op dit moment useless.

Grappig is dat de ZAX1001 variant wel erg lijkt op onze variant. Zelfs de schrijfwijze is identiek. De kleine t in het woord “to” en de hoofdletters van de naam voor @scryptmail.com evenals de hoofdletters van “ENTER PASSWORD”.

Als we even uitgaan van een soortgelijke werking als ZAX1001 dan gaat de ransomware als volgt te werk:

• Maakt gebruik van AES128 en RSA2048 cipher algoritmes (sterke versleuteling)
• Versleuteld MBR
• Decryptiesleutel wordt na betaling niet toegestuurd (wat raar is aangezien ze hiermee hun “business” niet helpen. Met dit medeweten betaald niemand meer)
• Wordt meestal overgebracht via e-mail, malafide websites of andere datadragers zoals USB sticks

Op dit moment is het goed om te eventlogs te analyseren van de PC welke aan stond gedurende de aanval en waar we de DCrypt bestanden op gevonden hebben. De logbestanden onthullen bij inspectie interessante informatie. De infectie is begonnen om 03:10 vanaf een andere PC dan we aanvankelijk verwacht hadden, namelijk een Windows 7 cliënt welke ook versleuteld is. Hiervoor is een administrator account misbruikt. Deze cliënt stond in een afgesloten ruimte en werd alleen voor een specifieke toepassing gebruikt waarbij geen menselijke interactie nodig was (namelijk barcode scanning).

Na diepere analyse blijkt dat de bron pc een open poort had naar buiten. Dit was een alternatieve RDP poort, namelijk 3395 (v.a. buiten) welke geNAT was naar poort 3389. Deze PC bleek gebruikt te zijn door een oud werknemer om vroeger vanuit huis te werken.

Windows updates worden gedownload van de WSUS server en dus geeft de WSUS server ons inzicht in de update status van dit station. En het station is helaas niet up-to-date. De laatste 6 maanden zijn de updates niet meer binnen gehaald. Waarom is momenteel niet duidelijk.

Hoewel de toedracht nog steeds divers kan zijn en de huidige bevindingen geen enkel uitsluitsel geven is dit voor mij op dit moment het meest voor de hand liggende scenario:

Door het missen van recente patches en updates is deze Windows7 machine vatbaar voor een RDP exploit. Bijvoorbeeld de “EsteemAudit” exploit welke aan het licht gekomen is door de uitgelekte NSA Files. Door het misbruiken van deze Exploit heeft de hacker toegang kunnen krijgen tot het systeem waar deze vervolgens een credential scan uitgevoerd heeft en het administrator account achterhaald heeft. Vervolgens heeft deze de ransomware geactiveerd en erop uitgestuurd om het netwerk te infecteren. Of dit alles automatisch of manueel gedaan is daar is nog niets over te zeggen maar dit zou zomaar een volledig (en ouder) automatisch script geweest kunnen zijn. Dit vermoeden wordt versterkt door de zeldzaamheid en feit dat het e-mailadres momenteel niet meer bestaat.

Hoewel de ransomware veel weg heeft van de Mamba Cryptolocker lijkt de ransomware een soort “oudere” variant te zijn. Mamba zit namelijk een stuk geavanceerder in elkaar dan deze cryptolocker. Hier ontbreken de BitCoin betaallinks, het ID waarmee de hacker je PC kan identificeren en Mamba gebruikt slechts een aantal bestanden uit de DCrypt toolset terwijl deze exploit de volledige software installeert. Daarnaast kan ik op de geïnfecteerde maar niet versleutelde PC geen credential scan of restanten daarvan vinden.

Naar alle waarschijnlijkheid is de ransomware als volgt te werk gegaan:

• Volledige DCrypt suite geïnstalleerd
  
• Herstelpunten verwijderd
• MFT verwijderen
• Opschonen
• DCrypt draaien in het Explorer.exe proces en versleutelen van bestanden
  
• Bootloader in de MBR geïnstalleerd
• Rebooten

Een andere opvallende gebeurtenis is dat elke ingevoerde wachtwoord resulteert in de tekst “Wrong Password” dat een simpele door boot en er vervolgens een Windows Herstel scherm verschijnt waarmee je helemaal niks kunt omdat de partitie helemaal niet herkent wordt en essentiële Windows bestanden versleuteld zijn. Toch opmerkelijk dat een herstelvenster wel getoond wordt.

Ook nadat reparatie van de bootsector wordt uitgevoerd middels de Windows herstel sectie op de installatie cd boot het systeem door zonder melding van de cryptolocker maar nog steeds met bovenstaande en nutteloze herstelscherm. Met de volgende commando kan de bootconfiguratie opnieuw opgebouwd worden.

• bootrec /fixmbr (schrijf een Windows MBR naar de systeempartitie, bestaande partitietabel wordt overschreven)
• bootrec /fixboot (schrijf opstartsector naar systeempartitie om Windows te starten)
• bootrec /ruibuildbcd (Bouw de BCD (Boot Configuration Data) opslag opnieuw op)

Omdat de partitie niet leesbaar is kan de herstelprocedure geen enkele geinstalleerde Windows installatie terugvinden waardoor ook de BCD niet opnieuw opgebouwd kan worden. Dit levert zelfs een extra probleem op. Stel dat je op een later moment de decryptiesleutel terug vindt. Waar ga je die dan invoeren om het systeem te ontsleutelen.

Verder onderzoek van de DCrypt applicatie hashes wijst uit dat de legitieme versie van de DCrypt website is gebruikt. En met deze versie is een encryptieproces starten met een blanco wachtwoord onmogelijk.

Mijn vermoeden is dat de ENTER misschien een bug is in de bootloader waardoor de bootloader doorstart maar er geen ontsleuteling plaatsvindt van de data. Om het decryptie proces te starten zullen we toch over de sleutels moeten beschikken.

Verder kijkend naar DCrypt moet het programma voor het uitvoeren van zijn encryptieslag een commando hebben ontvangen met het gebruikte wachtwoord. Als we dit commando terug kunnen vinden kunnen we het wachtwoord achterhalen en kunnen decrypten. Dit commando kan in een scriptbestand hebben gestaan welke door deze ransomware gebruikt is. Laten we hopen dat deze nog opgeschoond is. Het commando zal de volgende vorm hebben gehad:

dccon –decrypt C: -p yourencryptionpassword

Verder info die we vinden over deze DiskCryptor open-source tool (diskcryptor.net) zijn o.a. dat het een kleine en snelle applicatie is welke meerdere partities snel en tegelijkertijd kan versleutelen alsmede externe schijven en netwerkpartities welke een NTFS, FAT12,16 en 32 en exFAT bestandssysteem hebben. DiskCryptor is ontwikkeld door een voormalig TrueCrypt gebruiker welke een alternatief wilde maken voor de commeciele disk encryptie applicaties. DiskCryptor maakt gebruik van AES-256, Twofish, Serpent of een combinatie van cascaded algoritmes in XTS-modus voor het uitvoeren van de versleuteling. Right… dat hebben we gemerkt.

De volgende stap is het maken van forensische disk images als eventueel bewijslast en zeker om verder onderzoek op te plegen. Na het maken van de kopieën gaan we de images doorzoeken op bepaalde steekwoorden zoals “STAR100”, “DCrypt”, “decrypt” en “Scryptmail”.

Als eerste onderzoeken we de bron PC. Autopsy is de tool die ik hiervoor gebruik. Het grappige is dat Autopsy verdacht veel bestanden alsmede de directorystructuur kan terugvinden.

Helaas is dit de laatste doorbraak in het proces. Alle images zijn geanalyseerd en volledig doorzocht op belangrijke zoekwoorden. Helaas heeft dit niet het gewenste resultaat opgeleverd. Er zijn voldoende sporen maar geen van alle leiden tot het herleiden van het encryptie wachtwoord of tot het verkrijgen van andere sporen.

De volgende stap is het downloaden van alle DLL en EXE bestanden. Deze gecontroleerd op integriteit en door diverse virusscanners laten scannen om de malware strain te achterhalen. Ook dit leverde niet het gewenste resultaat op.

Unallocated space en overige data op sectorniveau doorzocht en geanalyseerd. Geen van allen geven een goede indicatie om door te zoeken. Misschien naar nog 4 dagen zoeken dat er een valide spoor achterhaald kan worden maar het lijkt er niet op dat deze ransomware verder geanalyseerd kan worden. Het is heel vreemd want er is plain data te vinden op een versleutelde HD. Daarnaast is de Dcrypt bootloader te skippen met een ENTER terwijl DiskCryptor geen “ENTER” als wachtwoord accepteert. Zo zijn er nog meer vreemde zaken die doen vermoeden dat de ransomware maar half succesvol uitgevoerd is en dat de encryptie niet volledig succesvol was.

Doordat deze variant waarschijnlijk meerdere keren de computer gereboot heeft is er in het geheugen ook geen aanwijzing meer te vinden.

Op dit moment besluiten we verder onderzoek te staken en roeien met de riemen die we hebben. Dat betekend een flinke kostenpost en reputatieschade. Denk aan de investering van diverse nieuwe systemen, forensisch onderzoek, dagen lang geen productie kunnen draaien, juridische bijstand, damage control etc.

Overweeg zeker als bedrijf om jezelf te verzekeren tegen cybercrime!

Wel is de verloren data teruggehaald en dat is op zich al een pluspunt.

Helaas is er dus niet altijd een uitslag die genoegdoening geeft. Ransomware is gevaarlijk en de nachtmerrie van iedere ICTer. Kijk uit, en mocht het gebeuren volg dan zeker de tips aan het begin van deze post toe. Binnenkort een post met meer informatie over “incident response”.