Prioridade 1
Em exploração

Cisco FMC: falhas exploradas levam ao ransomware Qilin

11 de setembro de 2026

Atacantes estão explorando duas vulnerabilidades no Cisco Secure Firewall Management Center para roubar credenciais, manter acesso à rede e preparar ataques de ransomware.

Uma das cadeias observadas avançou até a implantação do Qilin. Nesse caso, o operador usou o FMC como ponto de apoio para reconhecer o domínio, acessar serviços internos, desativar controles de segurança e selecionar os endpoints que receberiam o ransomware.

Por isso, as organizações precisam combinar três ações: aplicar os hotfixes, reduzir a exposição da interface de gerenciamento e investigar um possível comprometimento anterior. O patch impede novas tentativas de exploração, mas não remove web shells, túneis, credenciais expostas ou outros mecanismos de persistência que o atacante já tenha instalado.

Em resumo

Três clusters de ameaça estão explorando as falhas CVE 2026 20079 e CVE 2026 20316 no Cisco Secure FMC. As atividades incluem execução remota, coleta de credenciais, reconhecimento de rede, persistência com Cyclops Blink, movimento lateral e implantação do ransomware Qilin.

Organizações que utilizam versões vulneráveis devem aplicar os hotfixes da Cisco imediatamente. Além disso, precisam restringir o acesso à interface administrativa, revisar conexões originadas pelo FMC e procurar evidências de comprometimento em todo o período de retenção disponível.

A prioridade não depende apenas da pontuação CVSS. Afinal, o FMC ocupa uma posição relevante na infraestrutura e pode oferecer ao atacante informações sobre redes, dispositivos gerenciados, políticas e credenciais.

Quais falhas estão sendo exploradas?

Os atacantes exploram duas vulnerabilidades com características diferentes, mas complementares. Enquanto uma delas permite contornar a autenticação, a outra fornece acesso por meio de credenciais estáticas.

A CVE 2026 20079 permite contornar a autenticação do Cisco Secure FMC. A falha recebeu pontuação CVSS 10.0 e permite que um atacante remoto sem autenticação execute scripts e obtenha acesso root ao sistema operacional subjacente.

Por sua vez, a CVE 2026 20316 expõe credenciais estáticas associadas a uma conta com baixo privilégio. A vulnerabilidade recebeu pontuação CVSS 5.3. No entanto, o atacante pode combiná la com outras falhas ou abusar de recursos legítimos do FMC para ampliar seus privilégios.

A pontuação menor da segunda vulnerabilidade não representa um impacto operacional menor. Na prática, o operador ligado à cadeia do Qilin usou a CVE 2026 20316 como ponto de entrada para uma intrusão que terminou com a criptografia de endpoints.

Além disso, a CISA incluiu a CVE 2026 20079 no catálogo de vulnerabilidades conhecidas e exploradas em setembro de 2026. A agência já havia incluído a CVE 2026 20316 no catálogo KEV em julho.

A Cisco disponibilizou hotfixes para as versões afetadas. Como não existem medidas alternativas que eliminem as vulnerabilidades, controles de acesso e segmentação servem apenas para reduzir a exposição até a conclusão da atualização.

O que aconteceu no Cisco FMC?

O Cisco Talos identificou três clusters de atividade maliciosa em instâncias comprometidas do Secure FMC. Cada cluster seguiu um caminho diferente após o acesso inicial.

O primeiro buscou credenciais. O segundo estabeleceu acesso persistente e instalou o Cyclops Blink. Já o terceiro reconheceu o domínio, criou túneis para a rede interna e implantou o ransomware Qilin em endpoints selecionados.

ClusterAcesso observadoAtividade posteriorObjetivo aparente
UAT 12197Exploração da CVE 2026 20079Web shell JSP, executor JAR e consulta ao banco internoColeta de dados de autenticação
UAT 11823Exploração das falhas ou uso das credenciais estáticasReverse shell Netcat, coleta de configurações e Cyclops BlinkPersistência, exfiltração e acesso de longo prazo
UAT 11988Credenciais estáticas ligadas à CVE 2026 20316Reconhecimento, túneis, movimento lateral, desativação de antivírus e ransomwarePreparação e execução de ransomware

Como agiu o UAT 12197?

O UAT 12197 explorou a CVE 2026 20079 para instalar um web shell baseado em JSP no diretório webroot do Tomcat. Assim, o atacante criou uma interface para executar comandos remotamente no FMC.

Em seguida, o grupo instalou o arquivo malicioso cmd.jar. Esse componente recebia comandos pela linha de execução e os encaminhava ao shell Unix.

O atacante também usou o arquivo para consultar o banco interno do FMC. Com isso, buscou nomes de usuários, dados de autenticação e outras informações que poderiam ampliar o acesso ao ambiente.

Portanto, o risco não ficou restrito ao dispositivo. As credenciais obtidas no FMC poderiam abrir novos caminhos até contas, servidores e serviços internos.

Como agiu o UAT 11823?

O UAT 11823 buscou persistência e acesso de longo prazo. O Cisco Talos atribuiu o segundo cluster a esse ator com alta confiança e identificou uma sobreposição de ferramentas com o Sandworm.

Essa relação exige cautela. A pesquisa demonstra proximidade técnica entre as operações, mas não confirma que UAT 11823 e Sandworm representem necessariamente o mesmo ator.

Após o acesso inicial, o atacante substituiu o arquivo license.tmp por uma cópia maliciosa. Depois, acionou o utilitário legítimo package_info.pl, que executou o conteúdo do arquivo com privilégios root.

Como resultado, o ator estabeleceu uma reverse shell com Netcat e criou um canal de comando e controle. Além disso, scripts em Bash coletaram configurações dos dispositivos administrados pelo FMC e organizaram os dados em arquivos para exfiltração.

O grupo também instalou uma variante do Cyclops Blink. O malware oferece recursos para executar comandos, transferir arquivos, coletar credenciais, mapear a rede, capturar pacotes e resolver endereços por DNS sobre HTTPS.

Para manter o acesso após reinicializações, o atacante adicionou scripts aos diretórios de inicialização do sistema. Por isso, uma simples atualização pode não eliminar o malware nem interromper todos os mecanismos de persistência.

A coleta de configurações amplia o impacto do incidente. Mesmo depois da reconstrução do FMC, informações sobre redes, políticas e dispositivos podem continuar sob controle do atacante.

Como o ataque chegou ao Qilin?

O UAT 11988 usou o FMC como ponto de entrada para uma operação de ransomware. O ator entrou no dispositivo com as credenciais estáticas relacionadas à CVE 2026 20316.

O Cisco Talos avalia com alta confiança que o UAT 11988 atua como operador de ransomware. Além disso, a empresa considera suas ações posteriores consistentes com as técnicas observadas entre afiliados do Qilin.

No entanto, essa associação não significa que UAT 11988 seja outro nome para todo o grupo Qilin. Ela indica que o cluster observado empregou ferramentas e procedimentos compatíveis com operações desse ransomware.

Depois do acesso, o operador abusou do utilitário legítimo package_info.pl para executar comandos com privilégios root. Em seguida, coletou nomes de hosts, endereços IP, listagens de diretórios, contas de serviço, credenciais de MySQL e informações sobre o domínio.

O reconhecimento também alcançou controladores de domínio, servidores de arquivos, bancos de dados, servidores de identidade e outros sistemas críticos. Assim, o atacante construiu uma lista de endpoints para as próximas etapas.

Na sequência, o operador implantou um proxy SOCKS5 e criou um túnel SSH reverso. Esses canais permitiram encaminhar tráfego até serviços internos como LDAP, LDAPS, Kerberos, SMB, NetBIOS e Windows Remote Management.

O atacante também utilizou ferramentas como Impacket e Invoke TheHash. Com elas, trabalhou com as credenciais obtidas, acessou compartilhamentos administrativos e executou comandos em outros sistemas.

Por fim, o operador implantou componentes para desativar ferramentas antivírus. Depois dessa preparação, executou o ransomware Qilin nos endpoints selecionados.

O ransomware, portanto, não operou apenas dentro do FMC. O dispositivo funcionou como ponto de pivô para reconhecimento, acesso a credenciais, conectividade interna e movimento lateral.

Por que as falhas são críticas?

As falhas são críticas porque atingem uma plataforma que administra controles de segurança e concentra contexto sobre a rede. Dessa forma, o comprometimento entrega ao atacante uma posição privilegiada para entender o ambiente e construir novos caminhos de ataque.

O FMC pode conter informações sobre dispositivos gerenciados, redes, integrações, políticas e contas administrativas. Além disso, sua posição pode permitir conexões com serviços que não estão diretamente expostos à internet.

Esse contexto muda a priorização. A organização não deve avaliar o risco apenas pela pontuação CVSS, pois a função do ativo e seu alcance na rede também determinam o impacto.

A CVE 2026 20316 ilustra esse problema. Embora tenha pontuação inferior à CVE 2026 20079, ela forneceu o acesso inicial para uma cadeia que avançou até o ransomware.

Por isso, programas de gestão de vulnerabilidades precisam combinar severidade, exploração ativa, exposição externa, criticidade do ativo e posição no caminho de ataque. A DataRunk aprofunda esse modelo no artigo O colapso do patching tradicional na era da weaponization baseada em IA.

Empresas brasileiras podem ser afetadas?

Sim. Empresas brasileiras podem ser afetadas quando operam versões vulneráveis do Cisco Secure FMC e oferecem algum caminho de acesso à interface de gerenciamento.

As informações públicas não detalham a distribuição das vítimas por país ou setor. Portanto, não há evidência suficiente para afirmar que os atacantes direcionaram essa campanha especificamente ao Brasil.

A ausência de um recorte regional, no entanto, não reduz o risco. As técnicas observadas podem atingir qualquer organização que mantenha uma instância vulnerável e acessível.

Empresas com operações distribuídas, ambientes híbridos e muitos segmentos podem enfrentar um impacto maior. Afinal, o comprometimento do FMC pode afetar credenciais, configurações, conectividade, disponibilidade de sistemas e continuidade de processos críticos.

Além disso, organizações reguladas podem enfrentar consequências para auditoria, governança, gestão de terceiros e proteção de dados. Nesse contexto, preservar evidências e registrar as decisões de resposta torna se tão importante quanto instalar o patch.

Como o ataque avança até o ransomware?

O ataque avança em uma sequência que conecta acesso inicial, persistência, descoberta, movimento lateral e impacto. Assim, a vulnerabilidade representa apenas a primeira etapa da intrusão.

  1. Acesso inicial: o atacante explora a interface web ou utiliza as credenciais estáticas do FMC.
  2. Execução: o ator usa comandos Unix, web shell JSP, executor JAR e utilitários legítimos do dispositivo.
  3. Persistência: o grupo cria scripts de inicialização e instala o Cyclops Blink.
  4. Acesso a credenciais: o atacante consulta o banco interno e coleta materiais de autenticação nos sistemas Windows.
  5. Descoberta: o operador enumera processos, hosts, diretórios, servidores, controladores de domínio e contas de serviço.
  6. Movimento lateral: o grupo acessa compartilhamentos administrativos e utiliza Windows Remote Management.
  7. Comando e controle: o ator estabelece reverse shell Netcat, proxy SOCKS5 e túnel SSH reverso.
  8. Evasão: o operador tenta desativar ou contornar ferramentas antivírus.
  9. Impacto: o atacante implanta o ransomware nos endpoints selecionados.

A detecção desse fluxo exige correlação entre eventos do FMC, rede, identidade, servidores e endpoints. Caso cada equipe analise apenas sua própria telemetria, os sinais podem parecer eventos isolados.

Por exemplo, uma alteração no FMC, uma conexão SSH incomum e um acesso por WinRM podem não gerar contexto suficiente separadamente. Quando a organização conecta os três eventos, porém, o caminho de ataque se torna mais claro.

Esse processo depende de uma camada de inteligência capaz de transformar dados distribuídos em hipóteses de investigação. O artigo Threat intelligence: como usá la para avançar sua estratégia em segurança explica como conectar fontes externas, telemetria interna e contexto operacional.

Como responder às falhas no Cisco FMC?

A resposta deve começar pelo inventário e pela aplicação dos hotfixes. Ao mesmo tempo, as equipes precisam reduzir a exposição do plano de gestão e investigar sinais de acesso anterior.

Gestão de vulnerabilidades

  • Identifique todas as instâncias físicas e virtuais do Cisco Secure FMC.
  • Confirme as versões instaladas e verifique quais advisories se aplicam a cada ativo.
  • Aplique os hotfixes da CVE 2026 20079 e da CVE 2026 20316.
  • Use o Cisco Software Checker para validar a exposição das versões instaladas.
  • Confirme a versão executada depois da manutenção.
  • Registre responsáveis, exceções, controles compensatórios e risco residual.
  • Execute uma nova verificação para comprovar a remediação.

Além disso, o time deve avaliar a posição do FMC no caminho de ataque. Uma instância com acesso a redes críticas ou contas privilegiadas exige prioridade maior do que um ativo com alcance limitado.

Essa abordagem aproxima a gestão de vulnerabilidades do modelo de Continuous Threat Exposure Management. A diferença entre os dois processos está detalhada no artigo Diferença entre vulnerability management e CTEM.

Infraestrutura e redes

  • Remova a exposição pública da interface de gerenciamento sempre que possível.
  • Restrinja o acesso a redes administrativas, endereços autorizados e conexões protegidas.
  • Revise os acessos concedidos a fornecedores, filiais e equipes descentralizadas.
  • Limite as conexões de saída originadas pelo FMC ao que a operação realmente exige.
  • Verifique a segmentação entre o plano de gestão e os serviços internos.
  • Revise o acesso do FMC a LDAP, Kerberos, SMB, NetBIOS e Windows Remote Management.

Esses controles reduzem a superfície disponível para o atacante. Ainda assim, eles não substituem os hotfixes nem eliminam uma intrusão que já ocorreu.

SOC e CSIRT

  • Procure arquivos JSP desconhecidos no diretório webroot do Tomcat.
  • Investigue a presença de home.jsp e cmd.jar.
  • Compare os hashes encontrados com os indicadores publicados pelo Cisco Talos.
  • Revise alterações e execuções associadas a /var/tmp/license.tmp.
  • Investigue execuções incomuns de package_info.pl, principalmente quando envolvem license.tmp.
  • Procure chamadas ao OmniQuery.pl destinadas a consultar usuários e dados de autenticação.
  • Busque processos Netcat, shells interativos e conexões de saída incompatíveis com o comportamento esperado.
  • Revise scripts novos ou modificados em diretórios de inicialização, incluindo /etc/init.d/.
  • Investigue proxies SOCKS5, túneis SSH reversos e conexões internas originadas pelo FMC.
  • Correlacione acessos a LDAP, Kerberos, SMB e Windows Remote Management com atividades de descoberta.
  • Procure falhas ou desativações simultâneas de ferramentas antivírus nos endpoints.

Ao encontrar um desses sinais, o SOC deve ampliar a investigação. Um web shell no FMC, por exemplo, exige análise das contas acessíveis, dos dispositivos administrados e das conexões posteriores com a rede interna.

Threat intelligence

  • Adicione hashes, endereços IP e artefatos confirmados aos processos de hunting.
  • Revise os indicadores em todo o período de retenção disponível.
  • Monitore a evolução dos clusters UAT 12197, UAT 11823 e UAT 11988.
  • Separe evidências confirmadas de hipóteses de atribuição.
  • Atualize os perfis de ameaça e os playbooks conforme surgirem novos indicadores.
  • Compartilhe o contexto com SOC, CSIRT, infraestrutura e gestão de vulnerabilidades.

Os indicadores ajudam a localizar evidências conhecidas. Contudo, eles não substituem detecções comportamentais para execução de comandos, persistência, tunelamento, coleta de credenciais e movimento lateral.

Quais sinais devem receber prioridade?

Os sinais abaixo representam comportamentos observados nas três cadeias. Portanto, as equipes devem correlacioná los com o histórico do ativo, os usuários envolvidos e as conexões internas e externas.

SinalRisco relacionadoAção de investigação
Arquivo JSP desconhecido no webrootWeb shell e execução remotaPreservar o arquivo, validar o hash e revisar processos Java
Execução de cmd.jarExecutor de comandos maliciosoVerificar comandos filhos, consultas ao banco e conexões externas
Alteração de license.tmpAbuso do processo de instalaçãoCorrelacionar a alteração com package_info.pl e privilégios root
Conexões Netcat de saídaReverse shell e acesso remotoIdentificar destino, duração, processo responsável e comandos
Novo script em /etc/init.d/Persistência do Cyclops BlinkComparar o arquivo com o baseline e verificar o binário acionado
Proxy SOCKS5 ou túnel SSHPivô para a rede internaRevisar serviços alcançados, contas utilizadas e volume de tráfego
Acesso incomum por SMB ou WinRMMovimento lateralCorrelacionar origem, conta, horário e processos remotos
Desativação de antivírusPreparação para ransomwareElevar a prioridade e procurar sinais de criptografia

Aplicar o patch elimina o comprometimento?

Não. O hotfix corrige a vulnerabilidade, mas não remove automaticamente os artefatos que o atacante instalou antes da atualização.

Se o invasor já implantou um web shell, coletou credenciais, modificou scripts ou criou um túnel, a organização continua exposta. Por isso, a equipe precisa tratar qualquer indicador como possível evidência de incidente.

No advisory da CVE 2026 20079, a Cisco alerta que os hotfixes evitam novas explorações, mas podem não resolver um comprometimento existente. A empresa também orienta clientes com sinais de exploração a acionar o Cisco Technical Assistance Center.

Além disso, a organização deve considerar potencialmente expostas as credenciais que o FMC armazenava ou conseguia acessar. A resposta precisa incluir rotação de contas administrativas e de serviço, revisão das configurações gerenciadas e investigação dos sistemas alcançáveis pelo dispositivo.

Esse padrão também aparece em outros ataques contra appliances de borda. No artigo Zero days SonicWall expõem

blog

Quais registros de um SOC demonstram monitoramento contínuo de segurança?

por Lariana Luy Peixoto

Maturidade do SOC: como avaliar e decidir o que evoluir primeiro

por Lariana Luy Peixoto

Como um SOC terceirizado apoia os requisitos de segurança do Banco Central?

por Lariana Luy Peixoto

Já comprei as ferramentas de segurança e não vejo valor: por que acontece e o que fazer

por Roberto Mendes