NexaCorp DFIR: INC-2026-001 - Compromisso de Infraestrutura Linux

Investigação DFIR e engenharia de deteção numa intrusão simulada contra a infraestrutura da NexaCorp. Realizada como um envolvimento individual de 4 dias (bootcamp Blue & Red Team da BeCode Brussels, Missão 01). O entregável é um relatório de descobertas de 54 páginas (PDF) mais 7 regras Suricata validadas que detetam o incidente capturado em replay de PCAP.

Este repositório documenta um envolvimento de analista SOC realizado como parte do BeCode Cybersecurity Bootcamp (promoção 2025-2026). Reconstrói uma intrusão completa a partir de evidências de rede e logs, e depois entrega um conjunto validado de regras de deteção Suricata. É o primeiro incidente na série NexaCorp DFIR.

Contents

• Aviso operacional
• Num relance
• Contexto do envolvimento
• Sumário executivo
• Sumário da cadeia de ataque
• Como ler este relatório
• Metodologia
• Ferramentas utilizadas
• Resumo das descobertas
• Engenharia de deteção
• Estrutura do repositório
• Reprodutibilidade
• Limitações conhecidas
• Série NexaCorp DFIR
• Agradecimentos
• Sobre
• Licença

Aviso operacional

Este é um envolvimento de laboratório contra infraestrutura fictícia. A NexaCorp é um cliente fictício usado como cenário para a Missão 01 da BeCode Brussels. O host comprometido é uma VM Metasploitable 2 intencionalmente vulnerável para treino de segurança, e o implante Caldera Sandcat faz parte do laboratório que ensina ao analista como é o tráfego de beacon de um intruso real. Nenhuma organização, rede ou pessoa real foi atacada.

Todos os endereços IP, nomes de host e indicadores de compromisso publicados neste relatório (172.16.50.10, 192.168.10.10, 10.40.0.200, blue11, mesdec, etc.) são artefatos locais de laboratório, não inteligência de ameaças do mundo real. Não os introduza num SIEM como IOCs.

Publicação autorizada pelo coach de laboratório da BeCode (Thomas B.) em 2026-05-17. A declaração de confidencialidade completa aparece no relatório de descobertas (secção "Distribuição e Classificação").

Num relance

Contexto do envolvimento

Cenário (ficcional). A NexaCorp, um cliente corporativo de médio porte, contactou a equipa blue da BeCode Corp após a sua monitorização interna sinalizar tráfego de saída inesperado de um dos seus servidores Linux internos. O firewall registou o tráfego mas não levantou nenhum alerta acionável. O conselho precisava de uma determinação antes de decidir sobre divulgação e notificação regulatória.

Mandato. Investigar a janela do incidente suspeito, caracterizar o caminho de entrada do atacante e a atividade pós-exploração, avaliar o que a pilha de deteção existente capturou (e perdeu), e entregar um plano de remediação priorizado. Uma segunda fase adicionou engenharia de deteção: produzir regras de IDS de rede prontas para implementar que detetassem uma recorrência em tempo real.

Pacote de evidências recebido do cliente.

Contexto educativo. Este envolvimento foi realizado durante o bootcamp Blue & Red Team da BeCode Brussels (novembro de 2025 a setembro de 2026) como Missão 01: uma investigação individual com tempo limitado simulando um verdadeiro envolvimento de consultoria DFIR. A infraestrutura de laboratório, a identidade NexaCorp e os valores IOC são deliberadamente ficcionais. A metodologia, ferramentas e formato do relatório seguem padrões do mundo real (NIST SP 800-61r2, SANS PICERL, MITRE ATT&CK).

Sumário executivo

📄 O relatório de descobertas completo de 54 páginas é o entregável canónico. Descarregue o PDF (215 KB) ou navegue pelo fonte Markdown para grep/citação.

Na noite de 2026-05-09 às 22:53 UTC, um atacante externo (172.16.50.10) comprometeu um servidor interno da NexaCorp (192.168.10.10) explorando CVE-2011-2523, a backdoor presente no vsftpd 2.3.4 (uma versão que está documentada publicamente como comprometida desde julho de 2011). Um único pedido FTP USER terminando com :) desencadeou uma shell root não autenticada no TCP/6200. O atacante executou 8 comandos de reconhecimento durante uma sessão de 20 segundos (sem persistência, sem exfiltração, sem movimento lateral através deste vetor de acesso) e desligou.

Independentemente, o mesmo host foi encontrado a executar um agente MITRE Caldera "Sandcat" pré-existente em /opt/caldera/sandcat (root, daemonizado) a fazer beacon a cada 40-50 segundos em HTTP claro para 10.40.0.200:8888 durante toda a janela capturada. Esta é a "conexão de saída incomum" originalmente sinalizada pelo cliente e indica um compromisso anterior não representado no pacote de evidências (o implante já estava ativo no primeiro frame PCAP).

O Wazuh SIEM existente ingeriu 397 eventos do host alvo mas levantou apenas 4 alertas de alta severidade (1.0% do total), todos classificados como brute-force genérico (MITRE T1110). Nenhum identificou o payload de exploração CVE-2011-2523, a shell bind no TCP/6200, ou o canal C2 Caldera: o byte de exploração (USER baduser:)) nunca é registado pelo próprio vsftpd, e o SIEM não tinha telemetria de rede para ver o resto. As 7 regras Suricata entregues na Fase 2 fecham todas as três lacunas.

IOCs principais (apenas laboratório, não introduza num SIEM real):

Sumário da cadeia de ataque

O incidente capturado tem dois fios distintos, reconstruídos a partir do PCAP:

1. Serviço exposto: vsftpd 2.3.4, uma versão com uma backdoor documentada publicamente (CVE-2011-2523), estava acessível na rede interna (Descoberta I1).
2. Exploit: um único pedido FTP USER terminando com :) ativou a backdoor (Descoberta I3).
3. Shell root bind: uma shell root não autenticada abriu no TCP/6200; o atacante executou 8 comandos de reconhecimento durante uma sessão de 20 segundos, depois desligou, sem persistência ou exfiltração através deste vetor (Descoberta I4).
4. C2 paralelo (pré-existente): independentemente, um implante MITRE Caldera Sandcat já estava a fazer beacon em HTTP claro para 10.40.0.200:8888 durante toda a janela, evidência de um compromisso anterior não representado no pacote de evidências (Descoberta I5).

Como ler este relatório

O repositório está organizado para que possa mergulhar na profundidade certa para o seu papel:

Entregável canónico: o PDF em reports/. O fonte Markdown tem conteúdo idêntico, mantido no repositório para pesquisa e controlo de versões.

Rasto da investigação: notes/journal.md é o bloco de notas de trabalho do analista (hipóteses testadas e refutadas, inventário de evidências, estado do plano). Complementa o relatório formal mostrando como as conclusões foram alcançadas, não apenas as conclusões em si.

Conjunto de regras de deteção: detection/lab.rules contém as 7 regras Suricata com justificação completa por palavra-chave em comentários inline. detection/README.md documenta o fluxo de trabalho de validação de implementar-e-replay usado para confirmar que cada regra dispara no incidente capturado.

Metodologia

O envolvimento segue três estruturas padrão da indústria sobrepostas.

NIST SP 800-61r2: Guia de Tratamento de Incidentes de Segurança Informática

O modelo de 4 fases do NIST (Preparação, Deteção & Análise, Contenção / Erradicação / Recuperação, Atividade Pós-Incidente) fornece a estrutura de alto nível. Neste envolvimento, a Fase 1 do entregável corresponde ao "Deteção & Análise" do NIST (forense de PCAP, correlação SIEM, reconstrução da linha temporal do atacante). A Fase 2 corresponde às "Lições Aprendidas" do NIST traduzidas em controlos preventivos (as 7 regras Suricata e a lista de recomendações priorizada na secção 7 do relatório).

SANS PICERL: fluxo de investigação tático

PICERL (Preparação, Identificação, Contenção, Erradicação, Recuperação, Lições Aprendidas) é o Processo de Resposta a Incidentes SANS. Aplicado neste envolvimento:

MITRE ATT&CK: mapeamento de técnicas

Cada descoberta é mapeada a uma ou mais técnicas MITRE ATT&CK para permitir ao cliente correlacionar este incidente com o seu modelo de ameaças existente. 14 técnicas distintas são referenciadas nas 10 descobertas:

• Reconhecimento: T1595.002, T1592.002, T1589
• Acesso Inicial: T1190 (Explorar Aplicação Pública via CVE-2011-2523)
• Execução: T1059.004 (Shell Unix)
• Descoberta: T1033, T1082, T1087.001, T1083, T1016, T1049, T1046
• Acesso a Credenciais: T1110 (Força Bruta)
• Comando e Controlo: T1071.001, T1102 (beacon Caldera Sandcat)
• Escalação de Privilégios: T1078.003, T1548.003 (atividade sudo suspeita)

A tabela completa de técnicas por descoberta está na secção 4 do relatório (IOCs) e as análises aprofundadas por descoberta nas secções 3 e 5.

Reprodutibilidade

Cada afirmação no relatório é rastreável a um artefacto no pacote de evidências, com o filtro tshark exato, consulta Wazuh, ou comando de replay Suricata necessários para a reproduzir. Consulte o Anexo A (Comandos de reprodutibilidade) no relatório e a secção de Reprodutibilidade abaixo para um início rápido.

Ferramentas utilizadas

Forense de rede

• tshark: Wireshark CLI para triagem de PCAP, reconstrução de stream TCP (-z follow,tcp,ascii), filtragem de protocolo e extração de campos
• tcpreplay e tcprewrite: replay PCAP para uma interface de monitorização ao vivo para validação de regras Suricata, com ajuste de MTU para caber no ens19 do laboratório (1450 bytes)
• Descodificadores Base64: reconstruir payloads C2 do Caldera Sandcat (corpo do beacon e resposta do operador)

IDS de rede / engenharia de deteção

• Suricata 6.0.4 (modo afpacket, single-thread, Hyperscan desativado no laboratório): criou, validou e afinou as 7 regras neste entregável
• suricata -T: validação de config e regras durante a implementação e afinação
• kill -USR2 $(pgrep suricata): recarregamento de regras ao vivo durante a afinação iterativa

SIEM e telemetria de host

• Wazuh (manager + dashboard): correlação de eventos, análise de distribuição de severidade, consulta de regras (rule.id 11452, 5551, etc.), exportação CSV de 397 eventos
• Utilitários de texto Linux padrão (grep, awk, jq): mineração de logs e parsing JSON

Contexto de emulação de adversário (referenciado, não operado)

• MITRE Caldera (agente Sandcat): presente no host alvo como o implante C2 pré-existente simulado a ser caracterizado

Estruturas de referência

• NIST SP 800-61r2: Guia de Tratamento de Incidentes de Segurança Informática
• SANS PICERL: fluxo de investigação tático
• MITRE ATT&CK: atribuição de técnicas
• Advertência CVE-2011-2523: referência da backdoor vsftpd 2.3.4

Resumo das descobertas

As 10 descobertas (I1 a I10) estão documentadas em detalhe no relatório de descobertas. Cada entrada inclui evidências, comandos de reprodutibilidade, mapeamento MITRE ATT&CK e orientação de remediação.

Distribuição de severidade: 3 CRÍTICOS / 3 ALTOS / 2 MÉDIOS / 2 BAIXOS

Recomendação de ordem de leitura: comece com I1 (o serviço vulnerável), depois I3 e I4 (a cadeia de exploração real), depois I5 (o implante C2 paralelo, não relacionado). I2 e I6 fornecem o contexto de reconhecimento. I7 a I10 são as descobertas de postura defensiva (o que a monitorização viu vs perdeu).

Engenharia de deteção

A Fase 2 do envolvimento produziu 7 regras Suricata (SID 9000001 a 9000007) cobrindo o incidente capturado em três ângulos: a assinatura do exploit, a shell pós-exploit e o canal C2 paralelo. Cada regra é validada por replay offline de PCAP contra uma instância Suricata 6.0.4 na estação de trabalho SOC.

As 7 regras

Resumo de validação

A diferença entre 40 e 314 reflete uma limitação deliberada nas regras 9000003, 9000004, 9000005, 9000006 para dar aos analistas SOC uma visão operacional limpa enquanto preserva o fluxo de alertas brutos em eve.json para análises forenses aprofundadas.

Decisões de design notáveis

Quatro correções iterativas durante a implementação estão documentadas em detection/README.md. Lições principais:1. Detecção HTTP independente de porta. As regras 9000004 e 9000005 (Caldera) foram inicialmente escritas com as palavras‑chave alert http e http.uri, que só ativam o analisador HTTP do Suricata na porta 80. O Caldera C2 é executado na porta 8888, portanto o analisador foi ignorado e as regras nunca dispararam. Correção: reescrita em modo TCP+conteúdo (alert tcp ... content:"POST /beacon"; content:"Go-http-client/1.1";) que corresponde aos bytes HTTP brutos independentemente da porta. 2. flow:established não confiável durante a repetição de PCAP. Um handshake TCP capturado fora da janela de repetição deixa a máquina de estado do fluxo num estado indeterminado. Remover flow:established das regras Caldera faz com que elas correspondam tanto em modo ao vivo quanto em repetição. 3. Direção de fluxo explícita para regras SYN-only. A regra 9000003 (porta 6200) levantou SC_WARN_POOR_RULE: SYN-only ... w/o direction specified. Corrigido adicionando flow:to_server,not_established. 4. HOME_NET vs em laboratórios apenas RFC1918. Quando atacante, alvo e C2 estão todos no espaço privado, fica vazio e regras da forma nunca correspondem. Correção em laboratório: usar em ambos. Correção em produção: restringir apenas ao segmento protegido.

Considerações sobre falsos positivos

A análise de falsos positivos por regra está documentada na seção 8.5 do relatório. A maioria das regras apresenta risco insignificante num ambiente bem dimensionado; as regras 9000005 (cabeçalho do servidor aiohttp) e 9000006 (curl/Wget em caminhos administrativos) exigem ajustes se houver serviços Python internos benignos ou scripting administrativo.

Layout do repositório```text

NexaCorp-DFIR-INC-2026-001/ ├── README.md (this file) ├── LICENSE (MIT) ├── .gitignore ├── .github/ │ └── workflows/ │ └── ci.yml markdownlint + typography + Suricata rule check ├── reports/ │ ├── INC-2026-001_Findings_Report.pdf canonical 54-page deliverable │ └── INC-2026-001_Findings_Report.md same content, Markdown source ├── detection/ │ ├── lab.rules 7 Suricata rules (SID 9000001-9000007) │ └── README.md deploy + replay validation workflow ├── evidence-summary/ │ └── ioc-summary.md indicators of compromise (SIEM-ingestible) ├── methodology/ │ ├── attack-timeline.md incident timeline (UTC) │ └── attck-mapping.md MITRE ATT&CK mapping table └── notes/ └── journal.md analyst investigation journal (hypotheses, plan, IOCs, timeline)

**Classificações de ficheiros:**

| Caminho | Função | Público-alvo |
|---|---|---|
| `reports/*.pdf` | Entregável canónico, relatório formal | Cliente, recrutador, auditor |
| `reports/*.md` | Mesmo conteúdo, fonte compatível com grep | Qualquer pessoa que cite ou faça diff |
| `detection/lab.rules` | Conjunto de regras Suricata pronto para produção | SOC / engenheiro de deteção |
| `detection/README.md` | Guia de implementação e validação de reprodução | Integração de engenheiro de deteção |
| `evidence-summary/ioc-summary.md` | Indicadores de compromisso, por categoria | SOC / caça a ameaças |
| `methodology/attack-timeline.md` | Linha temporal do incidente (UTC) | Profissional de DFIR |
| `methodology/attck-mapping.md` | Tabela de mapeamento MITRE ATT&CK | DFIR / engenheiro de deteção |
| `notes/journal.md` | Caderno de trabalho de investigação | Profissional de DFIR a estudar o método |
| `.github/workflows/ci.yml` | Validação automatizada de markdownlint, tipografia e regras Suricata (`suricata -T`, executado quando `detection/*.rules` está presente) no push | CI |

## Reprodutibilidade

Cada alegação no relatório de conclusões é rastreável a um artefacto no pacote de evidências. O PCAP em si não é redistribuído (propriedade do laboratório BeCode), mas os comandos e consultas estão documentados para que qualquer pessoa com a sua própria cópia possa reproduzir a análise.

### Reproduzir conclusões principais (análise PCAP)

Requer `tshark` (CLI do Wireshark) e o `attack.pcap` original:```bash
# 1. PCAP overview
tshark -r attack.pcap -q -z io,stat,0

# 2. TCP conversations (reveals attacker, target, C2)
tshark -r attack.pcap -q -z conv,tcp | head -30

# 3. Confirm vsftpd 2.3.4 banner exposure (Finding I1)
tshark -r attack.pcap -Y "ftp && ip.src == 192.168.10.10" \
  -T fields -e frame.time -e ftp.response.code -e ftp.response.arg | head -5

# 4. Find the CVE-2011-2523 exploit payload (Finding I3)
tshark -r attack.pcap -Y 'ftp.request.command == "USER"' \
  -T fields -e frame.time -e ftp.request.arg

# 5. Reconstruct the root shell session on TCP/6200 (Finding I4)
tshark -r attack.pcap -q -z follow,tcp,ascii,70

# 6. Reconstruct the Caldera C2 beacon (Finding I5)
tshark -r attack.pcap -q -z follow,tcp,ascii,6 | head -50

Reproduzir validação de regras (Suricata replay)

Requer Suricata 6.0.x, tcpreplay, e uma interface monitorada (ens19 no laboratório; substitua pela sua):```bash

1. Install the ruleset

sudo cp detection/lab.rules /etc/suricata/rules/learner/lab.rules

2. Hot-reload Suricata without restart

sudo kill -USR2 $(pgrep -f suricata) sleep 5

3. Clear the alert log for a clean baseline

sudo truncate -s 0 /var/log/suricata/fast.log

4. Replay the PCAP at top speed

sudo tcpreplay --intf1=ens19 --topspeed attack_mtu.pcap

5. Count alerts per rule (expect 7 distinct SIDs)

sudo grep -oE '[1:[0-9]+:' /var/log/suricata/fast.log | sort | uniq -c | sort -rn

Saída esperada (após uma repetição completa):```text
     30 [1:9000002:    (vsftpd banner repeated per session)
      3 [1:9000007:    (FTP USER enumeration threshold)
      3 [1:9000006:    (HTTP admin path enumeration)
      1 [1:9000005:    (Caldera C2 response)
      1 [1:9000004:    (Caldera Sandcat beacon, throttled)
      1 [1:9000003:    (Backdoor port 6200 SYN)
      1 [1:9000001:    (vsftpd USER smiley exploit)

7/7 regras disparam corretamente. O pacote completo de evidências (fast.log, eve.json, configuração de throttling, snapshot da versão do Suricata) está enumerado no Anexo E do relatório de conclusões.

Limitações conhecidas

• Pacote de evidências começa no meio do incidente. O PCAP começa em 2026-05-09 20:08 UTC, mas o agente Caldera Sandcat já está ativamente fazendo beaconing no frame 1. O comprometimento inicial que instalou o implante ocorreu antes e não está representado nos dados. Conclusões sobre atividade pré-implante são extrapoladas dos campos full_log do Wazuh, não observadas diretamente.
• Os logs de auditoria do host não coincidem com a janela do ataque. Os auth.log e syslog locais começam ~5 horas após o término do PCAP, com a primeira entrada sendo syslogd restart (provavelmente reinicialização da VM). Nenhum arquivo de log rotacionado foi fornecido. Isso está documentado como Achado I10.
• O escopo foi engenharia forense + detecção, não resposta ao vivo. Contenção, erradicação, aquisição forense (imagem de memória, imagem de disco) e enumeração de persistência estão documentados como recomendações P0 no relatório, mas não foram executados: o engajamento não tinha acesso ao host ao vivo. Um engajamento de acompanhamento seria necessário para fechar esses loops.
• As 7 regras do Suricata detectam esta assinatura específica do incidente. Um atacante sofisticado pode evitá-las alterando o padrão de bytes do exploit (terminadores de byte nulo alternativos no argumento USER), recompilando o Caldera com um User-Agent diferente, ou movendo o C2 para HTTPS criptografado (a análise de metadados TLS como JA3/JA4 seria o fallback). As regras são apropriadas para o cenário de ameaça capturado; a estratégia de detecção de longo prazo deve adicionar detecções comportamentais e baseadas em metadados.
• Lacuna de ingestão do Wazuh durante a investigação. O pipeline de ingestão de logs do SIEM ficou temporariamente indisponível até 2026-05-11 11:39 UTC (no meio da investigação, restaurado pelo coach do laboratório). Os 4 alertas de alta gravidade aparecem no painel com carimbos de tempo de ingestão (11 de maio 13:17-13:28) em vez dos carimbos de tempo reais do incidente (9 de maio 21:00-22:53), o que distorce o tempo aparente dos eventos de correlação.

Série DFIR NexaCorp

• INC-2026-001: este repositório
• INC-2026-002: escalonamento de privilégios e persistência (Tor SSH, SUID, conta backdoor)
• INC-2026-003: avaliação cruzada de incidentes do mês 1
• INC-2026-004: injeção SQL (portal web)
• INC-2026-005: injeção de comandos do SO e web shell (portal web)
• INC-2026-006: XSS armazenado e sequestro de sessão (portal web)
• INC-2026-007: IDOR e controle de acesso quebrado (NexaPortal); marco do Mês 2
• INC-2026-008: reconhecimento de AD e Kerberoasting (primeiro incidente do Mês 3)

Agradecimentos

• Thomas B. (coach do laboratório BeCode): design do cenário, correção da ingestão do Wazuh durante a investigação, autorização de publicação para uso no portfólio.
• MITRE pela estrutura Caldera que alimentou o implante C2 simulado, e pela base de conhecimento ATT&CK usada para mapear cada achado.
• Projeto Suricata pelo motor que tornou as 7 regras implantáveis em menos de 30 minutos.

Sobre

Engajamento solo de DFIR entregue durante o bootcamp Blue & Red Team da BeCode Brussels (Novembro de 2025 a Setembro de 2026), Missão 01, em 2026-05-15.

Autor: Johan-Emmanuel Hatchi (LinkedIn).

Aberto a oportunidades de estágio em cibersegurança a partir de Setembro de 2026 na Bélgica. Procurando funções em SOC / DFIR / engenharia de detecção onde este tipo de trabalho de investigação ponta a ponta (forense de PCAP, correlação SIEM, escrita de regras IDS, relatórios formais para clientes) esteja no escopo.

Licença

MIT, 2026 Johan-Emmanuel Hatchi.

As regras Suricata em detection/lab.rules e o texto do relatório são ambos lançados sob a mesma licença MIT: livre para copiar, adaptar e redistribuir com atribuição. O PCAP, a infraestrutura do laboratório e os briefings do engajamento permanecem propriedade da BeCode Brussels e não são redistribuídos.