Inicio de sesión na VPN e despois ransomware: que sosteñen as probas

Todo o que segue usa un rexistro hipotético, reunido para mostrar unha forma e non para describir un caso real. Leses como unha cadea: unha autenticación na pasarela ás 02:14, unha sesión de escritorio ás 02:19, un cambio de conta privilexiada ás 02:41 e ficheiros cifrados atopados ás 03:02. A primeira liña parece a resposta, e o informe adoita escribirse como se o fose. Un inicio de sesión é un evento que rexistrou unha pasarela, non unha conclusión sobre como entrou alguén, e esa diferenza decide que fai vostede despois.

O síntoma: un inicio de sesión que parece a resposta

Os rexistros de autenticación son as probas máis fáciles de obter e as máis fáciles de sobreinterpretar. Mostran que o servizo aceptou unha credencial nun momento, desde un enderezo, para unha conta. Non mostran quen controlaba a credencial, se a pasarela foi explotada ou se o dispositivo do titular da conta xa estaba comprometido.

Tres explicacións encaixan na mesma liña de inicio de sesión. Alguén usou un contrasinal roubado, e a pasarela fixo exactamente aquilo para o que foi construída. Un portátil comprometido antes simplemente iniciou sesión como de costume. Un servizo exposto non relacionado forneceu a entrada real, e a sesión VPN é unha acción posterior e separada do mesmo actor.

Cada explicación predí probas distintas noutros lugares da contorna, polo que a investigación debe buscar esas predicións e non a confirmación da primeira que encaixe. Un contrasinal roubado predí unha xeografía ou un momento de autenticación inusuais. Un portátil comprometido predí artefactos do equipo antes do inicio de sesión. Un punto de entrada non relacionado predí actividade que non ten nada que ver coa pasarela.

Manteña os eventos separados antes de narralos

Escriba os eventos por separado antes de que exista calquera narración, porque unha narración invita a ordenar a cronoloxía arredor dun sospeitoso. Cada liña debe dicir que establece ese rexistro e, por separado, que non pode establecer por si só. No momento en que dúas liñas se fusionan nunha frase, unha interpretación xa gañou.

Observe que o último evento trata da detección e non do atacante. O momento do descubrimento e o momento do compromiso adoitan estar separados por horas ou semanas, e un informe que os equipara enganará a todo lector que veña despois de vostede.

Rexiste de onde veu cada marca temporal, non só o que di. A hora de recepción dun colector, a hora dun evento e a hora de detección son tres números distintos, e normalizalos en silencio nunha soa columna é como unha cronoloxía adquire unha forma que as probas nunca tiveron.

Unir rexistros só onde coincidan os identificadores

Fusionar rexistros é unha hipótese, non un paso de formato. O nome da conta, o enderezo VPN asignado, o equipo de destino e o identificador de sesión deben coincidir antes de que dúas filas se convertan nunha historia. Un enderezo público compartido non abonda, porque se comparte por deseño.

Lea a táboa de abaixo cara arriba cando rastree unha entrada, e de arriba cara abaixo cando delimite o impacto, porque as dúas preguntas necesitan direccións opostas. Onde os identificadores coincidan de verdade, dígao e cite ambos os rexistros. Onde non coincidan, deixe o oco visible en lugar de pechalo cunha suposición.

Aquí tamén engana un nome de usuario familiar. A mesma conta pode usala o titular lexítimo pola mañá e outra persoa pola noite, e o nome da conta por si só non pode distinguilos. Atribúa a conta, despois atribúa a persoa por separado, e só cando algo o sosteña. A maioría das cronoloxías que se desmoronan na revisión fixeron exactamente este paso con demasiada présa.

Os rexistros que faltan son un oco, non unha proba negativa

A ausencia de eventos de contrasinal fallida non demostra que o inicio de sesión correcto fose lexítimo. Unhas credenciais roubadas válidas producen un rexistro de autenticación correcto e ningún fallo, e iso é exactamente o que fai atractivo o roubo de credenciais.

Do mesmo xeito, un porto que hoxe está pechado di algo sobre hoxe. Non di nada sobre se ese servizo estaba exposto entón, se era vulnerable entón ou se levou o ataque. A configuración histórica e as probas do servizo son a única maneira de pechar ese oco.

Declare o oco explicitamente no informe. «Non temos rexistros para ese intervalo» é unha frase defendible; «non pasou nada máis» non o é, e citaránlla de volta. Os ocos tamén teñen responsables: nomee o sistema que debería ter producido o rexistro e por que non o fixo. Esa liña converte unha omisión nun elemento de remediación.

Escriba os achados no nivel que sosteñen as probas

Coordine a preservación, a contención e a recuperación a través do responsable do incidente, non á marxe. A guía técnica de CISA subliña a recollida de artefactos e rexistros relevantes antes de que a remediación cambie o que queda dispoñible, e esa orde importa máis que calquera ferramenta concreta.

Volver executar un suposto exploit contra equipamento vivo para pechar o oco non vale o risco que engade. Unha proba que mostra que un ataque podería funcionar non é proba de que funcionase, e a diferenza entre esas dúas afirmacións é toda a disciplina do exercicio.

Remate con catro listas: que se observou, que relacións sosteñen os rexistros, que segue sendo hipótese e que rexistros non están dispoñibles. «Usouse unha conta VPN durante o incidente» pertence á segunda lista cando os rexistros o sosteñen. «A VPN causou o ransomware» non pertence a ningures ata que algo estableza causalidade.