Login na VPN e depois ransomware: o que as evidências sustentam

Tudo abaixo usa um registro hipotético, montado para mostrar uma forma e não para descrever um caso real. Lê-se como uma cadeia: uma autenticação no gateway às 02:14, uma sessão de desktop às 02:19, uma alteração de conta privilegiada às 02:41 e arquivos criptografados encontrados às 03:02. A primeira linha parece a resposta, e o relatório costuma ser escrito como se fosse. Um login é um evento que um gateway registrou, não uma conclusão sobre como alguém entrou, e essa diferença decide o que você fará em seguida.

O sintoma: um login que parece a resposta

Os registros de autenticação são as evidências mais fáceis de obter e as mais fáceis de superinterpretar. Mostram que o serviço aceitou uma credencial num momento, de um endereço, para uma conta. Não mostram quem controlava a credencial, se o gateway foi explorado ou se o dispositivo do titular da conta já estava comprometido.

Três explicações cabem na mesma linha de login. Alguém usou uma senha roubada, e o gateway fez exatamente o que foi construído para fazer. Um notebook comprometido antes simplesmente entrou como de costume. Um serviço exposto sem relação forneceu a entrada real, e a sessão VPN é uma ação posterior e separada do mesmo ator.

Cada explicação prevê evidências diferentes em outros pontos do ambiente, por isso a investigação deve procurar essas previsões, e não a confirmação da primeira que encaixa. Uma senha roubada prevê geografia ou horário de autenticação incomuns. Um notebook comprometido prevê artefatos do host antes do login. Um ponto de entrada sem relação prevê atividade que nada tem a ver com o gateway.

Separe os eventos antes de narrá-los

Escreva os eventos separadamente antes que exista qualquer narrativa, porque uma narrativa convida a ordenar a linha do tempo em torno de um suspeito. Cada linha deve dizer o que aquele registro estabelece e, separadamente, o que ele não pode estabelecer sozinho. No momento em que duas linhas se fundem numa frase, uma interpretação já venceu.

Observe que o último evento trata da detecção e não do atacante. O momento da descoberta e o momento do comprometimento costumam estar separados por horas ou semanas, e um relatório que os equipara enganará todo leitor que vier depois de você.

Registre de onde veio cada carimbo de tempo, não apenas o que ele diz. O horário de recebimento de um coletor, o horário de um evento e o horário de detecção são três números diferentes, e normalizá-los em silêncio numa única coluna é como uma linha do tempo ganha uma forma que as evidências nunca tiveram.

Junte registros apenas onde os identificadores coincidem

Fundir registros é uma hipótese, não uma etapa de formatação. O nome da conta, o endereço VPN atribuído, o host de destino e o identificador de sessão precisam coincidir antes que duas linhas se tornem uma história. Um endereço público compartilhado não basta, porque é compartilhado por projeto.

Leia a tabela de baixo para cima quando rastreia uma entrada, e de cima para baixo quando delimita o impacto, porque as duas perguntas exigem direções opostas. Onde os identificadores realmente coincidem, diga isso e cite os dois registros. Onde não coincidem, deixe a lacuna visível em vez de fechá-la com uma suposição.

É aqui que um nome de usuário familiar também engana. A mesma conta pode ser usada pelo titular legítimo pela manhã e por outra pessoa à noite, e o nome da conta sozinho não consegue distingui-los. Atribua a conta, depois atribua a pessoa separadamente, e só quando algo sustenta isso. A maioria das linhas do tempo que desmoronam na revisão fez exatamente esse passo depressa demais.

Registros ausentes são uma lacuna, não uma prova negativa

A ausência de eventos de senha falha não prova que o login bem-sucedido foi legítimo. Credenciais roubadas válidas produzem um registro de autenticação bem-sucedido e nenhuma falha, e é exatamente isso que torna o roubo de credenciais atraente.

Da mesma forma, uma porta fechada hoje diz algo sobre hoje. Não diz nada sobre se aquele serviço estava exposto então, se era vulnerável então ou se carregou o ataque. A configuração histórica e as evidências do serviço são a única forma de fechar essa lacuna.

Declare a lacuna explicitamente no relatório. «Não temos registros para esse intervalo» é uma frase defensável; «nada mais aconteceu» não é, e isso será citado de volta para você. Lacunas também têm responsáveis: nomeie o sistema que deveria ter produzido o registro e por que não o fez. Essa linha transforma uma omissão em item de correção.

Escreva as conclusões no nível que as evidências sustentam

Coordene preservação, contenção e recuperação por meio do responsável pelo incidente, e não em torno dele. A orientação técnica da CISA destaca a coleta de artefatos e registros relevantes antes que a correção altere o que ainda está disponível, e essa ordem importa mais do que qualquer ferramenta isolada.

Reexecutar um suposto exploit contra equipamento em produção para fechar a lacuna não vale o risco que acrescenta. Um teste que mostra que um ataque poderia funcionar não é prova de que funcionou, e a diferença entre essas duas afirmações é toda a disciplina do exercício.

Termine com quatro listas: o que foi observado, que relações os registros sustentam, o que continua hipótese e quais registros não estão disponíveis. «Uma conta VPN foi usada durante o incidente» pertence à segunda lista quando os registros sustentam isso. «A VPN causou o ransomware» não pertence a lugar nenhum até que algo estabeleça causalidade.