Voorbereiden op herstel van ransomware

[fRiEtJeSaTe]

Ik werk voor een MKB-bedrijf met ongeveer 150 Windows devices, 2 man part-time op de IT-afdeling.
Nu vroeg ik mezelf af hoe (snel) wij recoveren van een ransomware-aanval, zoals die zo vaak in de media te vinden is de laatste tijd.

We maken offline-backups van data en servers; air-gapped, redelijk veilig denk ik. Het gros van de servers draait virtueel in een cluster en is redelijk snel te herstellen.

Maar wat heb ik aan draaiende servers als alle clients naar een bitcoin-scherm (Petya) zitten te kijken? Juist hier zit voor ons het probleem. We hebben veel mensen in de buitendienst, die ik graag een mogelijkheid zou willen geven om op dat moment van afstand te kunnen herstellen, naar in ieder geval een soort basisniveau. Met MDT dwing ik iedereen per direct naar kantoor, geen wenselijke situatie.

Ik begrijp dat Windows Autopilot mogelijk geschikt is, maar betekent dit een complete revisie van (Dell) hardware? (vergelijkbaar aan Apple MDM, bestaande toestellen kunnen niet worden toegevoegd?). Of kan ik ook bestaande hardware herstellen? Ransomware versleutelt alles, dus het apparaat zal toch een soort pre-boot omgeving moeten hebben? Of de pragmatische / low-tech oplossing; Autopilot i.c.m. een usb-stick die we aan alle buitendienst collega's verstrekken?

Wie kent het probleem en heeft mogelijk een oplossing?

[pagani]

Air gappen is leuk, maar praktisch alle moderne ransomware bereidt zich daarop voor

[F_J_K]

pagani schreef op maandag 17 augustus 2020 @ 15:10:
Air gappen is leuk, maar praktisch alle moderne ransomware bereidt zich daarop voor

Paar weken versleutelen en dan pas jezelf kenbaar maken ken ik, maar hoe kan de ransomware het 'achter' de gap testen van de backups omzeilen?

fRiEtJeSaTe schreef op maandag 17 augustus 2020 @ 15:00:
Wie kent het probleem en heeft mogelijk een oplossing?

Overstappen op puur SaaS werken. Prima om een 'cache' te hebben op laptops, maar die wordt niet gebackupt. Als laptop overgenomen: leg aan de kant en gebruik een ander endpoint puur webbased tot de laptop op kantoor is leeggegooid. Via Citrix of whatever waar een client-applicatie onontbeerlijk is. Jammer voor de powerusers die graag met eigen tools werken maar een noodgeval is een noodgeval.

[ Voor 46% gewijzigd door F_J_K op 17-08-2020 15:18 ]

[fRiEtJeSaTe]

pagani schreef op maandag 17 augustus 2020 @ 15:10:
Air gappen is leuk, maar praktisch alle moderne ransomware bereidt zich daarop voor

Als er weken lang ge-encrypte data wordt gebackupt idd. Maar dan werd die data ook weinig gewijzigd anders was het wel opgevallen. En ik snap dat herstel uiterst voorzichtig moet gebeuren zodat verborgen ransomware niet weer los gaat. Maar zover ik weet zijn offline backups nog steeds de enige manier waarop je data echt veilig kunt stellen?

F_J_K schreef op maandag 17 augustus 2020 @ 15:14:
Overstappen op puur SaaS werken. Prima om een 'cache' te hebben op laptops, maar die wordt niet gebackupt. Als laptop overgenomen: leg aan de kant en gebruik een ander endpoint puur webbased tot de laptop op kantoor is leeggegooid. Via Citrix of whatever waar een client-applicatie onontbeerlijk is. Jammer voor de powerusers die graag met eigen tools werken maar een noodgeval is een noodgeval.

Het gros van de users werkt met powertools zoals Revit. Deze in de cloud draaien is onderzocht maar geen optie i.v.m. mouse-lag en bestandsgrootte waarmee wordt gewerkt (1GB). Beleid is geen data opslaan op de laptop. Het 'cache' is dan ook voor eigen risico. Gaat er puur om dat de laptop z.s.m. weer in business is met zo min mogelijk handelingen voor IT (die het op dat moment het al druk genoeg heeft).

[ Voor 33% gewijzigd door fRiEtJeSaTe op 17-08-2020 15:31 ]

[PD2JK]

Is on-premise RDS / Citrix met nVidia Tesla's een optie?
Meestal zijn modellen niet zo spannend qua 3D, alleen renderen kan best CPU intensief zijn. Maar ik weet niet hoevaak dat bij jullie voorkomt.
Dubbele AMD Epyc 64-core in een server?

[Gomez12]

fRiEtJeSaTe schreef op maandag 17 augustus 2020 @ 15:00:
We maken offline-backups van data en servers; air-gapped, redelijk veilig denk ik. Het gros van de servers draait virtueel in een cluster en is redelijk snel te herstellen.

Je bent ermee bekend dat huidige ransomware rustig maanden in je software zit voordat je er iets van ziet, oftewel heb je ook air-gapped backups van maanden terug en heb je dan nog wel iets aan die data?

Of hoe zie je een herstel-procedure voor je? Gister restoren, dan na x uur erachter komen dat dat niet de goede is, dan maar die van eergister? Of vorige week?

Maar wat heb ik aan draaiende servers als alle clients naar een bitcoin-scherm (Petya) zitten te kijken? Juist hier zit voor ons het probleem. We hebben veel mensen in de buitendienst, die ik graag een mogelijkheid zou willen geven om op dat moment van afstand te kunnen herstellen, naar in ieder geval een soort basisniveau. Met MDT dwing ik iedereen per direct naar kantoor, geen wenselijke situatie.

Enige wenselijke situatie is iedereen naar kantoor... Elke manier van remote terugkunnen heeft een grote kans aangetast te zijn door je ransomware waardoor je morgen weer opnieuw kan beginnen...

[F_J_K]

Gomez12 schreef op maandag 17 augustus 2020 @ 15:32:
[...]
Je bent ermee bekend dat huidige ransomware rustig maanden in je software zit voordat je er iets van ziet, oftewel heb je ook air-gapped backups van maanden terug en heb je dan nog wel iets aan die data?

Dat valt dus te mitigeren door achter de air gap de backup structureel iedere keer te testen. Verspreid @random een paar honderd bestanden van variërende grootte op evenzoveel plaatsen en een dozijn belangrijkste bestandstypes. Check iedere keer de checksums met de aan jouw kant bekende checksums. Als er een verschil zit in 1 van die files: meteen piepen. (En oudere backups dan niet meer weggooien tot er duidelijkheid is )

Of loop ik achter?

[fRiEtJeSaTe]

Misschien kan iemand wat uitleg geven hoe men dan te werk gaat?
Ransomware die ik tot dusver tegen ben gekomen hernoemt alle bestanden en zet er een txt-bestandje bij met betalingsinfo. Hij doet dit middels een geïnfecteerde executable. Tot het moment dat de executable draait zijn de bestanden onaangetast.

Ik ging ervan uit dat huidige aanvallers op eenzelfde manier werken, echter eerst een aantal weken / maanden in het netwerk rondhangen om de aanval voor te bereiden. Dan op een onbewaakt moment (vakantie) tijd nodig hebben om alles te encrypten.

Maar ik begrijp uit bovenstaand verhaal dat de bestanden al pre-encrypt zijn en de oude backups waardeloos? Hoe moet ik me dit voorstellen, zijn de bestanden wel nog te openen door gebruikers tot moment van eisen losgeld? Anders gaat het toch opvallen?

[I_IBlackI_I]

Vaak zie je dat alle bestanden al tijden ge-encrypt zijn, en gedurende runtime ontsleuteld worden. Na verloop van tijd gooit de ransomware de sleutel weg, en dan kom je er achter dat alles versleuteld is. Dus ook de bestanden in je backup.

[downtime]

I_IBlackI_I schreef op maandag 17 augustus 2020 @ 16:38:
Vaak zie je dat alle bestanden al tijden ge-encrypt zijn, en gedurende runtime ontsleuteld worden. Na verloop van tijd gooit de ransomware de sleutel weg, en dan kom je er achter dat alles versleuteld is. Dus ook de bestanden in je backup.

Dan moet het redelijk geavanceerde ransomware zijn, die on-the-fly bestanden kan decrypten die de user opent, en die software moet dan ook op alle clients draaien. Is ransomware inmiddels zo geavanceerd dat eerst alle clients besmet worden voordat de bestanden daadwerkelijk encrypted worden?

[Gomez12]

downtime schreef op maandag 17 augustus 2020 @ 16:47:
[...]

Dan moet het redelijk geavanceerde ransomware zijn, die on-the-fly bestanden kan decrypten die de user opent, en die software moet dan ook op alle clients draaien. Is ransomware inmiddels zo geavanceerd dat eerst alle clients besmet worden voordat de bestanden daadwerkelijk encrypted worden?

Niet alle clients hoeven besmet te zijn, alleen degenen die de bestanden benaderen...

En door bijv eerst gewoon een week niets te encrypten maar alleen "logische" plekken te proberen te infecteren heb je een week de tijd om de meeste clients te raken.

En tja, er is zeer geavanceerde ransomware voor als je echt uitgekozen wordt als target. Die doet gewoon niets in 1e instantie behalve infecteren en inventariseren, dan kan men remote gewoon kiezen welke daadwerkelijke ransomware wil toepassen (bijv aan de hand van een virusscanner die is geinstalleerd alleen die variant x/y/z niet kent)

En dan kom je dus ook in de vraagtekens hoe goed je air-gapped backup is, als die enkel de ransomware opmerkt maar niet het infecteren/inventariseren heb je net je backup teruggezet en de volgende dag heb je gewoon een andere ransomware variant...

[Gomez12]

F_J_K schreef op maandag 17 augustus 2020 @ 15:35:
[...]

Dat valt dus te mitigeren door achter de air gap de backup structureel iedere keer te testen. Verspreid @random een paar honderd bestanden van variërende grootte op evenzoveel plaatsen en een dozijn belangrijkste bestandstypes. Check iedere keer de checksums met de aan jouw kant bekende checksums. Als er een verschil zit in 1 van die files: meteen piepen. (En oudere backups dan niet meer weggooien tot er duidelijkheid is )

Of loop ik achter?

Technisch gezien valt er een heleboel te mitigeren, maar praktisch denk ik dat je al blij mag zijn als mensen hun backup 1x per maand volledig testen, ga je daar nog additionele testen aan toevoegen dan kan dat theoretisch wel, maar praktisch zal het bij veel bedrijven niet gebeuren.

[unezra]

fRiEtJeSaTe schreef op maandag 17 augustus 2020 @ 15:24:
[...]
Het gros van de users werkt met powertools zoals Revit. Deze in de cloud draaien is onderzocht maar geen optie i.v.m. mouse-lag en bestandsgrootte waarmee wordt gewerkt (1GB). Beleid is geen data opslaan op de laptop. Het 'cache' is dan ook voor eigen risico. Gaat er puur om dat de laptop z.s.m. weer in business is met zo min mogelijk handelingen voor IT (die het op dat moment het al druk genoeg heeft).

Daar zijn oplossingen voor. Niet goedkoop, maar ze zijn er wel.

Mits de laptops altijd de beschikking hebben over een fatsoenlijke, stabiele internet verbinding kun je zoals @PD2JK zegt praktisch alles prima via een VDI achtige constructie draaien.

Het leuke is, je zou dan zelfs kunnen overstappen op mobiele Thin Clients waar ransomware in de regel helemaal geen vat op heeft: https://www.igel.com/igel...s-and-certified-hardware/

[sh4d0wman]

Denk ook na over wat voor data je als bedrijf precies hebt. De recente varianten bieden de gestolen data te koop aan. Wat als concurrenten dit in handen krijgen? Voor het MKB zal dit over het algemeen wel meevallen maar grote internationale bedrijven doen er goed aan om sommige data maar niet te digitaliseren.

Als je ziet hoe veel budget China, USA en Rusland hebben om inlichtingen te verzamelen dan is data opkopen natuurlijk peanuts en veel makkelijker dan zelf een aanval opzetten en uitvoeren. Maar zoals gezegd, maak je hier als MKB'er niet druk om

Voor jullie het belangrijkste, stel een Disaster Recovery / Business Continuity plan op. Dan zie je al snel wat cruciale systemen/data zijn/is en wat er op welk moment weer hersteld moet zijn. Daarop gebaseerd je budget afstellen en beveiliging inrichten.

Vergeet ook niet dat als men al zo lang in je systemen zit alle credentials van alle mogelijke devices en users ook aangepast moeten worden. Dat wil ook nog wel eens een klus zijn nu er meer appliances en IoT dingen in je netwerk zitten. En uiteraard certificate hell als je pech hebt (leaked private keys.. oops).

[Heroic_Nonsense]

I_IBlackI_I schreef op maandag 17 augustus 2020 @ 16:38:
Vaak zie je dat alle bestanden al tijden ge-encrypt zijn, en gedurende runtime ontsleuteld worden. Na verloop van tijd gooit de ransomware de sleutel weg, en dan kom je er achter dat alles versleuteld is. Dus ook de bestanden in je backup.

En daarom, ook wat @F_J_K, zegt, test je de air gapped backups.

De tijdelijke sleutel is alleen aanwezig op machines die met de ransomware zijn besmet. Verplaats je data die door ransomware is geëncrypt naar een air gapped machine, dan kunnen de bestanden opeens niet geopend worden omdat de ransomware niet op de air gapped machine aanwezig is (en dus ook niet de tijdelijke sleutel).

Een check op de checksum zou ook voldoende moeten zijn (knappe ransomware die een geëncrypte versie van een bestand dezelfde checksum kan laten genereren als het origineel).

[fRiEtJeSaTe]

Heroic_Nonsense schreef op dinsdag 18 augustus 2020 @ 08:16:
[...]


En daarom, ook wat @F_J_K, zegt, test je de air gapped backups.

De tijdelijke sleutel is alleen aanwezig op machines die met de ransomware zijn besmet. Verplaats je data die door ransomware is geëncrypt naar een air gapped machine, dan kunnen de bestanden opeens niet geopend worden omdat de ransomware niet op de air gapped machine aanwezig is (en dus ook niet de tijdelijke sleutel).

Een check op de checksum zou ook voldoende moeten zijn (knappe ransomware die een geëncrypte versie van een bestand dezelfde checksum kan laten genereren als het origineel).

Ok dus voor de duidelijkheid:
- de clients die besmet zijn encrypten de bestanden (zonder de bestandsnaam aan te passen)
- deze clients zijn allen voorzien van de decryptiesleutel
- clients die niet besmet zijn kunnen op dat moment de bestanden al niet meer openen
- aanvallers hopen dat het niemand opvalt en wachten totdat backups voldoende corrupt zijn
- na dat moment gooit men de decryptiesleutel weg en presenteert de 'oplossing'

Dat betekent dus dat men alle clients besmet moet hebben om geen alarmbellen te doen rinkelen? Heeft iemand concrete voorbeelden van ransomware die zo geavanceerd is? Ik heb moeite om me voor te stellen dat er een extra laag draait die bestanden eerst decrypt, alvorens ze te openen. Neem aan dat dit niet gewoon Bitlocker is.

[ Voor 9% gewijzigd door fRiEtJeSaTe op 18-08-2020 20:32 ]

[Gomez12]

fRiEtJeSaTe schreef op dinsdag 18 augustus 2020 @ 20:31:
[...]
Ik heb moeite om me voor te stellen dat er een extra laag draait die bestanden eerst decrypt, alvorens ze te openen. Neem aan dat dit niet gewoon Bitlocker is.

Waarom heb je daar moeite mee? Windows etc bieden er gewoon api's voor aan, waar bijv virus-scanners etc gebruik normaliter gebruik van maken.
Wil je geen virus-scanner nabootsen dan heb je Virtual FS-drivers die je kan gebruiken.
Ben je bereid dieper de windows-code in te gaan, dan kent de windows-verkenner ook allerlei hooks etc waardoor je in zip-files kan browsen als directory's etc.
Daarnaast kent ntfs bijv archive-functies die je ook kan half overwriten / redirecten naar je eigen functies...

Het is niet iets wat de gemiddelde programmeur even in een middagje schrijft, maar er zijn genoeg hooks binnen windows om iets aan vast te hangen en die MS er bijna niet uit kan halen, puur vanwege hardware compatibiliteit en backwards compatibility etc.

[fRiEtJeSaTe]

Ik kan er werkelijk niets over vinden. De pakkans lijkt me ook substantieel hoger.
Heb je concrete voorbeelden van ransomware die op deze wijze te werk gaat?

[ Voor 16% gewijzigd door fRiEtJeSaTe op 18-08-2020 23:38 ]

[Brahiewahiewa]

fRiEtJeSaTe schreef op dinsdag 18 augustus 2020 @ 23:37:
Ik kan er werkelijk niets over vinden. De pakkans lijkt me ook substantieel hoger.
Heb je concrete voorbeelden van ransomware die op deze wijze te werk gaat?

https://www.bleepingcompu...av-ransomware-protection/

[Wim-Bart]

Even over backup. Je kan Air Backed backups gewoon testen. Enige wat je nodig hebt is wat oudere hardware die los staat van de rest.

Wat je doet is dat je op een oude server met voldoende ruimte, ESX hebt draaien, gratis versie is geen enkel issue.
Daar restore je een aantal VM's naar toe, een domein controller (je PDC) een database server, een fileserver (of gedeelte daar van) wat applicatie servers. Kortom een kleine representatie van je omgeving. Belangrijk is om niets te wijzigen. Je past zelfs geen IP adressen aan.

Je zorgt ervoor dat het VM Netwerk waarin de servers staan geen verbinding naar buiten heeft. Zeer belangrijk, ook omdat je je IP nummers niet moet wijzigen. Je start nu alle VM's op, alsof het gewoon je productie omgeving is.

Hierna begin je de tijd van de ESX server in stapjes van een paar dagen te verhogen, dit kan je met een script doen. Gewoon iedere 30 minuten een dag er bij. Dat laat je gewoon draaien tot de omgeving 6 maanden vooruit loopt. Hieruit kan je dan zien wat er gaat gebeuren.

Na de test gooi je alles weer weg.

[fRiEtJeSaTe]

Brahiewahiewa schreef op woensdag 19 augustus 2020 @ 02:13:
[...]
https://www.bleepingcompu...av-ransomware-protection/

Dit is nog steeds een bestand dat niet meer kan worden geopend. En niet een on-the-fly decrypter die ervoor zorgt dat de bestanden nog maanden bereikbaar blijven.

[Heroic_Nonsense]

fRiEtJeSaTe schreef op dinsdag 18 augustus 2020 @ 20:31:
[...]
Ik heb moeite om me voor te stellen dat er een extra laag draait die bestanden eerst decrypt, alvorens ze te openen.
[...]

Iets meer moeite doen om het je voor te stellen dan

Wat jij in je andere post omschrijft, is inderdaad hoe het in de begindagen van ransomware ging. Maar met die vroege versies kon je met een eenvoudige backup de boel weer restoren, waardoor het aantal betalende "klanten" gelimiteerd was tot de mensen zonder backup en kennis.

EDIT: van belang is het onderscheid tussen ransomware die zich op bedrijven richt, en zo geavanceerd werkt als hier wordt beschreven, en ransomware die zich op particulieren richt. Voor die laatste groep hoeft ransomware natuurlijk niet zo geavanceerd te zijn.

Tegenwoordig werkt ransomware dus zo transparant mogelijk tijdens de infectie- en encryptiefase. Voor infectie lijkt me dat vanzelfsprekend: je wil niet dat je malware ontdekt wordt terwijl het versleutelen nog niet is begonnen.

Voor de encryptie heeft het met de tijd te maken die het encrypten kost. Als men het encrypten in een "big bang" zou doen, dan zou de malware direct gedetecteerd worden (door AV, software die bovenmatige aantallen schrijfbewegingen rapporteert of door gebruikers die over prestaties klagen omdat drives en CPU's met andere dingen bezig zijn dan het draaien van de bedrijfsapplicaties). Bovendien heb je dan kans dat er onversleutelde backups aanwezig zijn waardoor je "klant" minder snel geneigd is om te betalen voor je "diensten".

Dus tegenwoordig werkt men dus op de manier zoals meerdere mensen hier uitleggen. Dit neemt tijd in beslag; soms maanden. Het is belangrijk dat het niet opvalt, dus de infectie moet ver genoeg verspreid zijn onder de clients zodat een medewerker met een schone client niet opeens gaat klagen dat hij geen bestanden op de server kan openen. Dat betekent dat je óf alle clients moet infecteren en voorzien van een sleutel óf de server zelf on-the-fly decryptie laten uitvoeren.

Bovendien: hoe langer je transparant ontsleutelt, hoe ouder de backups die nog onversleuteld in een kluis liggen. Geen bedrijf kan verder met een backup van 12 maanden oud.

Bij gerichte aanvallen wordt de malware zelfs actief bijgestuurd door de aanvallers (die inmiddels toegang hebben tot het netwerk en dus ook de data) om bepaalde servers met voorrang te infecteren.

Een jaar of twee geleden een cursus in Nieuwegein (ik meen via Global Knowledge) bijgewoond over cyber security. Daarin werd getoond hoe een honeypot werd aangevallen met een (destijds) actuele malware. Je zag hoe systemen via bekende CVE's en af en toe een 0-day werden besmet met de malware, waarna de aanvallers toegang kregen en het netwerk van de honeypot in kaart konden brengen. Met die kennis werd prioriteit bepaald (welke server eerst en welke kon wachten, zodat er bij vroegtijdige ontdekking toch genoeg encrypt was om losgeld te kunnen vragen). Na enkele weken werd de sleutel verwijderd van alle geïnfecteerde machines en toonde de malware het losgeldscherm op alle geïnfecteerde machines met een UI.

De periode was lang genoeg om ervoor te zorgen dan ook de grandfatherbackup was versleuteld.

De tip was daar ook: werk met tapes of andere removable media en draag die periodiek over naar een air gapped machine. Laat software, of een beheerder, daar bestanden van bekijken om te zien of ze geopend kunnen worden.

[ Voor 3% gewijzigd door Heroic_Nonsense op 19-08-2020 07:57 ]

[fRiEtJeSaTe]

Ok helder, deels.
Ik focus even op de fileserver. Deze wordt als VM gebackupt, en regelmatig gecontroleerd op werking. Men ziet de ransomware over het hoofd omdat de bestanden benaderbaar blijven via de extra laag op de fileserver die onthefly decrypt. Het moment is daar de ransomware wordt actief, sleutel wordt verwijderd.

Als er dan een backup teruggezet wordt van de complete VM, dan zit die decyptiesleutel en laag er toch nog in en zijn de bestanden benaderbaar? Mits de datum in bet verleden blijft zodat de ransomware niet actief wordt? Of staat de decryptiesleutel niet op de fileserver maar in de cloud?

[ Voor 8% gewijzigd door fRiEtJeSaTe op 19-08-2020 18:33 ]

[downtime]

fRiEtJeSaTe schreef op woensdag 19 augustus 2020 @ 18:30:
Of staat de decryptiesleutel niet op de fileserver maar in de cloud?

De decryptiesleutel staat op de client. Als de besmette clients op een (vooraf bepaalde) datum gelijktijdig de decryptiesleutel wissen, valt er weinig terug te halen. De meeste bedrijven maken niet eens backups van de clients.

[Bockelaar]

F_J_K schreef op maandag 17 augustus 2020 @ 15:35:
[...]

Dat valt dus te mitigeren door achter de air gap de backup structureel iedere keer te testen. Verspreid @random een paar honderd bestanden van variërende grootte op evenzoveel plaatsen en een dozijn belangrijkste bestandstypes. Check iedere keer de checksums met de aan jouw kant bekende checksums. Als er een verschil zit in 1 van die files: meteen piepen. (En oudere backups dan niet meer weggooien tot er duidelijkheid is )

Of loop ik achter?

en dat in een kleine MKB? met 2 man? succes

[F_J_K]

Bockelaar schreef op woensdag 19 augustus 2020 @ 18:43:
[...]

en dat in een kleine MKB? met 2 man? succes

Daar zijn scripts voor uitgevonden, inderdaad niet met de hand kijken en met kroontjespen afvinken

[Gomez12]

fRiEtJeSaTe schreef op woensdag 19 augustus 2020 @ 18:30:
Ok helder, deels.
Ik focus even op de fileserver. Deze wordt als VM gebackupt, en regelmatig gecontroleerd op werking. Men ziet de ransomware over het hoofd omdat de bestanden benaderbaar blijven via de extra laag op de fileserver die onthefly decrypt. Het moment is daar de ransomware wordt actief, sleutel wordt verwijderd.

Als er dan een backup teruggezet wordt van de complete VM, dan zit die decyptiesleutel en laag er toch nog in en zijn de bestanden benaderbaar? Mits de datum in bet verleden blijft zodat de ransomware niet actief wordt? Of staat de decryptiesleutel niet op de fileserver maar in de cloud?

In 1e instantie klopt je beschrijving. Alleen zelfs relatief simpele ransomware zal periodiek online verifieren of de datum nog klopt en/of de decryptiesleutel al ingetrokken is, waarop de online server antwoord dat hij al ingetrokken is oftewel hij kan verwijderd worden.
En dat valt wel weer te voorkomen door de VM zonder internet te restoren.

Alleen dan heb je dus een infected client nodig die de bestanden moet benaderen en geen internet heeft en die zeer waarschijnlijk in sommige bestanden die hij produceert weer de ransomware stopt om zichzelf verder te verspreiden...

Theoretisch mogelijk, praktisch erg kostbare excercitie omdat je echt elk bestandje 100% moet verifieren, terwijl je weet dat minimaal je vroegere virusscanner hem niet herkent, dus het is maar net de vraag of je nieuw aangeschafte AV hem wel in alle varianten gaat herkennen.
Als er 1 bestandje tussendoor slipt dan heb je over x tijd weer feest

F_J_K schreef op woensdag 19 augustus 2020 @ 19:05:
[...]

Daar zijn scripts voor uitgevonden, inderdaad niet met de hand kijken en met kroontjespen afvinken

Heb je wellicht wat links naar die scripts (of betaalde programma's) want met kleine MKB en 2 man op systeembeheer heb ik eerlijk gezegd weinig vertrouwen in iets zelfgebrouwen van die 2 man, het is simpelweg een specialisme op zich om het echt goed te krijgen etc.

Dan zou ik toch liever zien : Betaal x en het is gewoon geregeld en wordt onderhouden door experts...

[jimbo123]

Wim-Bart schreef op woensdag 19 augustus 2020 @ 02:58:
Even over backup. Je kan Air Backed backups gewoon testen. Enige wat je nodig hebt is wat oudere hardware die los staat van de rest.

Wat je doet is dat je op een oude server met voldoende ruimte, ESX hebt draaien, gratis versie is geen enkel issue.
Daar restore je een aantal VM's naar toe, een domein controller (je PDC) een database server, een fileserver (of gedeelte daar van) wat applicatie servers. Kortom een kleine representatie van je omgeving. Belangrijk is om niets te wijzigen. Je past zelfs geen IP adressen aan.

Je zorgt ervoor dat het VM Netwerk waarin de servers staan geen verbinding naar buiten heeft. Zeer belangrijk, ook omdat je je IP nummers niet moet wijzigen. Je start nu alle VM's op, alsof het gewoon je productie omgeving is.

Hierna begin je de tijd van de ESX server in stapjes van een paar dagen te verhogen, dit kan je met een script doen. Gewoon iedere 30 minuten een dag er bij. Dat laat je gewoon draaien tot de omgeving 6 maanden vooruit loopt. Hieruit kan je dan zien wat er gaat gebeuren.

Na de test gooi je alles weer weg.

Dan ga je er wel vanuit dat de ransomware offline de datum/tijd checkt als er geen internetverbinding is. Denk dat ‘ie meestal gewoon blijft slapen als er geen verbinding met internet mogelijk is

[Wim-Bart]

jimbo123 schreef op donderdag 20 augustus 2020 @ 10:25:
[...]


Dan ga je er wel vanuit dat de ransomware offline de datum/tijd checkt als er geen internetverbinding is. Denk dat ‘ie meestal gewoon blijft slapen als er geen verbinding met internet mogelijk is

Op te lossen door een backup internet lijntje te gebruiken Scenario kan natuurlijk gewoon aangepast worden op punten. Het gaat om het concept.

[burnedhardware]

ik vind het scenario van encryptiesoftware op alle devices met een timed detonation behoorlijk onwaarschijnlijk en onnodig complex, zeker als je bedenkt hoe snel notpetya en wannacry om zich heen sloegen. Heeft iemand een bron/voorbeeld waar dit scenario heeft gespeeld?

als aanvaller is het makkelijker om data te extraheren om eventueel te verkopen (al was het maar als pressiemiddel richting slachtoffer zoals oa Maze doet), eventueel eerst (handmatig, je zit toch al op dat netwerk) backups verzieken en dan pas de boel versleutelen.

[F_J_K]

Gomez12 schreef op woensdag 19 augustus 2020 @ 22:07:
[...]
Heb je wellicht wat links naar die scripts (of betaalde programma's) want met kleine MKB en 2 man op systeembeheer heb ik eerlijk gezegd weinig vertrouwen in iets zelfgebrouwen van die 2 man, het is simpelweg een specialisme op zich om het echt goed te krijgen etc.

Dan zou ik toch liever zien : Betaal x en het is gewoon geregeld en wordt onderhouden door experts...

Is met een paar regels powershell of bash te maken, licentie kopen lijkt me overkill.
Bv.

code:

# bron: https://stackoverflow.com/questions/11746287/compare-filehash-in-powershell
# Get the file hashes
$hashSrc = Get-Hash $file -Algorithm "SHA256"
$hashDest = Get-Hash $file2 -Algorithm "SHA256"

# Compare the hashes & note this in the log
If ($hashSrc.HashString -ne $hashDest.HashString)
{
  Add-Content -Path $cLogFile -Value " Source File Hash: $hashSrc does not 
  equal Existing Destination File Hash: $hashDest the files are NOT EQUAL."
}

Maar dan dus een vaste waarde ipv hashSrc (en in een loopje meer 'canary in the coal mine' files langslopen) en desgewenst Send-MailMessage ipv logfile aanvullen. Idem bijv. shasum onder Linux.

[ Voor 0% gewijzigd door F_J_K op 20-08-2020 11:35 . Reden: bron opnemen in de [code= tag is onzinnig, nu dus als comment erbij ]

[Gomez12]

F_J_K schreef op donderdag 20 augustus 2020 @ 11:34:
[...]
Is met een paar regels powershell of bash te maken, licentie kopen lijkt me overkill.
...
Maar dan dus een vaste waarde ipv hashSrc (en in een loopje meer 'canary in the coal mine' files langslopen) en desgewenst Send-MailMessage ipv logfile aanvullen. Idem bijv. shasum onder Linux.

Tja, 2 mogelijkheden :
- Of je restored echt dagelijks elke backup en checked die (en feitelijk ken ik geen enkel bedrijf wat dat doet, 1x per week is max) en dan ook nog eens uitgebreid want als je het merkt als je al 90% kwijt bent dan ben je een beetje laat.
- Of je krijgt een scripting oplossing die er heel anders uit gaat zien omdat je geen goede hashes meer live hebt, je zal die separaat moeten bijhouden etc. Je moet rekening houden met false-positives vanuit user-edits etc.

Jouw simplistische oplossing vind ik leuk als je je backup in een half uurtje erdoorheen draait en je ook in een halfuurtje een airgapped restore kan doen, maar ik ken weinig bedrijven die die getallen halen

[MOOS]

fRiEtJeSaTe schreef op maandag 17 augustus 2020 @ 15:00:
Ik werk voor een MKB-bedrijf met ongeveer 150 Windows devices, 2 man part-time op de IT-afdeling.
Nu vroeg ik mezelf af hoe (snel) wij recoveren van een ransomware-aanval, zoals die zo vaak in de media te vinden is de laatste tijd.

We maken offline-backups van data en servers; air-gapped, redelijk veilig denk ik. Het gros van de servers draait virtueel in een cluster en is redelijk snel te herstellen.

Maar wat heb ik aan draaiende servers als alle clients naar een bitcoin-scherm (Petya) zitten te kijken? Juist hier zit voor ons het probleem. We hebben veel mensen in de buitendienst, die ik graag een mogelijkheid zou willen geven om op dat moment van afstand te kunnen herstellen, naar in ieder geval een soort basisniveau. Met MDT dwing ik iedereen per direct naar kantoor, geen wenselijke situatie.

Ik begrijp dat Windows Autopilot mogelijk geschikt is, maar betekent dit een complete revisie van (Dell) hardware? (vergelijkbaar aan Apple MDM, bestaande toestellen kunnen niet worden toegevoegd?). Of kan ik ook bestaande hardware herstellen? Ransomware versleutelt alles, dus het apparaat zal toch een soort pre-boot omgeving moeten hebben? Of de pragmatische / low-tech oplossing; Autopilot i.c.m. een usb-stick die we aan alle buitendienst collega's verstrekken?

Wie kent het probleem en heeft mogelijk een oplossing?

MDT offline media is één oplossing.

[Steven-b]

Excuses voor de late reply, ik ben niet zo actief op het forum maar zag dit interessante topic toevallig voorbij komen tijdens het scrollen op het forum

Wijzelf gebruiken SAN's die het ZFS filesysteem draaien, de snapshot functionaliteit is fantastisch en je zet bij wijze van spreken je omgeving in een handomdraai terug afhankelijk van hoeveel data je moet restoren natuurlijk.

[skai21]

Steven-b schreef op donderdag 14 januari 2021 @ 13:29:
Excuses voor de late reply, ik ben niet zo actief op het forum maar zag dit interessante topic toevallig voorbij komen tijdens het scrollen op het forum

Wijzelf gebruiken SAN's die het ZFS filesysteem draaien, de snapshot functionaliteit is fantastisch en je zet bij wijze van spreken je omgeving in een handomdraai terug afhankelijk van hoeveel data je moet restoren natuurlijk.

Maar niet airgapped, waar er dus kans is dat ook die versleuteld wordt. Wij hebben alles draaien op NetApps en hebben ook super uitgebreidde en snelle restore mogelijkheden. Maar daarnaast toch ook echt nog een of meerdere airgapped alternatieve.

[Steven-b]

skai21 schreef op dinsdag 19 januari 2021 @ 21:55:
[...]

Maar niet airgapped, waar er dus kans is dat ook die versleuteld wordt. Wij hebben alles draaien op NetApps en hebben ook super uitgebreidde en snelle restore mogelijkheden. Maar daarnaast toch ook echt nog een of meerdere airgapped alternatieve.

Dat hangt er een beetje vanaf uiteraard hoe de infrastructuur ontworpen is, ZFS Snapshots zijn read-only dus daar valt weinig aan te torsen tenzij er iemand toegang heeft tot dat systeem en deze zou deleten.
Sommige KMO's die het budget ervoor hebben doen ook een offsite replicatie van hun snapshots en niets anders buiten het systeem dat de snapshots verzend heeft hier toegang toe.

Wij gebruiken de off-site replicatie meer om de snapshots langer te kunnen behouden bv. maanden en eventueel jaren (dat laatste is nu nog niet voorgevallen, maar het kan.)
Op de productiesystemen zelf staat er uiteraard een kortere retentietijd.

De storage zelf word gekoppeld via iSCSI naar de Windows/VMWare laag dus als er iets geencrypteerd zou worden is het de ZVOL maar niet de snapshots.

Nu moet ik eerlijk toegeven dat ik geen ervaring heb met NetApp, dus ik ken zijn snapshot/restore mogelijkheden niet.
Ook de term Airgapped begrijp ik maar had ik tot nu toe niet gehoord, ik ben er wel van overtuigd dat dit mogelijk is om een systeem te hebben dat backups bijhoud en niet verbonden is met het internet maar op een gegeven moment zal je toch niet anders kunnen dan ook hier toegang tot te voorzien om te maintenancen bevoorbeeld of de storage die gerepliceerd dient te worden (op dat moment onstaat er effectief een fysieke link tussen de productiesystemen en het airgapped systeem, deze link is een risico.)

Ik ken niemand die bv. een systeem volledig offline houd, updates binnenhaalt elders, deze eerst gaat verifiëren op een ander systeem om dan vervolgens deze te implementeren op het airgapped systeem.
Ook qua data ken ik niemand die dit manueel begint over te zetten:

Hiermee bedoel ik bv in het geval van ZFS een heleboel snapshots repliceren naar een aparte pool op aparte disks om dan vervolgens deze disks te verplaatsen naar het airgapped systeem om deze over te zetten.
Want alleen dan bekom je naar mijn mening een echt airgapped backup systeem maar ook hier kan er al vanalles ingeslopen zijn zonder dat je het beseft en kan je alleen hopen dat je genoeg retentie had om de klok terug te draaien.

Kan je meer details geven over de airgapped alternatieven? Ik ben hierin zeker wel zéér geintresseerd en kan hier vooral van bijleren.

[skai21]

Steven-b schreef op woensdag 20 januari 2021 @ 09:52:
[...]


Dat hangt er een beetje vanaf uiteraard hoe de infrastructuur ontworpen is, ZFS Snapshots zijn read-only dus daar valt weinig aan te torsen tenzij er iemand toegang heeft tot dat systeem en deze zou deleten.
Sommige KMO's die het budget ervoor hebben doen ook een offsite replicatie van hun snapshots en niets anders buiten het systeem dat de snapshots verzend heeft hier toegang toe.

Wij gebruiken de off-site replicatie meer om de snapshots langer te kunnen behouden bv. maanden en eventueel jaren (dat laatste is nu nog niet voorgevallen, maar het kan.)
Op de productiesystemen zelf staat er uiteraard een kortere retentietijd.

De storage zelf word gekoppeld via iSCSI naar de Windows/VMWare laag dus als er iets geencrypteerd zou worden is het de ZVOL maar niet de snapshots.

Nu moet ik eerlijk toegeven dat ik geen ervaring heb met NetApp, dus ik ken zijn snapshot/restore mogelijkheden niet.
Ook de term Airgapped begrijp ik maar had ik tot nu toe niet gehoord, ik ben er wel van overtuigd dat dit mogelijk is om een systeem te hebben dat backups bijhoud en niet verbonden is met het internet maar op een gegeven moment zal je toch niet anders kunnen dan ook hier toegang tot te voorzien om te maintenancen bevoorbeeld of de storage die gerepliceerd dient te worden (op dat moment onstaat er effectief een fysieke link tussen de productiesystemen en het airgapped systeem, deze link is een risico.)

Ik ken niemand die bv. een systeem volledig offline houd, updates binnenhaalt elders, deze eerst gaat verifiëren op een ander systeem om dan vervolgens deze te implementeren op het airgapped systeem.
Ook qua data ken ik niemand die dit manueel begint over te zetten:

Hiermee bedoel ik bv in het geval van ZFS een heleboel snapshots repliceren naar een aparte pool op aparte disks om dan vervolgens deze disks te verplaatsen naar het airgapped systeem om deze over te zetten.
Want alleen dan bekom je naar mijn mening een echt airgapped backup systeem maar ook hier kan er al vanalles ingeslopen zijn zonder dat je het beseft en kan je alleen hopen dat je genoeg retentie had om de klok terug te draaien.

Kan je meer details geven over de airgapped alternatieven? Ik ben hierin zeker wel zéér geintresseerd en kan hier vooral van bijleren.

Veeam Immutable Backups zijn wel eens goed om je op in te lezen:
https://www.veeam.com/blo...ud-tier-immutability.html

Dit maakt een Amazon S3 bucket aan voor iedere backup, en zet daar een retentie op.
Tijdens die retentie kan niemand het weggooien of aanpassen, zelfs een full AWS admin niet.
Als je dus perongeluk een 7 jaar retentie immutable instelt, zit je dus letterlijk 7 jaar vast aan die backup.

Airgapped / immutable backups, zijn echt intressant leesmateriaal.

Mocht je denken dat je ZFS snapshots alleen voldoende "ge-airgapped" zijn, zou ik het volgende eens lezen:
https://www.reddit.com/r/...xi_ransomware_postmortem/
Het is een ander voorbeeld, en een gerichte aanval. Maar het geeft wel aan dat zolang het niet 100% losgekoppeld is. Je het altijd kunt beinvloeden, encrypten of verwijderen.
Bij een echte airgapped / immutable backup, is de enige mogelijkheid om het fout te laten lopen. Het systeem infiltreren, zorgen dat je malware/ransomware onder de radar blijft tot de volledige immutable retentie voorbij is. En dan pas enablen..

Al met al vind ik het intressante materie, en de grootste uitdaging is de beste middenweg vinden in bruikbaarheid/kosten/security.

[Steven-b]

skai21 schreef op woensdag 20 januari 2021 @ 10:11:
[...]


Veeam Immutable Backups zijn wel eens goed om je op in te lezen:
https://www.veeam.com/blo...ud-tier-immutability.html

Dit maakt een Amazon S3 bucket aan voor iedere backup, en zet daar een retentie op.
Tijdens die retentie kan niemand het weggooien of aanpassen, zelfs een full AWS admin niet.
Als je dus perongeluk een 7 jaar retentie immutable instelt, zit je dus letterlijk 7 jaar vast aan die backup.

Airgapped / immutable backups, zijn echt intressant leesmateriaal.

Mocht je denken dat je ZFS snapshots alleen voldoende "ge-airgapped" zijn, zou ik het volgende eens lezen:
https://www.reddit.com/r/...xi_ransomware_postmortem/
Het is een ander voorbeeld, en een gerichte aanval. Maar het geeft wel aan dat zolang het niet 100% losgekoppeld is. Je het altijd kunt beinvloeden, encrypten of verwijderen.
Bij een echte airgapped / immutable backup, is de enige mogelijkheid om het fout te laten lopen. Het systeem infiltreren, zorgen dat je malware/ransomware onder de radar blijft tot de volledige immutable retentie voorbij is. En dan pas enablen..

Al met al vind ik het intressante materie, en de grootste uitdaging is de beste middenweg vinden in bruikbaarheid/kosten/security.

Bedankt, dit is inderdaad interessante materie en doet me opnieuw nadenken op vele vlakken van security/disaster recovery etc.

Ik dacht zeker niet dat ZFS snapshots alleen voldoende zouden zijn maar toch al zeker een stap in de juiste richting indien men off-site gaat repliceren en zolang men zich geen toegang kan verschaffen tot deze infrastructuur of tot dit specifieke systeem.

AWS S3 Object Lock / Immutable backups/snapshots is inderdaad intressant, helaas bekijken vele klanten dit alleen maar als een extra kost, de ogen worden pas geopend nadat m'n serieus in de stront zit.
Dit is niet alleen zo bij de kleintjes maar ook bij de grotere heb ik uit eigen ervaring helaas al kunnen vaststellen.

Overigens zal ransomware alleen nog maar geavanceerder worden, er zijn er blijkbaar al die zich kunnen nestelen in je UEFI firmware (gelukkig nog geen ervaring mee gehad!) die je steeds opnieuw en opnieuw zal infecteren maakt niet uit welke snapshot/backup je dan ook restored.

Ook hier zou je van kunnen recoveren maar het maakt het voor de meeste toch een uitdaging en dit gaat ook op voor mezelf.

[skai21]

Steven-b schreef op woensdag 20 januari 2021 @ 11:58:
[...]


Bedankt, dit is inderdaad interessante materie en doet me opnieuw nadenken op vele vlakken van security/disaster recovery etc.

Ik dacht zeker niet dat ZFS snapshots alleen voldoende zouden zijn maar toch al zeker een stap in de juiste richting indien men off-site gaat repliceren en zolang men zich geen toegang kan verschaffen tot deze infrastructuur of tot dit specifieke systeem.

AWS S3 Object Lock / Immutable backups/snapshots is inderdaad intressant, helaas bekijken vele klanten dit alleen maar als een extra kost, de ogen worden pas geopend nadat m'n serieus in de stront zit.
Dit is niet alleen zo bij de kleintjes maar ook bij de grotere heb ik uit eigen ervaring helaas al kunnen vaststellen.

Overigens zal ransomware alleen nog maar geavanceerder worden, er zijn er blijkbaar al die zich kunnen nestelen in je UEFI firmware (gelukkig nog geen ervaring mee gehad!) die je steeds opnieuw en opnieuw zal infecteren maakt niet uit welke snapshot/backup je dan ook restored.

Ook hier zou je van kunnen recoveren maar het maakt het voor de meeste toch een uitdaging en dit gaat ook op voor mezelf.

Malware zal ons altijd een stap voorblijven, dat is helaas iets waar we ons bij neer zullen moeten leggen.
Enige wat je kunt doen is zorgen dat de buren intressanter zijn dan jij.

Ik vind de metafoor: Repareer het dak wanneer de zon schijnt. Altijd heel fijn
Als consultant lukt het met toch vaak om klanten te overtuigen.

[CAPSLOCK2000]

Even een andere insteek:
Zorg dat je een gegarandeerd veilige en onafhankelijke werkplek hebt.

Als alles om je heen in stort wil je er niet mee geconfronteerd worden dat je PC niet meer werkt omdat netwerk-logins stuk zijn, of zo iets. Op dat moment wil je ook niet een nieuwe PC gaan installeren want je kan niks wat je download nog vertrouwen.

Ik heb een voorgeinstalleerde laptop met daarnaast een read-only USB-stick met een Ubuntu Live image. Zo kan ik altijd iets booten dat ik kan vertrouwen.

Daarnaast wil je de belangrijkste documentatie en wachtwoorden beschikbaar hebben. Je wil niet in de situatie komen dat je wel backups hebt, maar er niet bij komt omdat het wachtwoord alle op de harde schijf staat van een computer die niet meer gebruikt kan worden.

Neem een keer de tijd om een restore actie te oefenen.
Ga ergens met je laptop en een pot koffie zitten en doe alsof alles weg is en je de boel opniew moet opbouwen.

[paulhekje]

wachtwoorden 1x per half jaar printen en in dichte envelop in een kluis; is nog steeds een goede backupmethode!