VPN-login en dan ransomware: wat het bewijs ondersteunt

Alles hieronder gebruikt een hypothetisch record, samengesteld om een vorm te tonen en niet om een echte zaak te beschrijven. Het leest als een keten: een gateway-authenticatie om 02:14, een desktopsessie om 02:19, een wijziging van een bevoorrecht account om 02:41 en versleutelde bestanden die om 03:02 werden gevonden. De eerste regel lijkt het antwoord, en het rapport wordt vaak geschreven alsof dat zo is. Een login is een gebeurtenis die een gateway vastlegde, geen bevinding over hoe iemand binnenkwam, en dat verschil bepaalt wat u hierna doet.

Het symptoom: een login die op het antwoord lijkt

Authenticatielogs zijn het makkelijkst te verkrijgen bewijs en het makkelijkst te overinterpreteren. Ze tonen dat de dienst op een moment, vanaf een adres, voor een account een inloggegeven accepteerde. Ze tonen niet wie het inloggegeven beheerde, of de gateway werd misbruikt, of het apparaat van de accounthouder al was gecompromitteerd.

Drie verklaringen passen bij dezelfde inlogregel. Iemand gebruikte een gestolen wachtwoord, en de gateway deed precies waarvoor hij is gebouwd. Een laptop die eerder was gecompromitteerd, logde gewoon zoals gebruikelijk in. Een ongerelateerde blootgestelde dienst leverde de echte binnenkomst, en de VPN-sessie is een latere, aparte actie van dezelfde actor.

Elke verklaring voorspelt ander bewijs elders in de omgeving, daarom moet het onderzoek naar die voorspellingen zoeken en niet naar bevestiging van de eerste die past. Een gestolen wachtwoord voorspelt ongebruikelijke authenticatiegeografie of -timing. Een gecompromitteerde laptop voorspelt host-artefacten vóór de login. Een ongerelateerd toegangspunt voorspelt activiteit die niets met de gateway te maken heeft.

Houd de gebeurtenissen apart voordat u ze vertelt

Schrijf de gebeurtenissen apart op voordat er een verhaal bestaat, want een verhaal nodigt uit de tijdlijn rond een verdachte te ordenen. Elke regel moet zeggen wat dat record vaststelt en, apart, wat het alleen niet kan vaststellen. Op het moment dat twee regels in één zin samensmelten, heeft een interpretatie al gewonnen.

Merk op dat de laatste gebeurtenis over detectie gaat en niet over de aanvaller. Ontdekkingstijd en compromitteringstijd liggen gewoonlijk uren of weken uit elkaar, en een rapport dat ze gelijkstelt, zal elke lezer na u misleiden.

Leg vast waar elke tijdstempel vandaan komt, niet alleen wat hij zegt. Een ontvangsttijd van een collector, een gebeurtenistijd en een detectietijd zijn drie verschillende getallen, en ze stil in één kolom normaliseren is hoe een tijdlijn een vorm krijgt die het bewijs nooit had.

Voeg records alleen samen waar identificatoren overeenkomen

Records samenvoegen is een hypothese, geen opmaakstap. De accountnaam, het toegewezen VPN-adres, de doelserver en de sessie-identificator moeten overeenkomen voordat twee rijen één verhaal worden. Een gedeeld openbaar adres is niet genoeg, want het is gedeeld door ontwerp.

Lees de tabel van onder naar boven wanneer u een binnenkomst volgt, en van boven naar beneden wanneer u de impact afbakent, omdat de twee vragen tegengestelde richtingen nodig hebben. Waar identificatoren echt overeenkomen, zeg dat en verwijs naar beide records. Waar ze dat niet doen, laat de leemte zichtbaar in plaats van hem met een aanname te dichten.

Hier misleidt ook een bekende gebruikersnaam. Hetzelfde account kan ’s ochtends door de rechtmatige houder en ’s nachts door iemand anders worden gebruikt, en de accountnaam alleen kan hen niet onderscheiden. Schrijf het account toe, schrijf daarna de persoon apart toe, en alleen wanneer iets dat ondersteunt. De meeste tijdlijnen die bij beoordeling uiteenvallen, deden precies deze stap te snel.

Ontbrekende logs zijn een leemte, geen negatief bewijs

De afwezigheid van gebeurtenissen met mislukte wachtwoorden bewijst niet dat de geslaagde login legitiem was. Geldige gestolen inloggegevens leveren een geslaagd authenticatierecord op en helemaal geen fouten, en dat is precies wat diefstal van inloggegevens aantrekkelijk maakt.

Evenzo zegt een poort die vandaag dicht is iets over vandaag. Hij zegt niets over of die dienst toen blootgesteld was, of die toen kwetsbaar was, of die de aanval droeg. Historische configuratie en bewijs van de dienst zijn de enige manier om die leemte te dichten.

Benoem de leemte expliciet in het rapport. ’We hebben geen logs voor dat interval’ is een verdedigbare zin; ’er is verder niets gebeurd’ is dat niet, en die wordt tegen u geciteerd. Leemtes hebben ook eigenaren: noem het systeem dat het record had moeten produceren en waarom het dat niet deed. Die regel maakt van een weglating een herstelitem.

Schrijf bevindingen op het niveau dat het bewijs ondersteunt

Coördineer bewaring, indamming en herstel via de incidenteigenaar in plaats van hem heen. De technische richtlijn van CISA benadrukt het verzamelen van relevante artefacten en logs voordat herstel verandert wat nog beschikbaar is, en die volgorde is belangrijker dan welk afzonderlijk hulpmiddel dan ook.

Een vermoed exploit opnieuw uitvoeren tegen live apparatuur om de leemte te dichten is het extra risico niet waard. Een test die aantoont dat een aanval zou kunnen werken, is geen bewijs dat hij werkte, en het verschil tussen die twee uitspraken is de hele discipline van de oefening.

Sluit af met vier lijsten: wat is waargenomen, welke relaties de records ondersteunen, wat hypothese blijft en welke records niet beschikbaar zijn. ’Tijdens het incident is een VPN-account gebruikt’ hoort in de tweede lijst wanneer de records dat ondersteunen. ’De VPN veroorzaakte de ransomware’ hoort nergens, totdat iets causaliteit vaststelt.