VPN-inloggning och sedan ransomware: vad bevisen stöder
En inloggning klockan 02:14 och krypterade filer klockan 03:02 är en sekvens värd att utreda, inte en ingångspunkt. Håll autentiserings-, sessions- och värdbevis åtskilda.
Allt nedan använder en hypotetisk loggpost, sammanställd för att visa en form och inte för att beskriva ett verkligt fall. Den läses som en kedja: en gateway-autentisering klockan 02:14, en skrivbordssession klockan 02:19, en ändring av ett privilegierat konto klockan 02:41 och krypterade filer som hittades klockan 03:02. Den första raden ser ut som svaret, och rapporten skrivs ofta som om den vore det. En inloggning är en händelse som en gateway registrerade, inte ett fynd om hur någon kom in, och den skillnaden avgör vad du gör härnäst.
Symptomet: en inloggning som ser ut som svaret
Autentiseringsloggar är de lättaste bevisen att skaffa och de lättaste att övertolka. De visar att tjänsten accepterade en inloggningsuppgift vid en tidpunkt, från en adress, för ett konto. De visar inte vem som kontrollerade uppgiften, om gatewayen utnyttjades eller om kontoinnehavarens enhet redan var komprometterad.
Tre förklaringar passar på samma inloggningsrad. Någon använde ett stulet lösenord, och gatewayen gjorde exakt det den är byggd för. En bärbar dator som komprometterats tidigare loggade helt enkelt in som vanligt. En orelaterad exponerad tjänst gav den egentliga ingången, och VPN-sessionen är en senare, separat handling av samma aktör.
Varje förklaring förutsäger olika bevis på andra håll i miljön, därför måste utredningen leta efter dessa förutsägelser och inte efter bekräftelse av den första som passar. Ett stulet lösenord förutsäger ovanlig autentiseringsgeografi eller -tid. En komprometterad bärbar dator förutsäger värdartefakter före inloggningen. En orelaterad ingångspunkt förutsäger aktivitet som inte har något med gatewayen att göra alls.
Håll händelserna åtskilda innan du berättar om dem
Skriv ned händelserna var för sig innan någon berättelse finns, eftersom en berättelse bjuder in till att ordna tidslinjen kring en misstänkt. Varje rad ska säga vad den loggposten fastställer och, separat, vad den inte kan fastställa ensam. I samma ögonblick som två rader smälter samman till en mening har en tolkning redan vunnit.
Lägg märke till att den sista händelsen handlar om upptäckt och inte om angriparen. Upptäcktstid och komprometteringstid ligger rutinmässigt timmar eller veckor isär, och en rapport som likställer dem kommer att vilseleda varje läsare som kommer efter dig.
Registrera var varje tidsstämpel kom ifrån, inte bara vad den säger. En samlares mottagningstid, en händelsetid och en upptäcktstid är tre olika tal, och att tyst normalisera dem till en kolumn är hur en tidslinje får en form som bevisen aldrig hade.
Slå bara samman poster där identifierarna stämmer överens
Att slå samman poster är en hypotes, inte ett formateringssteg. Kontonamnet, den tilldelade VPN-adressen, målvärden och sessionsidentifieraren måste stämma överens innan två rader blir en berättelse. En delad offentlig adress räcker inte, eftersom den är delad av design.
| Record source | Join key that must match | What breaks when the key is missing |
|---|---|---|
| File-share or backup record | file path and modification time | impact cannot be ordered against any session |
| Host process record, EDR or audit log | host name and process start time | the process cannot be placed inside a session |
| Session broker or remote-desktop log | session identifier and target host | the session cannot be traced back to a gateway login |
| Gateway authentication log | account name and assigned VPN address | the session cannot be followed past the gateway |
Läs tabellen nedifrån och upp när du spårar en ingång, och uppifrån och ned när du avgränsar påverkan, eftersom de två frågorna behöver motsatta riktningar. Där identifierarna faktiskt stämmer överens, säg det och hänvisa till båda posterna. Där de inte gör det, låt gapet vara synligt i stället för att stänga det med ett antagande.
Här vilseleder också ett välbekant användarnamn. Samma konto kan användas av den rättmätige innehavaren på morgonen och av någon annan på natten, och kontonamnet ensamt kan inte skilja dem åt. Tillskriv kontot, tillskriv sedan personen separat, och bara när något stöder det. De flesta tidslinjer som faller sönder i granskning gjorde just detta steg för snabbt.
Saknade loggar är ett gap, inte ett negativt bevis
Frånvaron av händelser med misslyckade lösenord bevisar inte att den lyckade inloggningen var legitim. Giltiga stulna inloggningsuppgifter ger en lyckad autentiseringslogg och inga misslyckanden alls, och det är precis det som gör stöld av inloggningsuppgifter attraktivt.
På samma sätt säger en port som är stängd i dag något om i dag. Den säger ingenting om huruvida den tjänsten var exponerad då, huruvida den var sårbar då eller huruvida den bar attacken. Historisk konfiguration och tjänstebevis är det enda sättet att stänga det gapet.
Ange gapet uttryckligen i rapporten. ”Vi har inga loggar för det intervallet” är en försvarbar mening; ”ingenting annat hände” är det inte, och det kommer att citeras tillbaka till dig. Gap har också ägare: namnge systemet som borde ha producerat loggen och varför det inte gjorde det. Den raden gör en utelämnande till en åtgärdspunkt.
Skriv fynd på den nivå som bevisen stöder
Samordna bevarande, inneslutning och återställning genom incidentägaren i stället för runt denne. CISAs tekniska vägledning betonar att samla relevanta artefakter och loggar innan åtgärder ändrar vad som fortfarande är tillgängligt, och den ordningen är viktigare än något enskilt verktyg.
Att köra en misstänkt exploit igen mot produktionsutrustning för att stänga gapet är inte värt den extra risken. Ett test som visar att en attack kunde fungera är inte bevis för att den gjorde det, och skillnaden mellan de två påståendena är hela disciplinen i övningen.
Avsluta med fyra listor: vad som observerades, vilka relationer loggarna stöder, vad som förblir hypotes och vilka loggar som inte är tillgängliga. ”Ett VPN-konto användes under incidenten” hör till den andra listan när loggarna stöder det. ”VPN orsakade ransomware” hör ingenstans hemma förrän något fastställer orsakssamband.