# Playbook - Resposta a Exploração de VMware ESXi/vCenter > [!critical] CISA KEV - Exploração Ativa Confirmada > CVE-2025-22224 (CVSS 9.3) e CVE-2025-22225 (CVSS 8.2) estão no catálogo CISA KEV com exploração ativa confirmada. Estas vulnerabilidades permitem escape de VM e execução de código no hypervisor, comprometendo toda a infraestrutura virtualizada. > [!warning] Aviso de Aplicabilidade > Este playbook é um **ponto de partida** baseado em boas práticas públicas. Deve ser revisado, testado e adaptado ao ambiente específico da organização antes de uso em produção. Não substitui um plano formal de Resposta a Incidentes (IRP). Consulte sua equipe de segurança antes de executar qualquer ação de contenção em produção. ## Visão Geral As vulnerabilidades [[cve-2025-22224|CVE-2025-22224]] (VMware ESXi heap overflow) e [[cve-2025-22225|CVE-2025-22225]] (vCenter Server arbitrary write) representam uma das classes mais críticas de vulnerabilidade em ambientes corporativos: escape de máquina virtual. Um atacante que explora essas falhas pode saltar de uma VM comprometida para o hypervisor ESXi, obtendo controle total sobre todas as VMs hospedadas no mesmo host físico. O grupo [[g1048-unc3886]], conhecido por atacar infraestrutura de virtualização, tem sido associado à exploração dessas vulnerabilidades em campanhas contra organizações governamentais e do setor de defesa. O ataque tipicamente segue o padrão: comprometimento de VM via phishing ou exploit web, escalada para o hypervisor via CVE-2025-22224, e subsequente movimento lateral para vCenter e outras VMs. A Broadcom/VMware públicou patches em março de 2025, mas a janela de exposição é significativa dado que muitas organizações atrasam a aplicação de patches em infraestrutura de virtualização por receio de impacto operacional. > [!latam] Impacto Regional > VMware é a plataforma de virtualização dominante em datacenters brasileiros, especialmente nos setores **financeiro** e **governamental**. Bancos, seguradoras e órgãos federais mantêm infraestrutura crítica em ESXi, frequentemente com ciclos de patch mais lentos que o recomendado. O CTIR Gov emitiu alerta específico para órgãos federais sobre estas CVEs. --- ## Fluxo de Resposta ```mermaid graph TB D["Alerta: Exploração<br/>VMware Detectada"] --> T["Triagem:<br/>Confirmar CVE e Escopo"] T --> C1["Contenção Imediata:<br/>Isolar ESXi Afetado"] C1 --> C2["Contenção Rede:<br/>Segmentar vMotion/Mgmt"] C2 --> I["Investigação:<br/>Logs ESXi + vCenter"] I --> E["Erradicação:<br/>Patch + Rebuild"] E --> R["Recuperação:<br/>Validar e Restaurar"] R --> L["Lições Aprendidas:<br/>Hardening vSphere"] ``` **Legenda:** [[t1190-exploit-public-facing-application|T1190]] - [[cve-2025-22224|CVE-2025-22224]] - [[cve-2025-22225|CVE-2025-22225]] --- ## Indicadores de Acionamento Este playbook deve ser iniciado quando: - [ ] Scanner de vulnerabilidades detecta CVE-2025-22224 ou CVE-2025-22225 sem patch - [ ] EDR/HIDS detecta processo anômalo no hypervisor ESXi - [ ] Logs do vCenter mostram autenticação incomum ou criação de conta - [ ] Alerta de rede sobre tráfego anômalo nas VLANs de gerenciamento VMware - [ ] Notificação do CTIR Gov ou CERT.br sobre exploração ativa - [ ] CISA KEV atualizado incluindo estas CVEs --- ## Fase 1 - Detecção > [!warning] Aviso sobre as queries abaixo > ESXi tem logging limitado comparado a endpoints Windows. Muitas detecções dependem de logs do vCenter, network monitoring e EDR nas VMs guest. Garantir que syslog forwarding está habilitado em todos os hosts ESXi. ### Detecção de Exploração ESXi #### Microsoft Sentinel (KQL) ```kql // Detectar processos anômalos no ESXi via syslog Syslog | where Computer has "esxi" or Computer has "vcenter" | where SyslogMessage has_any ( "VMkernel", "vpxa", "hostd", "vobd") | where SyslogMessage has_any ( "exploit", "overflow", "heap", "arbitrary write", "authentication failure", "unauthorized", "shell access") | project TimeGenerated, Computer, SyslogMessage, ProcessName | order by TimeGenerated desc ``` ```kql // Acessos SSH incomuns ao ESXi Syslog | where Computer has "esxi" | where ProcessName == "sshd" | where SyslogMessage has "Accepted" | project TimeGenerated, Computer, SyslogMessage | summarize LoginCount = count() by Computer, bin(TimeGenerated, 1h) | where LoginCount > 3 // ESXi raramente deve ter acesso SSH frequente ``` Tabela(s): `Syslog` (ESXi syslog forwarding) #### Splunk SPL ```spl index=esxi_syslog sourcetype=vmware:esxi:syslog ("VMkernel" OR "vpxa" OR "hostd") ("exploit" OR "overflow" OR "heap" OR "unauthorized" OR "shell") | table _time, host, log_message | sort - _time ``` ```spl index=esxi_syslog sourcetype=vmware:esxi:syslog process=sshd "Accepted" | stats count as login_count by host, span=1h | where login_count > 3 | sort - login_count ``` ### Detecção via vCenter Logs #### Microsoft Sentinel (KQL) ```kql // Atividade suspeita no vCenter Syslog | where Computer has "vcenter" | where SyslogMessage has_any ( "UserLoginSessionEvent", "UserLogoutSessionEvent", "VmCreatedEvent", "VmRemovedEvent", "TaskEvent", "AlarmStatusChangedEvent") | where SyslogMessage has_any ( "root", "administrator", "vpxuser") | project TimeGenerated, Computer, SyslogMessage | order by TimeGenerated desc ``` ### Detecção de Rede ```kql // Tráfego anômalo nas VLANs de gerenciamento VMware CommonSecurityLog | where DeviceVendor == "PaloAltoNetworks" or DeviceVendor == "Fortinet" | where DestinationPort in (443, 902, 903, 5480, 9443) // Portas VMware | where SourceIP !in (dynamic(["LISTA_IPS_ADMIN_AUTORIZADOS"])) | project TimeGenerated, SourceIP, DestinationIP, DestinationPort, Activity | order by TimeGenerated desc ``` --- ## Fase 2 - Triagem e Investigação ### Perguntas-chave a responder - [ ] Quais hosts ESXi estão vulneráveis (sem patch)? - [ ] Houve acesso SSH ao ESXi fora do padrão normal? - [ ] Existem VMs comprometidas que poderiam servir de pivot? - [ ] O vCenter mostra criação de contas ou mudanças de permissão? - [ ] Há snapshots ou VMs novas não autorizadas? - [ ] As VLANs de gerenciamento (vMotion, Management, vSAN) estão segmentadas? ### Inventário de versões vulneráveis ```spl // Verificar versões ESXi no ambiente index=asset_inventory sourcetype=vmware_inventory | table hostname, esxi_version, build_number, last_patch_date | eval vulnerable = if(match(esxi_version, "7\.0|8\.0\.0|8\.0\.1"), "SIM", "Verificar") | sort - vulnerable ``` --- ## Fase 3 - Contenção > [!danger] Ação com Impacto Potencial > Contenção em ambiente VMware pode afetar todas as VMs hospedadas. Coordenar com equipes de infraestrutura antes de isolar hosts ESXi. Priorizar migração de VMs críticas via [[t1021-004-ssh|vMotion]] para hosts seguros. ### Contenção imediata (primeiros 30 min) - [ ] Desabilitar SSH no ESXi afetado (se não for necessário para investigação) - [ ] Bloquear acesso externo às portas de gerenciamento VMware (443, 902, 903, 5480) - [ ] Isolar VLAN de gerenciamento do ESXi comprometido - [ ] Migrar VMs críticas para hosts ESXi já patcheados (se disponíveis) - [ ] Revogar credenciais de todas as contas com acesso ao vCenter ### Contenção de longo prazo - [ ] Segmentar redes de gerenciamento VMware (Management, vMotion, vSAN) - [ ] Implementar MFA para acesso ao vCenter e ESXi - [ ] Aplicar patches CVE-2025-22224 e CVE-2025-22225 (VMSA-2025-0004) - [ ] Habilitar Lockdown Mode nos hosts ESXi --- ## Fase 4 - Erradicação - [ ] Aplicar patches VMSA-2025-0004 em todos os hosts ESXi e vCenter - [ ] Verificar integridade dos binários do ESXi (`esxcli software vib list`) - [ ] Resetar todas as credenciais: root ESXi, vpxuser, contas vCenter - [ ] Verificar certificados SSL do vCenter (adversários podem ter instalado certificados maliciosos) - [ ] Auditar todas as VMs em busca de backdoors pré-instalados - [ ] Verificar se há VIBs (vSphere Installation Bundles) não autorizados --- ## Fase 5 - Recuperação - [ ] Restaurar vCenter a partir de backup limpo se comprometido - [ ] Rebuild de hosts ESXi se integridade não pode ser confirmada - [ ] Validar que todos os hosts estão no build patcheado - [ ] Monitorar intensivamente por 72h: SSH, Web UI, API calls - [ ] Habilitar auditoria avançada do vCenter (Config > Advanced Settings) - [ ] Documentar lições aprendidas e atualizar procedimento de patching --- ## Automação SOAR ### Microsoft Sentinel Automation Rules 1. Trigger: syslog do ESXi com keywords de exploração 2. Auto-consultar versão do ESXi via API do vCenter 3. Se vulnerável: criar incidente P1, notificar equipe de infraestrutura 4. Auto-bloquear IP de origem no firewall de perímetro ### Splunk SOAR Playbook: `VMware ESXi Exploitation Response` 1. Trigger: alerta de IDS/IPS com signature de CVE-2025-22224 2. Consultar inventário VMware para identificar hosts afetados 3. Auto-migrar VMs críticas via PowerCLI 4. Criar ticket P1 com runbook de patching --- ## Lições Aprendidas > [!note] Preencher após execução real > - O que funcionou conforme esperado? > - O que falhou ou precisou de adaptação? > - Quais regras de detecção geraram falsos positivos? > - O que deve ser ajustado neste playbook? --- ## Notas Relacionadas - [[cve-2025-22224|CVE-2025-22224]] - CVE principal (ESXi heap overflow, CVSS 9.3) - [[cve-2025-22225|CVE-2025-22225]] - CVE secundária (vCenter arbitrary write, CVSS 8.2) - [[t1190-exploit-public-facing-application|T1190 - Exploit Public-Facing Application]] - [[t1210-exploitation-of-remote-services|T1210 - Exploitation of Remote Services]] - [[g1048-unc3886]] - Threat actor associado a ataques em VMware - [[_vmware|VMware]] - Perfil do vendor - [[m1051-update-software|M1051 - Update Software]] - Mitigação primária - [[m1030-network-segmentation|M1030 - Network Segmentation]] - Segmentação de gerenciamento - [[ir-fortimanager-exploitation]] - Playbook de IR similar (exploitation de infraestrutura) - [[hunting-initial-access-brokers]] - Hunting de acesso inicial