Capítulo 7 — Redes e protocolos
Mapa da aula
Aula 07 publicada. Mapa, exemplo, EX019.
flowchart TD
N0["7.1 DNS"]
N1["7.2 HTTP e HTTPS"]
N2["7.3 SMTP e cabeçalhos"]
N3["7.4 Portas e serviços"]
N4["7.5 Horários e endereços"]
N5["7.6 Resultados de autenticação na prática"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX019"]
Desenho lógico
flowchart LR
N0["7.1 DNS"]
N1["7.2 HTTP e HTTPS"]
N2["7.3 SMTP e cabeçalhos"]
N3["7.4 Portas e serviços"]
N4["7.5 Horários e endereços"]
N5["7.6 Resultados de autenticação na prática"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX019"]
[7.1 DNS]
|
v
[7.2 HTTP e HTTPS]
|
v
[7.3 SMTP e cabeçalhos]
|
v
[7.4 Portas e serviços]
|
v
[7.5 Horários e endereços]
|
v
[7.6 Resultados de autenticação na prática]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX019]
Objetivos de aprendizagem
Você vai (1) explicar DNS, HTTP(S) e SMTP no nível de que a CTI precisa; (2) ler cabeçalhos de e-mail em busca de pistas sobre o remetente; (3) entender por que o tráfego cifrado limita a visibilidade; (4) relacionar protocolos a técnicas do ATT&CK.
7.1 DNS
O Domain Name System associa nomes a endereços. Os logs do resolvedor registram qual dispositivo pediu qual nome e quando. Como quase toda conexão começa com uma consulta, o DNS é a fonte mais amplamente útil para conferir indicadores de domínio. Amara verifica por quanto tempo o HCHT guarda os logs do resolvedor e se eles registram o endereço interno do dispositivo ou só o endereço de um servidor de encaminhamento, o que esconderia qual estação de trabalho fez a consulta. Os dois fatos decidem se uma busca retrospectiva por um domínio do HSSC consegue encontrar o dispositivo que o contatou, e ambos ficam escritos em suas notas sobre cada fonte.
7.2 HTTP e HTTPS
O tráfego web carrega a maior parte da atividade dos usuários e muito tráfego malicioso de comando. A técnica Application Layer Protocol do ATT&CK (T1071) descreve adversários que se misturam ao tráfego normal de web, e-mail ou DNS. Com HTTPS, um proxy pode ver só o nome do servidor, não o caminho completo, a menos que o tráfego seja inspecionado — uma decisão com implicações jurídicas e de privacidade em um hospital. A equipe jurídica e de privacidade do HCHT decidiu que categorias de tráfego podem ser inspecionadas, e os sites de saúde usados pelos funcionários para cuidados pessoais ficam excluídos. Amara trabalha com o que o proxy registra sob essa decisão, em geral o nome do servidor e o horário, e anota quando um indicador não pode ser conferido porque só o caminho completo o revelaria.
7.3 SMTP e cabeçalhos
Os cabeçalhos de e-mail registram o caminho que a mensagem percorreu: as linhas Received, o remetente do envelope e os resultados de autenticação (SPF, DKIM, DMARC). Um nome de exibição dizendo "HCHT Payroll" não significa nada se a autenticação falha e o domínio remetente é um domínio sósia. Amara aprende a ler primeiro os resultados de autenticação, depois o domínio remetente e só então o nome de exibição, que é a parte mais fácil de um atacante falsificar. Ela compara os domínios sósias dos relatórios do HSSC com os domínios do próprio HCHT para ver que truques miram a instituição.
7.4 Portas e serviços
Portas ou protocolos incomuns podem sugerir tunelamento, mas muitos sistemas médicos legítimos também usam portas incomuns. O contexto dado pelos responsáveis pelos ativos vale mais que regras práticas. Amara pergunta à equipe de engenharia clínica que portas seus dispositivos usam antes de tratar qualquer porta incomum como suspeita. Uma lista de portas clínicas conhecidas, mantida junto com o inventário de ativos, evita alertas sobre o tráfego normal de imagem e deixa as anomalias reais se destacarem. Cada entrada registra o modelo do dispositivo e o responsável que a confirmou.
7.5 Horários e endereços
Os logs de rede registram horários em fusos diferentes e endereços que podem ser traduzidos por firewalls. Normalize os horários para UTC e anote a tradução de endereços antes de correlacionar com indicadores compartilhados. Amara descobriu que o proxy do HCHT registrava a hora local, enquanto os relatórios do HSSC usam UTC, o que fazia um contato parecer ter ocorrido uma hora antes da primeira observação do domínio. Depois da normalização, a ordem fez sentido. Agora ela registra o fuso horário e qualquer tradução de endereços de cada fonte de log em uma tabela curta, para que outros analistas possam correlacionar eventos sem redescobrir os mesmos problemas.
7.6 Resultados de autenticação na prática
O SPF verifica se o servidor remetente pode enviar pelo domínio do envelope; o DKIM verifica uma assinatura sobre a mensagem; o DMARC os vincula ao domínio visível no campo From e declara a política do titular. Uma mensagem pode passar no SPF de um domínio sósia que o atacante controla, então passar nas verificações prova apenas quem a enviou, não que o remetente seja benigno. Amara acrescenta isso à sua lista de verificação para relatos de phishing. Para cada mensagem de phishing relatada, ela registra os três resultados e se o domínio visível é do próprio HCHT, de um parceiro conhecido ou um sósia. Isso torna visível, ao longo do tempo, o padrão de falsificação.
Exemplo resolvido
Uma gerente de enfermaria encaminha um e-mail suspeito de "atualização salarial". Amara lê os cabeçalhos: o domínio no campo From é hcht-payrolI.example (I maiúsculo no lugar de l), o SPF passa para esse domínio sósia e o alinhamento DMARC falha em relação ao domínio real. Ela registra o sósia como indicador de phishing (T1566) e o compartilha com o HSSC em TLP:GREEN depois de remover o endereço da funcionária destinatária.
Caso sintético. O e-mail e os domínios são inventados.
Erros e limites
Cabeçalhos anteriores ao seu próprio gateway podem ser forjados. A inspeção de tráfego cifrado exige aprovação de política e aviso aos funcionários.
Exercícios
- EX019 — Veredito do cabeçalho. O SPF passa, mas o alinhamento DMARC falha em relação ao domínio real. O que isso diz a Amara? Rubrica: 3 = o remetente está autorizado para o sósia, não para o domínio real; falsificação/sósia; 2 = parcial; 1 = o e-mail é seguro; 0 = nenhuma.
- EX020 — Melhor fonte para domínios. Por que o DNS é a fonte mais útil para indicadores de domínio? Rubrica: 3 = quase todas as conexões começam com consultas; cobertura ampla; 2 = parcial; 1 = criptografia; 0 = nenhuma.
- EX021 — Limite do HTTPS. O que um proxy normalmente vê no tráfego HTTPS sem inspeção? Rubrica: 3 = nome do servidor (SNI)/destino, não o caminho nem o conteúdo; 2 = só o destino; 1 = tudo; 0 = nenhuma.
Síntese
Os logs de DNS, web e e-mail são os principais pontos de conferência do analista de CTI; leia os cabeçalhos com senso crítico e respeite os limites da visibilidade sobre o tráfego cifrado.
Continue estudando — capítulo 07 de 40
← Capítulo 06 (rascunho) · Índice de capítulos do curso · Capítulo 08 (rascunho) →