Tag: Alerta

Vol. 1 No. 20260127-1101 (2025)

Atualização de Emergência Microsoft

Adriano Cansian | adriano.cansian@unesp.br | 27/01/2026

Esse é um alerta crítico. A Microsoft lançou no início da noite de ontem (26 de janeiro de 2026) uma atualização de segurança de emergência, para corrigir a vulnerabilidade zero-day CVE-2026-21509, que permite contornar de proteções contra controles inseguros nos aplicativos Microsoft Office, fazendo que um ataque possa acontecer por intermédio de um documento ou arquivo malicioso, possivelmente sem interação do usuário.

A vulnerabilidade atinge aplicações Microsoft Office / 365 tanto no Windows como no macOS (veja comentário sobre o MacOS no final dessa postagem).

Temos notícias de que vulnerabilidade essa está sendo explorada ativamente por atacantes usando documentos maliciosos.

Essa falha afeta todas as versões, tais como Office 2016, 2019, LTSC 2021/2024 e Microsoft 365 Apps Enterprise, bem como Microsoft 365 Standalone ou Famility Edition, tanto no Windows quanto no macOS.

O que fazer, imediatamente

  1. Aplique as atualizações de segurança do Microsoft Office via Microsoft Update ou WSUS.​ 
  2. Reinicie as aplicações Microsoft 365 (muito importante), ou faça um reboot.
  3. Como mitigação temporária, configure o registro do Windows com a chave “Compatibility Flags” = 0x400 em HKEY_CURRENT_USER\Software\Microsoft\Office[version]\Common para reforçar as proteções OLE.
  4. Monitore phishing com anexos Office, dado o uso em campanhas direcionadas.

Nota importante: reinicie a aplicação

Não há um “número de versão/build” específico a partir do qual se esteja seguro, pois a correção é aplicada via service-side change (mudança da regra de proteção COM/OLE nos servidores Microsoft). Assim, Office 2021 e posteriores, que estejam atualizados, ficam protegidos com a versão mais recente que você tenha testado como atualizada em 26/01/2026, e após reinício completo dos aplicativos, sem necessidade de novo patch de instalação ou alteração no número da versão local. Ou seja, se sua versão já estiver atualizada, pode ser que você não veja uma mudança no número de versão.

Severidade CVSS E EPSS

A pontuação CVSS de severidade dessa vulnerabilidade é 7.8 (alta severidade). No momento de escrita desse alerta (27/01/2026 9h43m BRT), ela ainda não possui um score EPSS (Exploit Prediction Scoring System) disponível nos dados públicos recentes, pois foi divulgada há apenas um dia (26 de janeiro de 2026). O EPSS é atualizado diariamente pela FIRST.org com base em dados de exploração real. Como ela está sendo explorada ativamente e listada no catálogo KEV da CISA, espera-se um score EPSS elevado. Verifique em https://www.first.org/epss/search?cve=CVE-2026-21509 para o valor mais atual.

Detalhamento

As proteções contra controles COM/OLE inseguros no Microsoft Office são mecanismos de segurança implementados para bloquear a execução automática de objetos “COM” (Component Object Model) e “OLE” (Object Linking and Embedding) potencialmente maliciosos.

Objetos COM/OLE perigosos são componentes ActiveX ou objetos vinculados, embutidos, anexados ou inseridos em documentos do Microsoft Office (como ícones, gráficos ou mini-aplicativos de outros programas) que podem conter código malicioso.

Eles podem explorar a confiança automática do Office para executar scripts ou payloads sem interação segura do usuário, permitindo roubo de dados, instalação de malware ou controle remoto do sistema, como observado em ataques por meio de macros VBA, arquivos HTA ou streams OLE ofuscados em documentos Word ou Excel.

A Microsoft introduziu mecanismos de mitigação, incluindo kill bits, para reduzir esses riscos, especialmente em cenários de phishing com anexos maliciosos. Em segurança cibernética, chamamos essas proteções de “kill bits“. Esses kill bits são flags de segurança no Registro do Windows que desabilitam a criação ou execução de controles ActiveX específicos no Microsoft Office. A vulnerabilidade zero-day CVE-2026-21509 no Microsoft Office explora uma falha relacionada a essa proteção, permitindo contornar a restrição imposta pelos kill bits.

Apple / macOS

A CVE-2026-21509 afeta sim o Microsoft 365 no macOS, especificamente as Microsoft 365 Apps for Enterprise, Family e Standalone (incluindo Word, Excel, PowerPoint, Outlook), pois as mitigações OLE/COM são aplicadas no cliente Office, não dependentes do Sistema Operacional.

A Microsoft confirma que para Office 2021 e posteriores (incluindo M365), a proteção é via service-side change, requerendo reinício dos apps no macOS após propagação do serviço, similar ao Windows. Verifique atualizações no Microsoft AutoUpdate no macOS e reinicie os apps para ativar a correção emergencial de 26/01/2026.

Apesar da correção ter saído ontem, 26/1/2026, no caso do macOS a versão NÃO vulnerável é a partir de, e incluindo, a Version 16.105.1, de 20/01/2026. Em outras palavras, a instalação em si não muda de número de versão via patch tradicional; o ambiente passa a ficar protegido quando o tenant já recebeu a atualização no serviço e o usuário reinicia Word/Excel/PowerPoint/Outlook, momento em que as novas mitigações OLE/COM entram em vigor.

Caso queira verificar e forçar uma atualização no macOS, os comandos via terminal são os seguintes:

cd "/Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app/Contents/MacOS"
./msupdate --list  # Lista atualizações disponíveis
./msupdate --install  # Instala todas

Referências

[1] NVD (NIST): https://nvd.nist.gov/vuln/detail/CVE-2026-21509​

[2] Microsoft MSRC: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-21509

[3] Microsoft – Configurações de segurança para objetos COM no Office.

[4] Microsoft Learn – Como controlar o bloqueio de componentes OLE/COM na Assinatura do Microsoft 365

Vol. 1 No. 20251224-1075 (2025)

BRICKSTORM: A sofisticação silenciosa de um backdoor patrocinado por Estado

Adriano Cansian | adriano.cansian@unesp.br | 24/12/2025

Em 4 de dezembro de 2025, a Cybersecurity and Infrastructure Security Agency (CISA), a National Security Agency (NSA) e o Canadian Centre for Cyber Security publicaram um comunicado conjunto alertando sobre uma nova e altamente sofisticada campanha de malware denominada BRICKSTORM.

Mais do que um backdoor convencional, o BRICKSTORM representa uma ameaça sistêmica a ambientes de virtualização, infraestrutura de identidade e operações corporativas críticas, explorando exatamente os pontos onde a visibilidade de segurança costuma ser limitada ou inexistente.

O relatório técnico AR25-338A, atualizado em 19 de dezembro de 2025, descreve em detalhes as capacidades avançadas do malware e disponibiliza indicadores de comprometimento destinados a apoiar equipes de defesa. Investigações conduzidas em resposta a incidentes revelam um dado alarmante, o tempo médio de permanência não detectada nos ambientes comprometidos chega a 393 dias, evidenciando o nível de evasão operacional alcançado pelos atores responsáveis.

A campanha é atribuída a atores patrocinados pelo Estado da República Popular da China, com foco em acesso persistente, coleta de credenciais privilegiadas e exploração silenciosa de infraestruturas críticas.

1. Visão Geral Técnica

O BRICKSTORM é um backdoor modular desenvolvido para ambientes VMware vSphere, incluindo vCenter e ESXi, além de sistemas Windows. Até o momento, foram identificadas pelo menos oito amostras distintas, coletadas a partir de ambientes reais de vítimas, incluindo organizações atendidas diretamente pela CISA em operações de resposta a incidentes.

O malware foi desenvolvido em linguagem Go, uma escolha arquitetural estratégica que permite portabilidade entre plataformas Linux, BSD e Windows. Esse fator é especialmente relevante porque possibilita a implantação do BRICKSTORM em appliances de perímetro e componentes de infraestrutura que normalmente não contam com EDRs ou agentes de segurança tradicionais, reduzindo drasticamente a superfície de detecção.

1.1. Vetores de Infecção e Acesso Inicial

A análise de múltiplos incidentes revela um padrão recorrente nos vetores de ataque utilizados. O acesso inicial ocorre, predominantemente, por meio da exploração de vulnerabilidades em dispositivos de perímetro e sistemas de acesso remoto , incluindo appliances de rede expostos à Internet (veja esss outra postagem sobre as vulnerabilidades associadas ao ataque inicial).

Em pelo menos um dos casos documentados, os atores exploraram vulnerabilidades zero-day, indicando acesso a capacidades avançadas de desenvolvimento e manutenção de exploits.

Após o comprometimento inicial, geralmente por meio de web shells implantadas em servidores na DMZ, os atores realizam movimento lateral utilizando protocolos amplamente disponíveis como RDP e SMB. Durante esse processo, credenciais são sistematicamente coletadas e reutilizadas para acessar sistemas críticos, incluindo controladores de domínio e servidores ADFS.

Em um incidente investigado pela CISA, os atacantes mantiveram acesso persistente desde abril de 2024. A partir de uma web shell em um servidor web da DMZ, o grupo avançou lateralmente até o vCenter, onde implantou o BRICKSTORM como mecanismo de persistência de longo prazo.

Esse padrão reforça um ponto crítico, a campanha não depende de exploração ruidosa, mas sim de progressão metódica e silenciosa dentro da rede.

1.2. Persistência e Mecanismos de Autoproteção

O BRICKSTORM implementa mecanismos robustos de persistência, projetados para resistir a tentativas de remoção parcial ou reinicializações do sistema. Um dos componentes mais relevantes é sua função de auto-vigilância, que monitora continuamente o próprio processo e o reinicia automaticamente caso seja interrompido.

Em sistemas Linux e Unix, o malware é implantado em diretórios sensíveis, como /etc/sysconfig/, e integrado aos scripts de inicialização do sistema. Em ambientes VMware, modificações são realizadas diretamente nos arquivos de inicialização do hypervisor, garantindo carregamento precoce durante o boot.

As amostras analisadas indicam desenvolvimento ativo, com uso de obfuscação por ferramentas como Garble e versões customizadas de bibliotecas. Algumas variantes incluem timers programados para atrasar a comunicação com o C2, aguardando datas específicas, um indicativo claro de planejamento operacional e tentativa de evitar correlação temporal com o incidente inicial.

2. Capacidades Técnicas Avançadas

2.1. Comunicação de Comando e Controle

O canal de comando e controle do BRICKSTORM foi projetado para dificultar ao máximo a inspeção e correlação por SOCs tradicionais. O malware combina múltiplas camadas de comunicação e criptografia:

  • HTTPS como camada de transporte básica.
  • WebSockets para multiplexação de sessões.
  • TLS aninhado na camada de aplicação.
  • DNS-over-HTTPS (DoH) para ocultar resolução de nomes.

Na prática, essa combinação quebra modelos clássicos de detecção baseados em DNS, proxy e inspeção de tráfego, especialmente em ambientes onde appliances de perímetro são tratados como “caixas pretas” do ponto de vista de segurança.

A infraestrutura de C2 observada inclui uso de Cloudflare Workers, aplicações Heroku e serviços de DNS dinâmico como sslip.io e nip.io. Um aspecto particularmente relevante é a ausência de reutilização de domínios C2 entre vítimas, indicando operações altamente compartimentalizadas e orientadas à evasão.

2.2. Funcionalidades de Controle Remoto

Uma vez estabelecida a comunicação, o BRICKSTORM oferece aos operadores um conjunto completo de capacidades de controle remoto:

  • Shell interativo para execução de comandos arbitrários.
  • Gerenciamento completo de arquivos.
  • Proxy SOCKS para facilitação de movimento lateral.
  • API HTTP para operações administrativas.
  • Suporte a VSOCK, permitindo comunicação inter-VM em ambientes virtualizados.

Essas funcionalidades transformam o sistema comprometido em um ponto de apoio operacional, capaz de sustentar operações de espionagem de longo prazo.

3.3. Escalação de Privilégios em Ambientes vCenter

Um dos aspectos mais sofisticados da campanha é a implantação de um Servlet Filter malicioso, rastreado como BRICKSTEAL, no Apache Tomcat que hospeda a interface web do vCenter.

Esse componente intercepta requisições HTTP relacionadas à autenticação SAML2, decodificando headers que podem conter credenciais em texto claro. Considerando que muitas organizações integram o vCenter ao Active Directory, o impacto potencial é elevado.

Com credenciais administrativas em mãos, os atores exploram recursos legítimos do vCenter para clonar máquinas virtuais críticas, como controladores de domínio. Essas clones permitem a extração offline de artefatos sensíveis, incluindo o banco ntds.dit, sem disparar alertas nos sistemas originais.

Esse método ilustra um ponto essencial, a virtualização deixa de ser apenas alvo e passa a ser ferramenta do ataque.

3. Indicadores de Comprometimento e Detecção

A CISA disponibilizou um conjunto abrangente de indicadores técnicos, incluindo nomes de arquivos, diretórios, variáveis de ambiente, padrões de tráfego e modificações em sistemas.

Apesar da utilidade desses IoCs, o próprio perfil da campanha indica que a detecção eficaz depende muito mais de hunting ativo, análise comportamental e baseline de ambientes virtualizados do que de simples correspondência por assinatura.

Regras YARA e Sigma, hashes conhecidos e análise forense de logs devem ser tratados como ponto de partida, não como solução definitiva.

4. Contexto de Ameaça e Atores

A atividade foi atribuída ao grupo UNC5221, associado a operações patrocinadas pela China, conforme documentado pelo Google Threat Intelligence Group e pela Mandiant.

Os setores-alvo incluem governo, TI, serviços jurídicos, SaaS e BPOs, organizações que frequentemente operam como nós intermediários de acesso a dados, identidades e infraestrutura crítica.

O longo tempo de permanência e a baixa geração de telemetria indicam que os operadores monitoram ativamente os ambientes comprometidos e adaptam suas técnicas diante de sinais de investigação, reforçando o caráter persistente da ameaça.

5. Recomendações de Mitigação

As recomendações das agências incluem:

  • Hunting ativo em vCenter, ESXi e appliances de perímetro
  • Implementação rigorosa de MFA para acessos administrativos
  • Segmentação entre DMZ e infraestrutura crítica
  • Revisão contínua de logs de autenticação e alterações em ambientes virtualizados
  • Aplicação tempestiva de patches de segurança em plataformas VMware

Organizações que identifiquem indícios de comprometimento devem acionar a CISA e considerar engajamento imediato de equipes especializadas em resposta a incidentes.

6. Conclusão

O BRICKSTORM não é apenas mais um backdoor sofisticado. Ele representa uma mudança clara na forma como atores patrocinados por Estados exploram virtualização, identidade e confiança operacional.

Ao operar quase invisivelmente em camadas tradicionalmente pouco monitoradas, essa campanha desafia modelos clássicos de defesa e reforça a necessidade de visibilidade real sobre infraestrutura, não apenas sobre endpoints.

Para SOCs, MSPs e organizações que operam ambientes híbridos e virtualizados, a lição é inequívoca, virtualização deixou de ser apenas plataforma, passou a ser superfície de ataque crítica.

Referências

  1. CISA. (2025, December 4). “PRC State-Sponsored Actors Use BRICKSTORM Malware Across Public Sector and Information Technology.” https://www.cisa.gov/news-events/alerts/2025/12/04/prc-state-sponsored-actors-use-brickstorm-malware-across-public-sector-and-information-technology
  2. CISA. (2025, December 19 ). “BRICKSTORM Backdoor – Malware Analysis Report (AR25-338A).” https://www.cisa.gov/news-events/analysis-reports/ar25-338a
  3. NSA. (2025, December 4 ). “NSA Joins CISA to Release Guidance on Detecting BRICKSTORM Backdoor Activity.” https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/4348338/
  4. Canadian Centre for Cyber Security. (2025, December 4 ). “Joint Malware Analysis Report on Brickstorm Backdoor.” https://www.cyber.gc.ca/en/news-events/joint-malware-analysis-report-brickstorm-backdoor
  5. Google Threat Intelligence Group & Mandiant. (2025, September 24 ). “Another BRICKSTORM: Stealthy Backdoor Enabling Espionage into Tech and Legal Sectors.” https://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign

Vol. 1 No. 20250808-789 (2025)

Vulnerabilidade no Microsoft Exchange Server

Adriano Cansian | adriano.cansian@unesp.br | 08/08/2025

INTRODUÇÃO

Estamos cientes de uma vulnerabilidade de alta gravidade, a qual permite que um agente de ameaça cibernética com acesso administrativo a um servidor Microsoft Exchange local aumente privilégios explorando configurações híbridas vulneráveis. Essa vulnerabilidade, se não for corrigida, pode afetar a integridade da identidade do serviço Exchange Online de uma organização. Uma vez explorada, permite que um atacante com acesso administrativo a um servidor MS Exchange local consiga elevar seus privilégios para o ambiente em nuvem (Exchange Online), potencialmente comprometendo todo o domínio.

Ela foi catalogada como a vulnerabilidade CVE-2025-53786 com pontuação CVSS de 8.0 (Alta).

  • Tipo: Escalonamento de privilégios.
  • Gravidade: Alta, com pontuação CVSS de 8.0.
  • Vetor:  CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H
  • CWE-287: CWE-287: Improper Authentication
  • Impacto: Permite que um atacante com acesso administrativo local acesse o ambiente em nuvem sem deixar rastros facilmente detectáveis, explorando a confiança entre o Exchange local e o Exchange Online.
  • Causa principal: O uso de um service principal compartilhado para autenticação entre o servidor local e a nuvem em configurações híbridas, criando uma ligação que pode ser explorada.

OBSERVAÇÃO: Não há evidências de exploração ativa até o momento, 08 de agosto de 2025, mas a Microsoft classifica a vulnerabilidade como “Exploitation More Likely“ (Exploração Razoavelmente Provável) devido à sua gravidade. Independente de não haver relatos da exploração da vulnerabilidade em larga escala, nós recomendamos fortemente a aplicação de mitigação sugerida nesse documento.

A exploração é particularmente perigosa porque pode passar despercebida. O ataque não gera logs ou alertas evidentes, dificultando a detecção, já que usa funções legítimas do sistema.

RESUMO DA VULNERABILIDADE

O atacante já deve ter privilégios administrativos no servidor Exchange local, por exemplo, via uma senha fraca, outra vulnerabilidade, ação de phishing ou credenciais roubadas.

Como ocorre a exploração da vulnerabilidade:

  • O atacante acessa as keyCredentials do service principal, armazenadas na configuração do Exchange ou via PowerShell/Graph API.
  • Com essas chaves, ele gera um token S2S (server-to-server) válido para autenticação na nuvem.
  • Isso permite acesso a recursos como caixas de e-mail no Exchange Online, envio de e-mails em nome de outros usuários, alterações em configurações de segurança ou até pivô para outros serviços, como SharePoint Online.
  • Para entender o que é o service principal e o KeyCredentials e como esses se combinam para o ataque, consulte o apêndice desse alerta.

Quais os riscos associados:

  • Comprometimento de dados sensíveis (e-mails, configurações de segurança).
  • Movimento lateral para outros serviços na nuvem (como SharePoint).
  • Potencial para comprometimento total do domínio em ambientes híbridos.
  • A exploração é particularmente perigosa porque pode passar despercebida, mesmo com ferramentas de monitoramento como Conditional Access ou de autenticação MFA.

MITIGAÇÃO RECOMENDADA

1. Aplicar o hotfix de abril de 2025:

  • Instale a atualização de segurança em todos os servidores Exchange locais (2016, 2019 ou Subscription Edition) em modo híbrido.
  • Verifique se os servidores estão dentro do ciclo de suporte (ex.: Exchange 2019 CU14/CU15, Exchange 2016 CU23).

2. Fazer inventário e verificação:

  • Use o script HealthChecker.ps1 da Microsoft para identificar servidores afetados e gerar relatórios.

3. Migrar para um service principal dedicado:

  • Execute o Hybrid Configuration Wizard (HCW) atualizado para configurar uma nova entidade de serviço dedicada:
.\HybridConfigurationWizard.exe /Upgrade

.\HybridConfigurationWizard.exe /Configure
  • Redefina as keyCredentials do service principal compartilhado:
Connect-MgGraph -Scopes "Application.ReadWrite.All"
$sp = Get-MgServicePrincipal -Filter "displayName eq 'Exchange Hybrid Modern Auth Service Principal'"
Update-MgServicePrincipal -ServicePrincipalId $sp.Id -KeyCredentials @()

4. Adotar boas práticas

  • Minimize permissões administrativas.
  • Habilite e monitore logs detalhados.
  • Desconecte da internet servidores Exchange ou SharePoint em fim de vida (EOL).
  • Considere migrar para protocolos mais seguros, como Graph API, e reduzir o uso de Exchange Web Services (EWS).

INFORMAÇÕES ADICIONAIS

  • Descoberta: A vulnerabilidade foi reportada por Dirk-jan Mollema da Outsider Security e apresentada na conferência Black Hat no último dia 6 de agosto de 2025.
  • Diretiva da CISA: Agências federais dos EUA foram obrigadas a mitigar a falha até 11 de agosto de 2025, mas a recomendação se estende a todas as organizações com ambientes híbridos.
  • Contexto maior: Tal falha reforça a necessidade de revisar configurações legadas em ambientes híbridos e adotar modelos de zero trust para minimizar riscos.

REFERÊNCIAS:

[1] CISA – Emergency Directives ED 25-02: Mitigate Microsoft Exchange Vulnerability – Released: Aug 7, 2025

[2] Microsoft Exchange Server Hybrid Deployment Elevation of Privilege Vulnerability – CVE-2025-53786 Security Vulnerability – Released: Aug 6, 2025

[3] CVE-2025-53786

APÊNDICE

A keyCredentials é como um “chaveiro” criptográfico, que funciona como uma carteira de identidade do service principal híbrido. Ela é usada para autenticar um servidor Exchange local na nuvem. Na vulnerabilidade CVE-2025-53786, um atacante com acesso administrativo local pode roubar esse chaveiro (keyCredentials) e usá-lo para fazer se passar pelo servidor, acessando o Exchange Online sem deixar rastros óbvios.

O que é um Service Principal?

Um service principal é uma identidade não-humana usada em sistemas da Microsoft (como o Azure Active Directory, agora Microsoft Entra ID) para autenticar aplicativos ou serviços, permitindo que eles interajam com outros recursos na nuvem, como o Exchange Online. No caso de ambientes híbridos do Exchange, o service principal é usado para facilitar a comunicação segura entre o Exchange Server local (on-premises) e o Exchange Online (nuvem).

  • Função no ambiente híbrido: O service principal híbrido atua como uma “ponte” de autenticação, permitindo que o servidor local execute ações na nuvem, como sincronizar dados, gerenciar caixas de e-mail ou autenticar usuários. Ele é configurado automaticamente pelo Hybrid Configuration Wizard (HCW) durante a criação do ambiente híbrido.

O que é a keyCredentials?

A keyCredentials é uma propriedade do service principal que armazena as chaves criptográficas (certificados ou chaves assimétricas) usadas para autenticar o service principal no Microsoft Entra ID. Essas chaves são essenciais para o processo de autenticação server-to-server (S2S), permitindo que o servidor local consiga provar sua identidade ao acessar recursos na nuvem.

  • Formato: A keyCredentials contém informações como:
    • Chave pública de um certificado.
    • Identificador da chave (keyId).
    • Tipo de chave (geralmente assimétrica, como RSA).
    • Datas de validade (início e fim).
  • Uso: Quando o servidor Exchange local precisa acessar o Exchange Online, ele usa a chave privada correspondente à keyCredentials para assinar um token de autenticação (JWT). Esse token é validado pela nuvem usando a chave pública armazenada na keyCredentials.