Accesso VPN e poi ransomware: cosa sostengono le prove

Tutto quanto segue usa un record ipotetico, messo insieme per mostrare una forma e non per descrivere un caso reale. Si legge come una catena: un’autenticazione sul gateway alle 02:14, una sessione desktop alle 02:19, un cambio di account privilegiato alle 02:41 e file cifrati trovati alle 03:02. La prima riga sembra la risposta, e il rapporto è spesso scritto come se lo fosse. Un accesso è un evento che un gateway ha registrato, non una conclusione su come qualcuno sia entrato, e quella differenza decide cosa farete dopo.

Il sintomo: un accesso che sembra la risposta

I registri di autenticazione sono le prove più facili da ottenere e le più facili da sovrainterpretare. Mostrano che il servizio ha accettato una credenziale in un momento, da un indirizzo, per un account. Non mostrano chi controllava la credenziale, se il gateway è stato sfruttato o se il dispositivo del titolare dell’account era già compromesso.

Tre spiegazioni si adattano alla stessa riga di accesso. Qualcuno ha usato una password rubata, e il gateway ha fatto esattamente ciò per cui è costruito. Un portatile compromesso in precedenza ha semplicemente effettuato l’accesso come al solito. Un servizio esposto non correlato ha fornito l’ingresso reale, e la sessione VPN è un’azione successiva e separata dello stesso attore.

Ogni spiegazione predice prove diverse altrove nell’ambiente, per questo l’indagine deve cercare quelle previsioni e non la conferma della prima che si adatta. Una password rubata predice una geografia o un momento di autenticazione insoliti. Un portatile compromesso predice artefatti dell’host prima dell’accesso. Un punto d’ingresso non correlato predice attività che non ha nulla a che vedere con il gateway.

Tenete separati gli eventi prima di raccontarli

Scrivete gli eventi separatamente prima che esista qualsiasi narrazione, perché una narrazione invita a ordinare la cronologia attorno a un sospetto. Ogni riga deve dire cosa stabilisce quel record e, separatamente, cosa non può stabilire da sola. Nel momento in cui due righe si fondono in una frase, un’interpretazione ha già vinto.

Notate che l’ultimo evento riguarda il rilevamento e non l’attaccante. Il momento della scoperta e il momento della compromissione sono di solito separati da ore o settimane, e un rapporto che li equipara ingannerà ogni lettore che verrà dopo di voi.

Registrate da dove viene ogni marca temporale, non solo cosa dice. L’ora di ricezione di un collector, l’ora di un evento e l’ora di rilevamento sono tre numeri diversi, e normalizzarli in silenzio in un’unica colonna è il modo in cui una cronologia acquisisce una forma che le prove non hanno mai avuto.

Unite i record solo dove gli identificatori coincidono

Unire i record è un’ipotesi, non un passaggio di formattazione. Il nome dell’account, l’indirizzo VPN assegnato, l’host di destinazione e l’identificatore di sessione devono coincidere prima che due righe diventino una storia. Un indirizzo pubblico condiviso non basta, perché è condiviso per progettazione.

Leggete la tabella dal basso verso l’alto quando tracciate un ingresso, e dall’alto verso il basso quando delimitate l’impatto, perché le due domande richiedono direzioni opposte. Dove gli identificatori coincidono davvero, ditelo e citate entrambi i record. Dove non coincidono, lasciate visibile la lacuna invece di chiuderla con una supposizione.

È qui che anche un nome utente familiare inganna. Lo stesso account può essere usato dal titolare legittimo al mattino e da qualcun altro di notte, e il solo nome dell’account non può distinguerli. Attribuite l’account, poi attribuite la persona separatamente, e solo quando qualcosa lo sostiene. La maggior parte delle cronologie che crollano in revisione ha fatto esattamente questo passo troppo in fretta.

I registri mancanti sono una lacuna, non una prova negativa

L’assenza di eventi di password fallita non dimostra che l’accesso riuscito fosse legittimo. Credenziali rubate valide producono un record di autenticazione riuscito e nessun fallimento, ed è esattamente ciò che rende attraente il furto di credenziali.

Allo stesso modo, una porta chiusa oggi dice qualcosa su oggi. Non dice nulla sul fatto che quel servizio fosse esposto allora, che fosse vulnerabile allora o che abbia portato l’attacco. La configurazione storica e le prove del servizio sono l’unico modo per chiudere quella lacuna.

Dichiarate la lacuna esplicitamente nel rapporto. «Non abbiamo registri per quell’intervallo» è una frase difendibile; «non è successo altro» non lo è, e vi sarà citata contro. Le lacune hanno anche responsabili: nominate il sistema che avrebbe dovuto produrre il record e perché non l’ha fatto. Quella riga trasforma un’omissione in una voce di rimedio.

Scrivete le conclusioni al livello che le prove sostengono

Coordinate conservazione, contenimento e ripristino attraverso il responsabile dell’incidente e non aggirandolo. L’orientamento tecnico della CISA sottolinea la raccolta di artefatti e registri pertinenti prima che il rimedio cambi ciò che resta disponibile, e quell’ordine conta più di qualsiasi singolo strumento.

Rieseguire un presunto exploit su apparecchiature in produzione per chiudere la lacuna non vale il rischio che aggiunge. Un test che mostra che un attacco potrebbe funzionare non è prova che abbia funzionato, e la differenza tra queste due affermazioni è tutta la disciplina dell’esercizio.

Chiudete con quattro elenchi: cosa è stato osservato, quali relazioni i record sostengono, cosa resta un’ipotesi e quali registri non sono disponibili. «Durante l’incidente è stato usato un account VPN» appartiene al secondo elenco quando i record lo sostengono. «La VPN ha causato il ransomware» non appartiene a nessun elenco finché qualcosa non stabilisce la causalità.