Capítulo 5 — Letramento em segurança
Mapa da aula
Aula 05 publicada. Mapa, exemplo, EX013.
flowchart TD
N0["5.1 Ataques comuns contra prefeituras e cidades"]
N1["5.2 Adivinhação de senhas"]
N2["5.3 Categorias de malware"]
N3["5.4 Persistência"]
N4["5.5 Comunicação de incidentes"]
N5["5.6 Somente defesa"]
N6["5.7 Usuários como sensores"]
N7["Serviços expostos"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX013"]
Desenho lógico
flowchart LR
N0["5.1 Ataques comuns contra prefeituras e cidades"]
N1["5.2 Adivinhação de senhas"]
N2["5.3 Categorias de malware"]
N3["5.4 Persistência"]
N4["5.5 Comunicação de incidentes"]
N5["5.6 Somente defesa"]
N6["5.7 Usuários como sensores"]
N7["Serviços expostos"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX013"]
[5.1 Ataques comuns contra prefeituras e cidades]
|
v
[5.2 Adivinhação de senhas]
|
v
[5.3 Categorias de malware]
|
v
[5.4 Persistência]
|
v
[5.5 Comunicação de incidentes]
|
v
[5.6 Somente defesa]
|
v
[5.7 Usuários como sensores]
|
v
[Serviços expostos]
|
v
[Exemplo resolvido] --> [Exercício EX013]
Objetivos de aprendizagem
Você vai (1) explicar ataques comuns contra pequenas organizações; (2) relacionar cada um à evidência que deixa; (3) entender as categorias de malware em nível conceitual; (4) relatar incidentes corretamente.
5.1 Ataques comuns contra prefeituras e cidades
Phishing, adivinhação de senhas contra serviços expostos, exploração de sistemas sem correção e ransomware. O MITRE ATT&CK cataloga esses comportamentos e as fontes de dados que podem revelá-los. Esses ataques são comuns porque são baratos: o phishing só precisa de endereços de e-mail, a adivinhação precisa de um serviço de logon exposto, e os sistemas sem correção aparecem em listas públicas. Uma prefeitura com centenas de funcionários e muitos serviços voltados ao público é um alvo atraente mesmo sem ter nada de incomum para roubar. Ataques de ransomware contra governos locais já interromperam alvarás, pagamentos e registros por semanas, e é por isso que a prontidão importa aqui.
5.2 Adivinhação de senhas
Logons malsucedidos repetidos, muitas vezes contra nomes de conta comuns como "admin", seguidos de sucesso se existir uma senha fraca. Evidência: logs de autenticação no alvo e logs de rede que mostram a origem. Os eventos do CLERK-03 se encaixam no padrão: três falhas para admin em poucos segundos e depois um sucesso. A velocidade é uma pista útil, porque pessoas erram a digitação em ritmo humano, enquanto a adivinhação automatizada é rápida e regular. Jonah também observa o nome da conta; uma conta genérica de administrador que ninguém usa no dia a dia é um alvo mais provável do que um usuário nominal.
5.3 Categorias de malware
Droppers instalam outros programas; ferramentas de acesso remoto dão controle; o ransomware cifra; os ladrões de informação coletam credenciais. Sikorski e Honig (2012) explicam como os analistas identificam esses comportamentos com segurança. Tecnólogos precisam reconhecer categorias, não construir nem executar amostras. Para um tecnólogo, a pergunta prática é qual evidência cada categoria pode deixar: um dropper deixa arquivos novos, uma ferramenta de acesso remoto deixa conexões de saída, o ransomware deixa arquivos renomeados ou ilegíveis, e um ladrão de informação pode deixar pouco além do tráfego de saída. O novo helper.exe no CLERK-03 é descrito por seu comportamento e sua localização, e não encaixado por palpite numa categoria antes que um analista o examine.
5.4 Persistência
O malware muitas vezes sobrevive a reinicializações instalando serviços, tarefas agendadas ou entradas de inicialização. A instalação do serviço no CLERK-03 se encaixa nesse padrão. Os mecanismos de persistência também dão aos investigadores um lugar onde procurar. Um serviço ou uma tarefa agendada tem um nome, um caminho, uma conta e um horário de criação, e esses registros duram mais do que a atividade do programa. No CLERK-03, o serviço foi instalado às 08:05:03 sob a conta admin, então tanto a lista de serviços quanto o log do sistema merecem ser preservados antes que alguém remova o serviço. Removê-lo cedo demais também alerta quem o instalou.
5.5 Comunicação de incidentes
Os funcionários comunicam suspeitas de incidente à central de serviços usando a categoria de segurança; não encaminham arquivos suspeitos por e-mail nem tentam "testá-los". Uma comunicação deve dizer o que foi visto, quando, em qual máquina e o que quem relata já fez até ali. A atendente que relatou o CLERK-03 descreveu a lentidão e as janelas que se abriam e o horário em que isso começou, o que bastou para a central de serviços encaminhar o chamado a Renata. Encaminhar um anexo suspeito o espalha e pode alterar seus metadados.
5.6 Somente defesa
O curso ensina a reconhecer e investigar; não inclui instruções de ataque. Na prática, isso significa que o curso descreve o malware pelo que ele faz e pelo que deixa, mostra amostras sintéticas apenas por seus nomes e hashes e nunca fornece código que explore ou burle o que quer que seja. O trabalho de Jonah fica do lado defensivo: preservar, coletar, entregar e ajudar a prefeitura a fechar as brechas que permitiram a intrusão. Quando um laboratório precisa de um arquivo suspeito, ele usa nomes inventados e hashes curtos inventados, como na comparação de listagens de diretórios.
5.7 Usuários como sensores
Funcionários que relatam cedo um comportamento estranho, como a usuária do CLERK-03, são valiosos; as comunicações devem ser bem recebidas. Em Alder Falls, a comunicação rápida da atendente deu a Renata a chance de capturar a memória antes de uma reinicialização. Uma cultura que culpa quem relata por ter clicado num link desestimula justamente essas ligações. Renata agradece a cada pessoa que relata, mesmo quando a causa se revela inofensiva, e registra a rapidez com que cada comunicação chegou, porque comunicações precoces encurtam as investigações. Os usuários também percebem coisas que nenhuma ferramenta mede, como uma janela que aparece e se fecha antes de qualquer alerta disparar.
Serviços expostos
A adivinhação de senhas só funciona contra serviços que aceitam logons. Jonah verifica quais sistemas da prefeitura aceitam logons remotos e a partir de onde: o CLERK-03 permitia área de trabalho remota a partir de toda a rede de escritório, uma configuração que ninguém se lembrava de ter ativado. Reduzir a exposição costuma ser a defesa mais simples.
Exemplo resolvido
Jonah associa os eventos do CLERK-03 a categorias: adivinhação de senha (logons malsucedidos), uso de conta válida (logon bem-sucedido de admin) e persistência (instalação de serviço). Ele lista a fonte de dados de cada um e registra que a finalidade do serviço ainda não é conhecida.
Caso sintético. A associação é inventada.
Erros e limites
Categorias são simplificações; ferramentas reais combinam funções, por isso confirme o comportamento a partir da evidência.
Exercícios
- EX013 — Evidência da adivinhação. Que evidência a adivinhação de senhas deixa? Rubrica: 3 = logons malsucedidos e depois bem-sucedidos; origem nos logs de rede; 2 = parcial; 1 = vago; 0 = nada.
- EX014 — Encaixe na persistência. Por que a instalação do serviço sugere persistência? Rubrica: 3 = serviços iniciam automaticamente, sobrevivem à reinicialização; 2 = parcial; 1 = velocidade; 0 = nada.
- EX015 — Comunicação pelos funcionários. Como os funcionários devem comunicar um arquivo suspeito? Rubrica: 3 = categoria de segurança da central de serviços; não encaminhar nem testar; 2 = parcial; 1 = enviá-lo por e-mail; 0 = nada.
Síntese
Reconheça os ataques pela evidência que deixam e comunique-os pelos canais adequados.
Continue estudando — capítulo 05 de 30
← Capítulo 04 (rascunho) · Índice de capítulos do curso · Capítulo 06 (rascunho) →