Alterações de DNS como indicadores de incidente
Durante um incidente cibernético, as alterações nos registros DNS podem ser tanto uma causa quanto um sintoma. Um registro MX alterado pode redirecionar o e-mail de entrada de uma organização para um servidor controlado por um invasor como parte de um comprometimento de e-mail comercial. Um registro NS ou A alterado pode ser um sinal de que uma conta de registrador de domínio foi comprometida e o invasor redirecionou o domínio completamente, às vezes para servir malware ou uma página de login falsa de uma infraestrutura que eles controlam. Em outros casos, a evidência DNS simplesmente ajuda a reconstruir qual infraestrutura estava em uso no momento do incidente, sem que o próprio DNS seja o vetor de ataque.
Construção de uma linha do tempo de DNS
Colete os registos DNS o mais cedo possível, uma vez que um incidente seja suspeito, pois os registos podem ser alterados de volta por um atacante ou corrigidos pelo administrador legítimo antes do início de uma investigação completa. Onde disponível, compare com qualquer instantâneo anterior que a própria organização tenha guardado, como um resultado de monitorização anterior ou um backup de configuração, para identificar especificamente quais os registos que foram alterados e aproximadamente quando, usando os valores de TTL do DNS e qualquer registo de alterações ou trilha de auditoria do registrador disponível como prova de suporte do cronograma.
Cruzar a cronologia do DNS com outras evidências de incidentes: cabeçalhos de e-mail mostrando quando o e-mail começou a chegar a um servidor diferente, logs de transparência de certificados mostrando quando um novo certificado foi emitido para o domínio, e logs de servidor ou aplicação mostrando quando os padrões de tráfego mudaram. A evidência DNS é mais útil quando corrobora, ou entra em conflito, com estas outras fontes, em vez de ser usada isoladamente.
Evidência ao nível do registador e do registo
Além dos próprios registos DNS, os dados de registo RDAP podem mostrar se o registrador do domínio, os servidores de nomes ou o contato do registrante mudaram aproximadamente na mesma altura, o que apontaria para um comprometimento ao nível da conta no registrador, em vez de um problema limitado a um único ficheiro de zona DNS. Códigos de status como "clientTransferProhibited" a serem removidos pouco antes de uma transferência não autorizada é um padrão específico que vale a pena verificar nos dados do registo.
Documentar para resposta e recuperação
Registar cada observação DNS e RDAP com o seu carimbo de data/hora e fonte como parte do registo de incidentes, uma vez que esta prova muitas vezes precisa de ser partilhada com o registador, o provedor de alojamento, as autoridades policiais ou um provedor de seguros cibernéticos, cada um dos quais pode pedir detalhes sobre o que exatamente mudou e quando. A restauração de registos corretos é um passo de resposta operacional e deve ser documentada separadamente da recolha de provas de quais eram os registos incorretos.
- Capturar registos DNS e RDAP atuais imediatamente após suspeita de um incidente.
- Compare com qualquer instantâneo salvo anteriormente para isolar o que mudou.
- Cruzamento com cabeçalhos de e-mail, emissão de certificados e registos de servidor.
- Verifique os códigos de status a nível de registrador e as alterações de contato, não apenas os registos DNS.
- Mantenha a recolha de provas separada das etapas de remediação.