A Fortinet busca sempre desenvolver e implementar práticas e padrões mais rigorosos em benefício de todos os nossos clientes, inclusive por meio de pesquisa contínua de ameaças, fornecimento de recursos de atualização automática, treinamento e educação em segurança cibernética e comunicações responsáveis e proativas sobre as melhores práticas e higiene cibernética.
Mas incidentes recentes continuam a colocar isso em foco com explorações ativas de vulnerabilidades conhecidas, já que investigações da Fortinet descobriram uma técnica de pós-exploração usada por um agente de ameaça.
Durante esta investigação, um agente de ameaça foi observado usando vulnerabilidades conhecidas (por exemplo, FG-IR-22-398 , FG-IR-23-097 , FG-IR-24-015 ) para obter acesso a dispositivos Fortinet. O direcionamento de vulnerabilidades conhecidas e não corrigidas por um agente de ameaça não é novo e já foi examinado anteriormente; esta descoberta específica é o resultado de um agente de ameaça aproveitando uma vulnerabilidade conhecida com uma nova técnica para manter acesso somente leitura a dispositivos FortiGate vulneráveis após o vetor de acesso original ter sido bloqueado. Imediatamente após a descoberta, ativamos nossos esforços de resposta PSIRT, desenvolvemos as mitigações necessárias e nos comunicamos com os clientes afetados. Continuamos a trabalhar diretamente com esses clientes para garantir que eles tenham tomado medidas para remediar o problema.
Um agente de ameaça utilizou uma vulnerabilidade conhecida para implementar acesso somente leitura a dispositivos FortiGate vulneráveis. Isso foi feito por meio da criação de um link simbólico conectando o sistema de arquivos do usuário e o sistema de arquivos raiz em uma pasta usada para servir arquivos de idioma para a SSL-VPN. Essa modificação ocorreu no sistema de arquivos do usuário e evitou a detecção. Portanto, mesmo que o dispositivo do cliente tenha sido atualizado com versões do FortiOS que corrigiam as vulnerabilidades originais, esse link simbólico pode ter sido deixado para trás, permitindo que o agente de ameaça mantivesse acesso somente leitura aos arquivos no sistema de arquivos do dispositivo, o que pode incluir configurações.
Mas se o cliente nunca tiver habilitado o SSL-VPN, ele não será afetado por esse problema.
Como parte da investigação, a Fortinet realizou varreduras para identificar dispositivos afetados usando telemetria interna e em colaboração com organizações terceirizadas. Os dados indicam que a atividade desse agente de ameaça não foi direcionada a uma região ou setor específico.
Ao descobrir a nova técnica, a Fortinet tomou medidas para mitigar o problema e equilibrar os diferentes níveis de higiene cibernética e os desafios que o cliente pode enfrentar. Os esforços de mitigação da Fortinet incluíram:
- Uma assinatura AV/IPS foi criada para detectar e limpar esse link simbólico dos dispositivos afetados.
- Foram feitas alterações nas versões mais recentes para detectar e remover o link simbólico e garantir que o SSL-VPN forneça apenas os arquivos esperados.
- Comunicações proativas incentivando os clientes a atualizarem seus dispositivos, equilibrando cuidadosamente nossas comunicações para proteger contra novos comprometimentos inadvertidos, ao mesmo tempo em que cumprimos nosso compromisso com a transparência responsável.
Especificamente para as descobertas detalhadas neste blog, lançamos diversas mitigações do FortiOS, incluindo:
- FortiOS 7.4, 7.2, 7.0, 6.4: O link simbólico foi sinalizado como malicioso pelo mecanismo AV/IPS para que fosse removido automaticamente se o mecanismo fosse licenciado e habilitado.
- FortiOS 7.6.2, 7.4.7, 7.2.11 e 7.0.17, 6.4.16: atualizar para esta versão removerá o link simbólico malicioso.
- FortiOS 7.6.2, 7.4.7, 7.2.11 e 7.0.17, 6.4.16: A interface de usuário SSL-VPN foi modificada para impedir o fornecimento de links simbólicos maliciosos.
Entrando em contato diretamente com os clientes identificados como afetados por esse problema com base na telemetria disponível, a Fortinet recomendou:
- Atualizar todos os dispositivos para 7.6.2, 7.4.7, 7.2.11 e 7.0.17 ou 6.4.16.
- Revisar a configuração de todos os dispositivos.
- Tratar todas as configurações como potencialmente comprometidas e siga as etapas recomendadas abaixo para recuperar:
É de extrema importância também que todas as organizações mantenham seus dispositivos atualizados.
Acredita-se que os invasores tenham aproveitado falhas de segurança conhecidas e agora corrigidas, incluindo, mas não se limitando a, CVE-2022-42475 , CVE-2023-27997 e CVE-2024-21762 .
O CERT-FR comunicou estar ciente de uma campanha massiva, com vários dispositivos comprometidos na França. Durante as operações de resposta a incidentes, o CERT-FR tomou conhecimento de comprometimentos que ocorreram já no início de 2023. O editor lançou correções de bugs para as ramificações 6.4.x, 7.0.x, 7.2.x, 7.4.x e 7.6.x. Atualizar para uma dessas versões remove os arquivos maliciosos. No caso de usar uma versão que não é mais suportada, o CERT-FR recomenda fortemente a migração para uma versão corretiva. Para usuários com um contrato de suporte e uma licença IPS ativada, o editor removeu automaticamente os arquivos maliciosos.
O CERT-FR está ciente de vários dispositivos para os quais essas condições não são atendidas. Entretanto, pontua que simplesmente remover esses itens e aplicar atualizações não é suficiente em caso de comprometimento . Nessa situação deve-se:
- isolar o equipamento comprometido da rede e executar um congelamento de dados (instantâneo para máquinas virtuais, isolamento do equipamento se for equipamento físico) para investigação posterior;
- redefinir todos os segredos em geral (senha, certificado, etc.) configurados nos dispositivos afetados;
- redefinir todos os segredos de autenticação que possam ter passado pelo equipamento afetado (se aplicável): senhas, tokens de identidade, chaves criptográficas, etc.;
- procurar por quaisquer vestígios de lateralização no resto do sistema de informação, em particular:
- buscando conexões ou tentativas de conexão com a Internet a partir do equipamento comprometido;
- em seguida, procurar esses endereços IP de destino para ver se alguma outra máquina tentou uma conexão;
- analisando logs do EDR ou logs do Windows para identificar conexões do dispositivo comprometido.
- identificar as contas de domínio do Active Directory que seriam configuradas no equipamento suspeito e então:
- verificar a atividade realizada a partir desta conta;
- redefinir os segredos associados a essas contas para impedir que o invasor consiga reutilizar quaisquer credenciais obtidas no equipamento em outro lugar.

Benjamin Harris, o CEO da watchTowr, disse que o incidente é preocupante por dois motivos. “Primeiro, a exploração está se tornando significativamente mais rápida do que as organizações conseguem corrigir. E os invasores estão comprovada e profundamente cientes desse fato. Em segundo lugar, e mais assustador, vimos, inúmeras vezes invasores implantando recursos e backdoors após exploração rápida, projetados para sobreviver aos processos de aplicação de patches, atualizações e redefinições de fábrica nos quais as organizações passaram a confiar para mitigar essas situações e manter a persistência e o acesso às organizações comprometidas.” Harris também disse que implantações de backdoor foram identificadas na base de clientes do watchTowr e que estão “vendo impacto em organizações que muitos claramente chamariam de infraestrutura crítica”.