Palo Alto: a falha de configuração que ninguém percebeu porque o firewall estava no caminho
Em 2024, uma falha na configuração padrão do PAN-OS levava à criação de uma rota para o tráfego de internet passar por dentro do firewall, e isso não aparecia em nenhum painel.
Em abril de 2024, a Palo Alto Networks publicou a CVE-2024-3400, uma falha de configuração no sistema operacional dos seus firewalls. A falha criava uma rota estática para o endereço de um servidor de detecção de ameaças, e essa rota fazia com que o tráfego da internet pudesse entrar na rede interna contornando o próprio firewall.
O detalhe que tornou a falha mais perceptível foi a forma como ela se manifestava. O traffic de entrada continuava passando pelo firewall, e as políticas eram aplicadas normalmente. A diferença era que o tráfego de saída, e apenas parte dele, podia contornar a inspeção. O sintoma, para quem não conhecia a causa, era o mesmo de uma configuração de proxy errada: alguns sites deixavam de funcionar, e a equipe de rede passava dias sem entender o motivo.
A campanha de exploração, o ProxyNotShell, apareceu semanas depois, e explorava justamente o que a falha permitia. Os dispositivos comprometidos eram usados para interceptar tráfego, Installing persistência e, em alguns casos, para Credentials.
A lição é que a configuração padrão de um produto precisa ser entendida, não aceita. O firewall estava funcionando, a política estava correta, e ainda assim existia um caminho que passava ao largo de tudo. E a segunda é sobre detecção: quando um serviço começa a falhar de forma inexplicável, a primeira hipótese não deveria ser o aplicativo, e sim a infraestrutura que ele atravessa.
O detalhe que tornou a falha mais perceptível foi a forma como ela se manifestava. O traffic de entrada continuava passando pelo firewall, e as políticas eram aplicadas normalmente. A diferença era que o tráfego de saída, e apenas parte dele, podia contornar a inspeção. O sintoma, para quem não conhecia a causa, era o mesmo de uma configuração de proxy errada: alguns sites deixavam de funcionar, e a equipe de rede passava dias sem entender o motivo.
A campanha de exploração, o ProxyNotShell, apareceu semanas depois, e explorava justamente o que a falha permitia. Os dispositivos comprometidos eram usados para interceptar tráfego, Installing persistência e, em alguns casos, para Credentials.
A lição é que a configuração padrão de um produto precisa ser entendida, não aceita. O firewall estava funcionando, a política estava correta, e ainda assim existia um caminho que passava ao largo de tudo. E a segunda é sobre detecção: quando um serviço começa a falhar de forma inexplicável, a primeira hipótese não deveria ser o aplicativo, e sim a infraestrutura que ele atravessa.
Leia também
Segurança da informação
Duas falhas de execução remota de código no PHP atingem todas as instalações da web
Em 21 de outubro de 2026 o PHP corrigiu duas falhas críticas que permitem executar código sem qualquer autenticação. Quem tem site em PHP precisa atualizar hoje.
LGPD e proteção de dados
Seu CPF vazou: o que fazer nas próximas 48 horas
A maior parte dos vazamentos de CPF é usada para golpe, e os golpes que mais dão certo começam nos primeiros dias.
IA e segurança
A era da IA no trabalho: o que mudou de verdade
A inteligência artificial mudou a forma de trabalhar, e junto trouxe um conjunto novo de falhas que os processos antigos não esperavam.
Segurança da informação
Sua empresa tem antivírus e ainda assim já foi invadida
A sensação de segurança atrasa a ação, e a maioria dos incidentes não depende de ataque sofisticado.