CVE-2025-47988 no Azure Monitor Agent: Avaliar o Risco na PME

O CVE-2025-47988 é uma vulnerabilidade de injecção de código no Azure Monitor Agent (AMA), corrigida na versão 1.35.1 do agente. O perfil de exploração é específico — vector de rede adjacente, complexidade alta, sem privilégios nem interação do utilizador — e isso muda o cálculo de risco conforme a topologia da rede. Para uma PME com servidores onboarded ao Azure Arc ou ao Log Analytics, a pergunta prática é: que versões de AMA tenho a correr e onde estão expostas?

O que é a vulnerabilidade

A Microsoft descreve o CVE-2025-47988 como uma injecção de código (“improper control of generation of code”, CWE-94) no Azure Monitor Agent que permite a um atacante não autorizado executar código através de uma rede adjacente. Os dados técnicos da NVD (estado Analyzed, com avaliação da CISA-ADP):

Campo Valor
CVSS 3.1 Base Score 7.5 HIGH
Vector CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE 94 (Improper Control of Generation of Code)
Versões afectadas Azure Monitor Agent < 1.35.1
Correcção AMA 1.35.1
SSVC (CISA) Exploitation: none · Automatable: no · Technical Impact: total

Sobre a cronologia da correcção: a página oficial de versões do agente lista a 1.35.1 na secção de Maio de 2025 (vertente Windows), com rollout progressivo por regiões ao longo de 4–6 semanas e notas de release publicadas depois do rollout completado — a divulgação do CVE em Julho de 2025 (Patch Tuesday) veio depois de a versão corrigida estar já em distribuição, um padrão normal de patch silencioso antes do disclosure. Quem manteve auto-upgrade activo ficou protegido antes do anúncio público.

A leitura do vector importa mais do que o score: AV:A (adjacent network) significa que o atacante precisa de acesso à rede no segmento onde o agente escuta — não é explorável da Internet directamente a menos que o dispositivo esteja exposto. AC:H (high complexity) e PR:N/UI:N indicam que não requer credenciais nem engano do utilizador, mas a janela de exploração é condicionada. O impacto nos três eixos (confidencialidade, integridade, disponibilidade) é alto: execução de código com os privilégios do agente.

O agente corre com privilégios elevados no host (processa telemetria, logs e métricas de sistema), pelo que a execução de código no AMA é execução de código no servidor — com acesso aos dados que o agente recolhe (logs de segurança, eventos, contadores de performance).

Quem é afectado na prática

O AMA está presente em três cenários que as PMEs usam:

  1. VMs Azure com Azure Monitor / Log Analytics — o agente vem por DCR (Data Collection Rules) para recolher logs e métricas.
  2. Servidores on-premise com Azure Arc — o AMA estende a monitorização cloud a servidores locais via servidores Arc-enabled.
  3. VM Scale Sets — instâncias com DCRs associadas.

A vulnerabilidade é relevante para qualquer um dos três com versão de agente anterior a 1.35.1. Como o agente se auto-actualiza por omissão (ver secção seguinte), o inventário típico em Setembro de 2026 já deve estar acima da versão corrigida — a excepção são ambientes com auto-upgrade desactivado, redes com restrições de saída, ou agentes que falharam updates.

Verificar a versão do agente

Na VM ou servidor Arc, a extensão AzureMonitorWindowsAgent (ou AzureMonitorLinuxAgent) tem a versão no nome. Vias rápidas:

Portal Azure: VM → Extensions + applications → coluna “State” mostra a versão da extensão (ex.: AzureMonitorWindowsAgent/1.45).

Azure Resource Graph (multi-VM, para inventário em escala):

resources
| where type =~ "microsoft.compute/virtualmachines/extensions"
| where name startswith "AzureMonitor"
| extend agentVersion = tostring(properties.settings.agentSettings)
| project name, agentVersion, resourceGroup

PowerShell local (no servidor, via extensão instalada):

Get-Process MicrosoftMonitoringAgent* -ErrorAction SilentlyContinue
# ou no Linux:
/opt/microsoft/omsagent/bin/omsadmin.sh --version

Atenção: a Microsoft suporta apenas versões de AMA lançadas no último ano e publica correcções apenas na versão mais recente. Um agente abaixo da versão corrente não recebe bug fixes — a remediação do CVE-2025-47988 (e de quaisquer issues posteriores) é actualizar para a versão mais recente disponível, não apenas para a 1.35.1.

Actualizar o agente

O mecanismo por omissão resolve a maioria dos casos: a Microsoft faz rollout progressivo automático das novas versões por região Azure (as vertentes Windows e Linux seguem calendários separados, com datas de início próprias). Com auto-upgrade activo, o agente actualiza-se sem acção.

Para gerir manualmente (ambientes com auto-upgrade desactivado ou necessidade de forçar):

  • Portal: VM → Extensions + applications → seleccionar a extensão AzureMonitorAgent → Update (instala a versão mais recente disponível na região).
  • CLI Azure:
az vm extension set \
  --publisher Microsoft.Azure.Monitor \
  --name AzureMonitorWindowsAgent \
  --vm-name NOMEDAVM \
  --resource-group NOMEDOGRUPO \
  --version 1.45
  • Servidores Arc: o update via Arc tem o mesmo fluxo — extensão no recurso Server – Azure Arc, ou em escala com Azure Policy Configure Azure Monitor agents to auto-upgrade.

Referência oficial das versões e do que cada uma corrige: Azure Monitor Agent extension versions — a tabela mensal lista Windows/Linux/Metrics e destaques (ex.: Junho 2026 Linux 1.42 com correcções CVE e memory leaks, Maio 2026 Windows 1.43 com OpenSSL 3.6.2, Agosto 2026 Windows 1.45 com OpenSSL 3.6.3).

Reduzir a superfície: o vector de rede adjacente

O vector AV:A merece atenção específica. O AMA escuta localmente para recolher telemetria — a exposição de rede relevante para o CVE depende da configuração. Medidas práticas de contenção, independentemente da versão:

  • Segmentação de redes de gestão — servidores monitorizados não precisam de acesso bidireccional com estações de utilizadores. VLAN de servidores com fluxo de saída para endpoints de Azure Monitor.
  • NSGs na VNet — restringir o tráfego para os endpoints do AMA (endpoints de DCR e Log Analytics) aos IPs de serviço documentados pela Microsoft.
  • Firewall local — Windows Firewall com regras de saída para global.in.ai.monitor.azure.com, .ods.opinsights.azure.com, .oms.opinsights.azure.com e afins, negando o resto.
  • Patch em anéis — VMs críticas primeiro. VM Scale Sets com rollout sequencial por instância.

Esta abordagem segue a orientação standard para vulnerabilidades de agentes de monitorização: o agente corre em toda a frota — uma vulnerabilidade nele é uma superfície de ataque transversal.

Estado da exploração e contexto

A NVD e os agregadores de threat intelligence não tinham, na data deste artigo, evidência de exploração activa do CVE-2025-47988 (sem PoC público conhecido, CISA-ADP marca exploitation: none). Não é garantia futura — agentes de monitorização são alvos atrativos porque estão presentes em massa e correm com privilégios, e o padrão de ataques a agentes (ex.: explorar agentes de backup, antivírus ou monitoring como vector de lateral movement) é recorrente.

O histórico do AMA em 2025 inclui outras correcções relevantes para quem usa a stack: o boletim NCSC-NL (via vulnerability.circl.lu) confirma o CVE-2025-47988 no advisory da Microsoft com score 7.5, e vulnerabilidades adjacentes em agentes de monitorização/management (access control impróprio, deserialização) foram documentadas no Outono de 2025. A lição transversal: o agente de monitorização é parte da superfície de ataque — incluí-lo no ciclo de patch management é obrigatório, não opcional.

Integração no ciclo de patch management da PME

Para quem já tem Azure Monitor/Log Analytics na stack, o CVE é um lembrete barato de três rotinas:

  1. Inventário mensal de versões de agente — Azure Resource Graph query (secção acima) exportada para o log de compliance. Versões com >12 meses = acção.
  2. Auto-upgrade activo — verificar que a policy de auto-upgrade está activa por região. Desactivações pontuais (ex.: durante uma janela de change freeze) precisam de re-activação agendada.
  3. Telemetria de falhas de update — o Agent health do Azure Monitor reporta agentes com falha de upgrade. Revisar mensalmente.
  4. CVE tracking da stack — subscrever o feed MSRC do produto Azure Monitor. Os boletins da Microsoft identificam as versões de agente corrigidas quando aplicável.

Erros comuns

Problema Causa Solução
Agente não actualiza automaticamente Auto-upgrade desactivado ou bloqueio de rede aos endpoints de rollout Activar policy de auto-upgrade; validar conectividade de saída aos endpoints do serviço
Versão antiga persiste em VM Scale Sets Rollout automático não alcança instâncias em update domains em falha Forçar update manual por instância; corrigir os update domains
ExtensionProvisioningError no update Provisionamento anterior incompleto Remover extensão e re-instalar (portal ou CLI), reassociar DCR
Logs param de chegar após update DCR associada em estado falho Verificar Data Collection Rules → health da DCR; revalidar associações
Arc server sem telemetria pós-update Agente instalado mas identity/registration de Arc em falha Re-validar azcmagent connectivity; verificar o endpoint do Arc

Checklist rápido

  • ✓ Inventário de versões AMA em toda a frota (VMs, Scale Sets, Arc) executado
  • ✓ Nenhuma instância abaixo da 1.35.1 — idealmente todas na versão corrente do último ano
  • ✓ Auto-upgrade activo via policy ou confirmado por região
  • ✓ Segmentação de rede entre a frota monitorizada e o resto da LAN em vigor
  • ✓ Endpoints do AMA cobertos pelas regras de firewall documentadas
  • ✓ CVEs do AMA no ciclo de revisão mensal (MSRC + extensão versions page)
  • ✓ Falhas de upgrade do agente monitorizadas (Update/DCR health)

Como evitar no futuro

  • Tratar agentes de monitorização como qualquer outro componente de segurança — patch, versão mínima, e revisão periódica.
  • Usar Azure Policy para auto-upgrade como default em toda a organização, com excepções documentadas.
  • Manter o inventário de agentes no Azure Resource Graph — consultável a qualquer momento, sem scripts manuais.
  • Revisar trimestralmente as DCRs — regras órfãs de VMs descomissionadas ampliam superfície sem valor.
  • Integrar o feed MSRC do Azure Monitor no processo de triagem mensal de patches.

Artigos Relacionados