# Hunting - Supply Chain Compromise > [!warning] Aviso Importante > Este playbook é um ponto de partida. Deve ser revisado, testado e adaptado ao ambiente da sua organização. Não substitui um plano formal de Incident Response. Queries marcadas com `# [VALIDAR NO SEU AMBIENTE]` requerem ajuste antes do uso em produção. --- ## Visão Geral O compromisso de cadeia de suprimentos de software (*supply chain compromise*) é uma das formas mais sofisticadas de intrusão conhecidas. O atacante não invade o alvo diretamente — ele compromete um fornecedor, biblioteca ou ferramenta de desenvolvimento confiável, e o malware chega junto com uma atualização legítima e assinada digitalmente. Os dois casos mais estudados definem o modelo de ameaça moderno: - **[[solarwinds-supply-chain-attack]]** (2020): O grupo [[g0016-apt29]] injetou o backdoor [[s0559-sunburst]] nas builds do SolarWinds Orion, distribuindo o implante para mais de 18.000 organizações. O SUNBURST permanecia dormente por 12-14 dias, verificava a presença de ferramentas de segurança, e só então iniciava balizamento DNS codificado para `avsvmcloud.com`. - **XZ Utils / CVE-2024-3094** (2024): Um agente de ameaça operou por mais de dois anos como mantenedor legítimo do projeto open source XZ Utils, inserindo um backdoor no processo de build que comprometia a autenticação SSH em distribuições Linux específicas (Debian/Fedora). A ativação era condicional - o payload só executava em builds específicas, tornando a detecção extremamente difícil. Ambos exploram a confiança implícita em software verificado e assinado. O hunting eficaz requer sair de assinaturas e olhar para **comportamento anômalo de processos confiáveis**. **Técnicas MITRE relevantes:** [[t1195-002-supply-chain-compromise|T1195.002 — Supply Chain Compromise]], [[t1027-obfuscated-files|T1027 — Obfuscated Files]], [[t1105-ingress-tool-transfer|T1105 — Ingress Tool Transfer]], [[t1574-002-dll-side-loading|T1574.002 — DLL Side-Loading]] **Fontes de inteligência:** [[solarwinds-supply-chain-attack]], [[s0559-sunburst]], [[g0016-apt29]] --- ## Fluxo de Hunting ```mermaid flowchart TD A([🔍 Iniciar Hunting<br/>Supply Chain]) --> B[Verificar Inventário<br/>de Software Instalado] B --> C{Software com\nVulnerabilidade Conhecida?} C -->|Sim| D[H6: Verificar Versão<br/>Contra Baseline] C -->|Não| E[Prosseguir com<br/>Hipóteses Comportamentais] D --> F{Versão\nComprometida?} F -->|Sim| G[🚨 ESCALAR PARA IR<br/>IMEDIATAMENTE] F -->|Não| E E --> H[H3: Verificar DLLs<br/>e Libs Modificadas] H --> I[H1: Processos Filhos<br/>Incomuns de Atualizadores] I --> J[H2: Conexões de Rede<br/>Incomuns de Updaters] J --> K[H4: Persistência<br/>Criada Pós-Instalação] K --> L[H5: Beaconing Periódico<br/>de Processos Confiáveis] L --> M[H7: Reconhecimento<br/>Pós-Dormência] M --> N{Alguma Hipótese\nTrue Positive?} N -->|Sim — critério crítico| G N -->|Sim — menor gravidade| O[Investigação<br/>Aprofundada] N -->|Não| P[Documentar Hunting<br/>e Retornar em 7 dias] O --> Q{Evidência\nAdicional?} Q -->|Sim| G Q -->|Não| P style A fill:#6600cc,color:#fff style G fill:#ff0000,color:#fff style P fill:#00aa44,color:#fff ``` --- ## Ferramentas Recomendadas ### Hunting de Software e Inventário | Ferramenta | Uso | Comando | |------------|-----|---------| | **Velociraptor** | Inventário de software e verificação de hash em escala | `velociraptor artifacts collect Generic.Applications.Inventory` | | **Osquery** | Inventário de pacotes instalados em Linux/Mac/Windows | `SELECT * FROM programs WHERE name LIKE '%xz%';` | | **KAPE** | Coleta de artefatos de software instalado | Target: `!SANS_Triage` | | **Sysinternals Sigcheck** | Verificar assinaturas de binários e DLLs | `sigcheck.exe -u -e C:\Program Files\SolarWinds\` | | **PEStudio** | Análise estática de binários PE suspeitos | Carregar DLL/EXE suspeito para análise | ### Análise de Código e Dependências | Ferramenta | Uso | |------------|-----| | **Trivy** | Scan de vulnerabilidades em containers e dependências | `trivy fs /app --security-checks vuln` | | **Snyk** | Análise de dependências maliciosas ou comprometidas | `snyk test --all-projects` | | **OSSF Scorecard** | Avaliar postura de segurança de projetos open source | `scorecard --repo=github.com/org/repo` | | **socket.dev** | Detectar pacotes npm/PyPI maliciosos | Integrar ao pipeline CI/CD | ### Análise de Comportamento | Ferramenta | Uso | |------------|-----| | **Chainsaw** | Análise rápida de Windows Event Logs com regras Sigma | `chainsaw hunt evtx/ --rules sigma/ --sigma-mapping mapping.yml` | | **Hayabusa** | Detecção de ameaças em Event Logs | `hayabusa.exe -d evtx/ -r rules/ -o results.csv` | | **PE-sieve** | Detectar injeções de código em processos em execução | `pe-sieve.exe /pid [PID] /dir output\` | | **Volatility 3** | Análise forense de memória - DLLs injetadas | `python3 vol.py -f mem.raw windows.malfind` | ### Threat Intelligence | Ferramenta | Uso | |------------|-----| | **MISP** | Feed de IoCs para supply chain attacks - CIRCL | | **VirusTotal** | Verificar hashes de software instalado | | **CISA Advisory DB** | Monitorar advisories de supply chain attacks | --- ## Gantt de Hunting (Ciclo Semanal) ```mermaid gantt title Ciclo de Hunting Supply Chain (Semanal) dateFormat YYYY-MM-DD section Segunda H6: Verificar versões instaladas vs baseline :2026-03-23, 1d H3: Verificar DLLs e libs modificadas :2026-03-23, 1d section Terça H1: Processos filhos incomuns de atualizadores :2026-03-24, 1d H2: Conexões de rede incomuns de updaters :2026-03-24, 1d section Quarta H4: Persistência criada pós-instalação :2026-03-25, 1d H5: Beaconing periódico de processos confiáveis :2026-03-25, 1d section Quinta H7: Reconhecimento pós-dormência :2026-03-26, 1d Correlação de todos os achados :2026-03-26, 1d section Sexta Documentar hipóteses e atualizar detections :2026-03-27, 1d Relatório de hunting semanal :2026-03-27, 1d ``` --- ## Checklist de Hunting ### Preparação - [ ] Confirmar inventário completo de software de terceiros instalado (CMDB) - [ ] Estabelecer baseline de versões aprovadas de softwares críticos - [ ] Confirmar disponibilidade de Sysmon com eventos 1, 3, 7 habilitados - [ ] Confirmar retenção de logs de processo mínima de 90 dias - [ ] Identificar softwares com histórico de supply chain attacks (SolarWinds, 3CX, etc.) ### Execução das Hipóteses - [ ] H3 - Verificar DLLs e bibliotecas modificadas por processos de baixa integridade - [ ] H6 - Verificar versões instaladas contra baseline (prioridade máxima) - [ ] H1 - Processos filhos suspeitos de atualizadores/instaladores - [ ] H4 - Persistência criada dentro de 90 minutos após execução de instalador - [ ] H7 - Reconhecimento de AD originado de processo de software de terceiro - [ ] H2 - Conexões de rede incomuns originadas de processos de atualização - [ ] H5 - Beaconing DNS com baixo jitter de processos confiáveis ### Documentação - [ ] Registrar cada hipótese: resultado (TP/FP/Inconclusivo), evidências, ação tomada - [ ] Escalar True Positives críticos para IR imediatamente - [ ] Atualizar baseline de software aprovado com novas versões válidadas - [ ] Adicionar FPs identificados à whitelist de queries --- ## Referências de Caça - [[t1195-002-supply-chain-compromise|T1195.002 - Supply Chain Compromise]] - técnica MITRE ATT&CK principal - [[t1105-ingress-tool-transfer|T1105 - Ingress Tool Transfer]] - transferência de payload pós-comprometimento - [[t1027-obfuscated-files|T1027 - Obfuscated Files]] - ofuscação usada no SUNBURST e XZ Utils - [[t1574-002-dll-side-loading|T1574.002 - DLL Side-Loading]] - mecanismo de injeção via biblioteca legítima - [[solarwinds-supply-chain-attack]] - caso de referência principal - [[s0559-sunburst]] - análise do implante do caso SolarWinds - [[g0016-apt29]] - grupo responsável pelo ataque SolarWinds - [[ir-supply-chain-attack]] - playbook de IR para supply chain confirmado - [[hunting-lateral-movement]] - hunting complementar - [CISA Advisory AA20-352A - SUNBURST Detection](https://www.cisa.gov/news-events/cybersecurity-advisories/aa20-352a) - [NIST SP 800-161r1 - Cybersecurity Supply Chain Risk Management](https://csrc.nist.gov/publications/detail/sp/800-161/rev-1/final) - [[t1195-002-compromise-software-supply-chain|MITRE ATT&CK - Supply Chain Compromise]] --- *Última revisão: 2026-03-23 | Próxima revisão recomendada: 2026-09-23* --- ## Hipóteses de Hunting > [!info] Como usar as hipóteses > Cada hipótese é uma declaração testável. Execute a query correspondente no seu SIEM, análise os resultados e aplique os critérios de verdadeiro/falso positivo antes de escalar. --- ### H1: Softwares legítimos estão executando processos filhos incomuns **Hipótese:** Instaladores, updaters e binários de software confiável estão gerando processos filhos (cmd.exe, powershell.exe, sh.exe) que não são esperados no ciclo de vida normal da aplicação. Esse padrão foi central no SUNBURST, onde o SolarWinds.BusinessLayerHost.exe gerava processos de reconhecimento. **Indicadores de verdadeiro positivo:** - Instalador/updater gerando `cmd.exe` ou `powershell.exe` sem interação do usuário - Processo filho sendo criado a partir de diretório temporário (`%TEMP%`, `/tmp`) - Binário filho não assinado ou com assinatura diferente do pai **Indicadores de falso positivo:** - Instaladores legítimos que invocam scripts pós-instalação (ex: Chocolatey, Ansible) - Ferramentas de gerenciamento de configuração (ex: Chef, Puppet) - Atualizações de software que executam migrações de banco de dados via CLI **Splunk SPL:** ```splunk index=wineventlog sourcetype=xmlwineventlog:Microsoft-Windows-Sysmon/Operational EventCode=1 (parent_process_name IN ("msiexec.exe", "setup.exe", "updaté.exe", "softwareupdated") OR parent_image="*\\installer\\*") AND (process_name IN ("cmd.exe", "powershell.exe", "wscript.exe", "cscript.exe") OR Image="*:\\Windows\\Temp\\*" OR Image="*:\\Users\\*\\AppData\\Local\\Temp\\*") | stats count by parent_process_name, process_name, Computer, CommandLine, _time | sort - _time ``` **Microsoft Sentinel KQL:** ```kql DeviceProcessEvents | where InitiatingProcessFileName in~ ("msiexec.exe", "setup.exe", "updaté.exe") | where FileName in~ ("cmd.exe", "powershell.exe", "wscript.exe", "cscript.exe") or FolderPath contains @"Temp\" | project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, InitiatingProcessCommandLine | order by Timestamp desc ``` --- ### H2: Mecanismos de atualização de software fazendo conexões de rede para destinos incomuns **Hipótese:** Processos de atualização (updaters, package managers) estão realizando conexões de saída para destinos que não correspondem à infraestrutura conhecida do vendor. No caso SUNBURST, o Orion fazia requisições HTTP simulando tráfego legítimo, mas para subdomínios DGA de `avsvmcloud.com`. **Indicadores de verdadeiro positivo:** - Updater conectando a IP/domínio pela primeira vez (nunca visto no ambiente) - Destino em país incomum para o vendor (ex: updater de software americano conectando a IPs russos ou chineses) - Uso de User-Agent genérico ou malformado em requisições HTTP de processo de atualização - Balizamento DNS com subdomínios gerados algoritmicamente (DGA) **Indicadores de falso positivo:** - CDNs globais legítimas (Cloudflare, Akamai, Fastly) - verificar o domínio pai - Telemetria e análise de software (ex: `telemetry.microsoft.com`, `updaté.googleapis.com`) - VPNs corporativas que fazem NAT do tráfego de saída **Splunk SPL:** ```splunk index=wineventlog sourcetype=xmlwineventlog:Microsoft-Windows-Sysmon/Operational (EventCode=1 (process_name IN ("updaté.exe", "msiexec.exe", "svchost.exe")) OR EventCode=3 (parent_process_name IN ("updaté.exe", "msiexec.exe"))) | eval dest_clean=lower(dest_host) | where NOT match(dest_clean, "(microsoft|windowsupdaté|adobe|google|apple|amazonaws|akamai|cloudflare)\.com") | stats dc(dest_host) as unique_dests values(dest_host) as destinos by Computer, process_name | where unique_dests > 0 | sort - unique_dests ``` **Microsoft Sentinel KQL:** ```kql DeviceNetworkEvents | where InitiatingProcessFileName in~ ("msiexec.exe", "wuauclt.exe", "updaté.exe", "svchost.exe") | where RemoteUrl !contains "windowsupdaté" and RemoteUrl !contains "microsoft.com" and RemoteUrl !contains "akamai" and RemoteUrl !contains "cloudflare" | summarize FirstSeen=min(Timestamp), DestCount=dcount(RemoteIP), Destinos=make_set(RemoteUrl) by DeviceName, InitiatingProcessFileName, RemoteIP | where DestCount > 0 | order by FirstSeen desc ``` --- ### H3: Bibliotecas dinâmicas carregadas por processos privilegiados foram modificadas recentemente **Hipótese:** Um processo de alta integridade (SSHD, serviço de sistema, processo assinado) está carregando uma DLL/biblioteca shared object que foi criada ou modificada por um processo de integridade menor. Esse é o mecanismo exato do XZ Utils — onde `liblzma.so` foi modificada pelo processo de build e depois carregada pelo `sshd`. **Indicadores de verdadeiro positivo:** - `sshd` ou processo equivalente carregando `liblzma.so` versão 5.6.0 ou 5.6.1 - DLL/SO em diretório de sistema modificada há menos de 48 horas sem patch Tuesday correspondente - Discrepância entre checksum do arquivo e valor esperado do package manager **Indicadores de falso positivo:** - Atualizações legítimas do sistema operacional que atualizam bibliotecas compartilhadas - Deploys de software via Ansible/Chef que instalam versões específicas **Splunk SPL (Sysmon - Windows):** ```splunk index=wineventlog sourcetype=xmlwineventlog:Microsoft-Windows-Sysmon/Operational EventCode=7 InitiatingProcessIntegrityLevel IN ("High", "System") | join type=left ImageLoaded [ search index=wineventlog sourcetype=xmlwineventlog:Microsoft-Windows-Sysmon/Operational EventCode IN (11, 13) InitiatingProcessIntegrityLevel IN ("Medium", "Low") | rename TargetFilename as ImageLoaded ] | where isnotnull(EventCode) | stats values(InitiatingProcessIntegrityLevel) as integrity_levels by ImageLoaded, Computer | where mvcount(integrity_levels) > 1 | sort - Computer ``` **Microsoft Sentinel KQL:** ```kql // [VALIDAR NO SEU AMBIENTE] — Adaptar FolderPath para libs críticas do seu ambiente let imls = materialize( DeviceImageLoadEvents | where InitiatingProcessIntegrityLevel in ("High", "System") and FileName !endswith ".exe" | project FolderPath=tolower(FolderPath), InitiatingProcessFileName, InitiatingProcessIntegrityLevel, DeviceId, DeviceName | distinct FolderPath, InitiatingProcessFileName, InitiatingProcessIntegrityLevel, DeviceId, DeviceName ); imls | join ( DeviceFileEvents | where FolderPath in~ ((imls | project FolderPath)) and ActionType in ("FileCreated", "FileModified") and InitiatingProcessIntegrityLevel !in ("High", "System", "") and InitiatingProcessAccountSid != "S-1-5-18" and InitiatingProcessTokenElevation in ("TokenElevationTypeDefault", "TokenElevationTypeLimited") and InitiatingProcessAccountSid !endswith "-500" | extend FolderPath=tolower(FolderPath) ) on FolderPath, DeviceId, DeviceName | project-away FolderPath1 | order by Timestamp desc ``` --- ### H4: Tarefas agendadas ou serviços instalados imediatamente após atualização de software **Hipótese:** Um mecanismo de persistência (scheduled task, serviço Windows, cron job) foi criado dentro de uma janela de tempo próxima à execução de um instalador ou updater. Isso indica que o software comprometido instalou persistência como parte do processo de setup. **Indicadores de verdadeiro positivo:** - Nova task/serviço criado dentro de 90 minutos após execução de `msiexec.exe` ou `setup.exe` - Task aponta para binário em diretório temporário ou incomum (`%APPDATA%`, `%TEMP%`) - Nome do serviço genérico ou semelhante a serviços do sistema (typosquatting) - Serviço configurado para executar com `SYSTEM` privileges sem justificativa **Indicadores de falso positivo:** - Softwares legítimos que instalam serviços de atualização em background (ex: Google Updaté Service, Adobe Updaté) - Ferramentas de monitoramento corporativo (ex: Tanium, CrowdStrike, Carbon Black) **Splunk SPL:** ```splunk index=wineventlog (sourcetype=WinEventLog:Security EventCode=4698 OR sourcetype=WinEventLog:Security EventCode=7045) | eval evento_tipo=if(EventCode==4698, "ScheduledTask", "ServiceInstall") | join type=inner Computer [ search index=wineventlog sourcetype=WinEventLog:Security EventCode=4688 (New_Process_Name="*msiexec*" OR New_Process_Name="*setup*" OR New_Process_Name="*install*") | eval install_time=_time | stats max(install_time) as ultimo_install by Computer ] | where abs(_time - ultimo_install) < 5400 | table Computer, evento_tipo, TaskName, ServiceName, _time, ultimo_install | sort - _time ``` **Microsoft Sentinel KQL:** ```kql DeviceEvents | where ActionType in ("ScheduledTaskCreated", "ServiceInstalled") | join kind=inner ( DeviceProcessEvents | where Timestamp > ago(24h) and FileName in~ ("msiexec.exe", "setup.exe", "install.exe", "updaté.exe") | summarize LastUpdaté=max(Timestamp) by DeviceName ) on DeviceName | where Timestamp between (LastUpdaté .. (LastUpdaté + 1h)) | project Timestamp, DeviceName, ActionType, AdditionalFields, LastUpdaté | order by Timestamp desc ``` --- ### H5: Processos confiáveis exibindo latência ou comportamento de balizamento periódico (beaconing) **Hipótese:** O SUNBURST aguardava 12-14 dias antes de ativar, depois transmitia a intervalos regulares via DNS. O XZ Utils introduzia latência de ~500ms no handshake SSH. Processos confiáveis com comunicação periódica e regular para o mesmo destino externo são suspeitos. **Indicadores de verdadeiro positivo:** - Processo confiável fazendo conexões DNS/HTTP em intervalos regulares (ex: a cada 30 minutos exatamente) - Subdomínios com padrões aleatórios longos (indicativo de DGA ou encoding de dados) - Latência anômala em serviços de rede (SSH com > 400ms de overhead no handshake) **Indicadores de falso positivo:** - Software de telemetria e heartbeat legítimo (muitos agentes de EDR, antivírus, RMM) - Serviços de atualização que verificam disponibilidade periodicamente **Splunk SPL — Detecção de Beaconing DNS:** ```splunk index=dns OR index=network sourcetype=stream:dns | eval hora_bucket=strftime(_time, "%Y-%m-%d %H:%M") | stats count by src_ip, query, hora_bucket | eventstats avg(count) as media_count stdev(count) as stdev_count by src_ip, query | where stdev_count < 2 AND count > 5 | eval jitter_baixo=if(stdev_count < 1, "SUSPEITO - beaconing regular", "normal") | where jitter_baixo="SUSPEITO - beaconing regular" | table src_ip, query, media_count, stdev_count, jitter_baixo ``` **Microsoft Sentinel KQL — Beaconing em DnsEvents:** ```kql // [VALIDAR NO SEU AMBIENTE] — Ajustar threshold de count e intervalos DnsEvents | where TimeGenerated > ago(24h) | summarize ContadorConsultas=count(), Intervalos=make_list(TimeGenerated) by Computer, Name | where ContadorConsultas > 20 | extend DesvioPadrao=array_length(Intervalos) | where DesvioPadrao > 0 | project Computer, Name, ContadorConsultas | order by ContadorConsultas desc ``` --- ### H6: Versões de pacotes instalados incompatíveis com o baseline aprovado **Hipótese:** Um software crítico (biblioteca de sistema, ferramenta de infraestrutura) está instalado em uma versão que não consta no baseline aprovado da organização, ou que difere do hash esperado. O caso XZ Utils é o exemplo perfeito — a versão 5.6.0/5.6.1 era a comprometida enquanto 5.4.x era a segura. **Indicadores de verdadeiro positivo:** - Versão instalada corresponde a release comprometida conhecida (ex: XZ 5.6.0, SolarWinds Orion 2020.2) - Hash do binário não corresponde ao hash públicado pelo vendor - Software instalado em endpoints que não deveriam ter aquele software **Indicadores de falso positivo:** - Ambientes de desenvolvimento onde versões variadas coexistem intencionalmente - Containers com pinning de versão específica para compatibilidade **Splunk SPL — Inventário de versão via Osquery:** ```splunk index=osquery sourcetype=osquery:results name=installed_packages | search (name="xz" OR name="xz-utils" OR name="liblzma") | eval versao_suspeita=if(match(version, "5\\.6\\.[01]"), "COMPROMETIDA", "OK") | where versao_suspeita="COMPROMETIDA" | table host, name, version, versao_suspeita ``` **Microsoft Sentinel KQL — Via Defender Vulnerability Management:** ```kql // [VALIDAR NO SEU AMBIENTE] — Adaptar para produtos relevantes ao seu ambiente DeviceTvmSoftwareInventory | where SoftwareName contains "xz" or SoftwareName contains "solarwinds" or SoftwareName contains "orion" | project DeviceName, SoftwareName, SoftwareVersion, SoftwareVendor, LastSeenTime | order by LastSeenTime desc ``` --- ### H7: Implante dormente ativando reconhecimento interno após período de espera **Hipótese:** O SUNBURST ficava inativo por 12-14 dias e depois executava reconhecimento (enumeração de AD, descoberta de processos de segurança) antes de prosseguir. Buscar por um padrão de "silêncio prolongado → explosão de atividade" em processos confiáveis pode revelar implantes ainda em fase de dormência. **Indicadores de verdadeiro positivo:** - Processo confiável que estava inativo por dias repentinamente executa `net.exe`, `whoami`, `nltest`, `ipconfig /all` - Enumeração de domínio Active Directory a partir de processo de serviço (não de estação de trabalho de analista) - Consultas LDAP incomuns originadas de processo de software de gerenciamento de TI **Indicadores de falso positivo:** - Scripts de auditoria agendados (ex: verificações de conformidade mensais) - Ferramentas de inventário de TI (Lansweep, PDQ Inventory) que fazem descoberta periódica **Splunk SPL — Reconhecimento pós-dormência:** ```splunk index=wineventlog sourcetype=xmlwineventlog:Microsoft-Windows-Sysmon/Operational EventCode=1 process_name IN ("net.exe", "net1.exe", "nltest.exe", "whoami.exe", "ipconfig.exe", "dsquery.exe") parent_process_name IN ("solarwinds.businesslayerhost.exe", "msiexec.exe", "svchost.exe", "services.exe") | stats count by parent_process_name, process_name, Computer, CommandLine, _time | where count > 3 | sort - _time ``` **Microsoft Sentinel KQL:** ```kql DeviceProcessEvents | where FileName in~ ("net.exe", "net1.exe", "nltest.exe", "whoami.exe", "ipconfig.exe", "dsquery.exe", "adfind.exe") | where InitiatingProcessFileName !in~ ("explorer.exe", "cmd.exe", "powershell.exe") | summarize ContadorExecucoes=count(), Comandos=make_set(ProcessCommandLine) by DeviceName, InitiatingProcessFileName, FileName | where ContadorExecucoes > 2 | order by ContadorExecucoes desc ``` --- ## Como Priorizar Nem todas as hipóteses têm o mesmo peso. Use a tabela abaixo para focar esforços: | Hipótese | Risco | Fidelidade | Prioridade | Justificativa | |----------|-------|------------|------------|---------------| | H3 - DLL/libs modificadas | Crítico | Alta | 🔴 1 | Indicador técnico direto; poucos FPs | | H6 - Versões comprometidas | Crítico | Alta | 🔴 1 | Verificação objetiva contra baseline | | H1 - Processos filhos incomuns | Alto | Média | 🟠 2 | Alta cobertura, ruído moderado | | H4 - Persistência pós-install | Alto | Média | 🟠 2 | Indicador claro de comprometimento | | H7 - Reconhecimento pós-dormência | Alto | Alta | 🟠 2 | Sinal tardio, mas altamente confiável | | H2 - Conexões incomuns de updaters | Médio | Baixa | 🟡 3 | Alta taxa de FPs - requer whitelist robusta | | H5 - Beaconing periódico | Médio | Baixa | 🟡 3 | Difícil de diferenciar de telemetria legítima | > [!tip] Comece por H3 e H6 > A verificação de versão (H6) e de integridade de biblioteca (H3) são as mais objetivas e com menor taxa de falso positivo. Confirme o baseline primeiro, depois avance para análise comportamental. --- ## Análise de Falsos Positivos Os FPs mais comuns neste tipo de hunting e como diferenciá-los: ### FP 1: Ferramentas de gerenciamento de TI (RMM, EDR, MDM) **Problema:** Agentes como CrowdStrike, Tanium, Ansible executam ações que simulam supply chain compromise (processos filhos de serviços, conexões periódicas, criação de tasks). **Diferenciação:** Mantenha whitelist de processos e destinos de rede de todos os agentes de gerenciamento aprovados. Verifique se o binário é assinado pelo vendor correto e se o destino de rede pertence à infraestrutura do vendor. ### FP 2: Software de desenvolvimento e build local **Problema:** npm, pip, Maven, Gradle e outros package managers criam conexões de rede, instalam bibliotecas e geram processos filhos como parte normal do desenvolvimento. **Diferenciação:** Segmente por contexto — hunting em servidores de produção deve excluir estações de desenvolvedor. Se executando em produção, qualquer atividade de build é suspeita por si só. ### FP 3: Atualizações legítimas do sistema operacional **Problema:** Windows Updaté, apt/yum no Linux e outros gerenciadores de pacote do sistema criam DLLs, serviços e tarefas como parte de patches legítimos. **Diferenciação:** Correlacione com janelas de manutenção aprovadas e change management (CMDB). Atividade de updaté fora de janela de manutenção deve ser investigada. ### FP 4: Software legítimo com beaconing para telemetria **Problema:** Adobe, Microsoft, Google e dezenas de outros vendors fazem check-in periódico de licença/telemetria com intervalos regulares. **Diferenciação:** Mantenha inventário dos destinos de telemetria de cada software corporativo. Use DNS allowlist para destinos de telemetria conhecidos e marque o restante como suspeito. --- ## Quando Escalar para IR Completo > [!danger] Critérios de Escalação Imediata > A presença de qualquer critério abaixo deve acionar IR completo imediatamente. ### Escalar IMEDIATAMENTE se: - **Versão comprometida confirmada** - software instalado corresponde a release com backdoor conhecido (ex: XZ Utils 5.6.0/5.6.1, SolarWinds Orion 2020.2.x) - **Reconhecimento de AD confirmado** - H7 positivo com `nltest`, `dsquery`, `adfind` executados a partir de processo de software de terceiro - **Exfiltração de dados confirmada** - conexão de saída para C2 conhecido com volume de dados transferidos acima do baseline - **Implante confirmado por EDR** - alerta de EDR correlacionado com qualquer hipótese positiva neste playbook - **Hash de binário não corresponde ao vendor** - verificação de integridade falha em binário crítico de sistema ### Escalar em até 4 horas se: - H1 + H2 positivos simultaneamente no mesmo host (processo suspeito COM conexão de rede incomum) - H4 positivo com tarefa/serviço apontando para diretório não-padrão - H3 positivo com DLL modificada em diretório de sistema ### Continuar hunting (sem IR ainda) se: - Apenas H5 positivo (beaconing isolado) - aprofundar análise de destino e frequência - Apenas H2 positivo - verificar whitelist e enriquecer com contexto de domínio - Hipótese única positiva com forte candidato de FP identificado --- ## Referências de Caça - [[t1195-002-supply-chain-compromise|T1195.002 - Supply Chain Compromise]] - técnica MITRE ATT&CK principal - [[t1105-ingress-tool-transfer|T1105 - Ingress Tool Transfer]] - transferência de payload pós-comprometimento - [[t1027-obfuscated-files|T1027 - Obfuscated Files]] - ofuscação usada no SUNBURST e XZ Utils - [[t1574-002-dll-side-loading|T1574.002 - DLL Side-Loading]] - mecanismo de injeção via biblioteca legítima - [[solarwinds-supply-chain-attack]] - caso de referência principal - [[s0559-sunburst]] - análise do implante do caso SolarWinds - [[g0016-apt29]] - grupo responsável pelo ataque SolarWinds - CISA Advisory AA20-352A - orientações de detecção para SUNBURST - NIST SP 800-161r1 - Cybersecurity Supply Chain Risk Management