Uma loja Magento pode estar em produção, operando normalmente e gerando pedidos — e ainda assim apresentar comprometimentos não detectados por meses. Neste caso real, a HEX identificou mais de 50 backdoors ativos, permissões 777 em milhares de arquivos e uma infraestrutura sem controles mínimos de segurança. O core da aplicação estava atualizado; os pontos de risco estavam no ambiente ao redor. Um alerta sobre governança de ativos digitais: esse tipo de comprometimento pode permanecer ativo sem ser percebido, especialmente na ausência de auditoria contínua.

Todo dia recebemos um pedido que começa mais ou menos assim:

“Precisamos de uma auditoria completa na nossa infraestrutura Magento. A loja está no ar, mas sentimos que a operação não está íntegra.”

Esse é o sintoma de um ativo digital comprometido. Diferente de uma falha pontual de vendas, aqui o problema é estrutural: o negócio funciona, os pedidos são aprovados, o marketing opera — mas por baixo, alguém não autorizado tem controle parcial ou total da sua plataforma.

Foi exatamente o que encontramos em um projeto recente: uma loja Magento 2.4.7-p9 em produção, centenas de pedidos diários, equipes trabalhando normalmente. E um detalhe crítico: a loja estava comprometida há mais de quatro meses. Ninguém sabia.

Nosso trabalho foi claro: realizar uma auditoria completa de segurança, infraestrutura e performance, identificar cada ponto de falha e entregar um plano de correção executado em ambiente controlado, sem afetar a operação em produção.

O que descobrimos — e como resolvemos — compartilhamos a seguir. Não como alarme, mas como lição de governança sobre ativos digitais.

Metodologia Aplicada

Nossa abordagem segue uma metodologia de cinco fases, desenvolvida ao longo de dezenas de auditorias em lojas Magento de todos os portes. O princípio central: não interferir na operação antes de compreender integralmente o estado do ativo.

Fase 1 — Reconhecimento Passivo

Sem qualquer alteração no servidor, coletamos dados de infraestrutura, configurações de serviços (Nginx, PHP-FPM, MySQL, Redis, Varnish), permissões de arquivos, serviços ativos e versões de software.

Princípio: “Nunca toque no servidor antes de entender o que está rodando.”

Fase 2 — Varredura de Segurança

Busca ativa por backdoors, web shells, arquivos com extensões suspeitas (.php8, .phar, .phtml) em diretórios que deveriam conter apenas imagens. Verificação de permissões 777, serviços desnecessários expostos, credenciais em texto puro e vetores de upload desprotegidos.

Fase 3 — Análise de Código

Identificação de práticas inseguras no código customizado: uso de ObjectManager::getInstance(), referências a bibliotecas deprecated (Zend_), funções perigosas (eval(), base64_decode()) e módulos de terceiros sem validação.

Fase 4 — Análise de Logs e Comportamento

Investigação dos arquivos de log para identificar padrões de erro, falhas recorrentes de cron, tentativas de injeção e sinais de atividade maliciosa recente.

Fase 5 — Cruzamento com Base de Vulnerabilidades

Cada descoberta foi confrontada com o Adobe Security Bulletin mais recente e nossa matriz interna de vulnerabilidades Magento, para verificar se a versão instalada cobria as correções conhecidas.

O Que Identificamos — O Estado Real do Ativo

Backdoors Ativos — 50+ Arquivos Escondidos em pub/media/

O achado mais crítico: mais de 50 arquivos com extensão .php8 estavam escondidos dentro de pub/media/customer_address/, um diretório que deveria conter apenas fotos e documentos de clientes.

Esses arquivos eram PHP Phar archives — executáveis disfarçados com extensão que contornava filtros básicos. Todos compartilhavam o mesmo hash MD5, indicando um único atacante com acesso persistente.

Além dos .php8, encontramos 2 arquivos .phar em pub/media/custom_options/ — backdoors do tipo PolyShell, que são imagens GIF válidas e arquivos PHP Phar ao mesmo tempo.

A atividade era contínua: os arquivos vinham sendo colocados no servidor desde novembro do ano anterior, com uploads regulares até poucos dias antes da nossa auditoria. O ativo estava sendo usado como plataforma de apoio para o invasor.

Permissões Totalmente Abertas — 80.000+ Arquivos com 777

Encontramos 7.227 diretórios e 74.981 arquivos com permissão 777 em pub/media/. Na prática, qualquer usuário ou processo com acesso mínimo ao servidor podia ler, modificar ou apagar esses arquivos — incluindo a instalação de novos backdoors. Uma porta dos fundos escancarada.

Servidor Sem Travas — PHP Ilimitado

O PHP estava configurado sem limites operacionais:

• memory_limit = -1 (um script pode consumir toda a RAM disponível)

• max_execution_time = 0 (um script pode rodar indefinidamente)

Isso significa que, se um backdoor fosse executado, não existia barreira de contenção. O ativo inteiro poderia ser drenado ou sequestrado.

10 Versões do PHP Rodando Simultaneamente

O servidor tinha 10 versões diferentes do PHP-FPM ativas ao mesmo tempo — desde PHP 7.1 até PHP 8.5. Cada versão rodando como serviço independente consumia memória e, mais importante, representava uma superfície de ataque adicional.

PHP 7.1, 7.2, 7.3, 7.4 e 8.0 estão fora de suporte há anos — vulnerabilidades conhecidas nunca receberão correção. Manter esses serviços ativos é expor o ativo a riscos perfeitamente evitáveis.

FTP Ativo — Porta 21 Exposta

Um servidor ProFTPD estava ativo e acessível externamente. FTP transmite credenciais em texto puro e era um vetor óbvio para upload de arquivos maliciosos. Um protocolo obsoleto em qualquer política de segurança de ativos digitais.

Logs Acumulados — 1.2 GB de Erros

O exception.log havia crescido a 1.1 GB. O cron.log tinha 55 MB. Centenas de milhares de erros acontecendo a cada carregamento de página — consumindo disco, degradando performance e mascarando ações maliciosas.

81 Usos de ObjectManager Direto no Código

Boas práticas do Magento recomendam o uso de Dependency Injection e Repositórios. Encontramos 81 instâncias de ObjectManager::getInstance() em módulos customizados — uma prática que dificulta manutenção e abre brechas desnecessárias.

156 Referências a Classes Zend_ Deprecated

O Magento migrou de Zend_ para Laminas_ há anos. Encontramos 156 referências a classes Zend_ no código customizado — comprometendo a compatibilidade futura e a evolução do ativo.

A Boa Notícia: O Que Já Estava Íntegro

Nem tudo estava comprometido. O Magento core estava na versão mais recente e segura disponível (2.4.7-p9), com todos os patches da Adobe aplicados. Os indexers estavam em dia, o cache funcionava corretamente, e o Fail2ban protegia contra ataques de força bruta.

O problema estava fora do core Magento — na infraestrutura, nas permissões e nos vetores de upload. Ou seja, o ativo principal estava bem construído, mas o ambiente ao redor foi negligenciado.

Resultados da Correção — Restauração da Integridade

Trabalhamos primeiro em um ambiente de staging, aplicando cada correção de forma controlada e documentada. O resultado foi a recuperação plena da integridade operacional.

Antes vs Depois — Staging

 

Score de segurança: de 25/100 para 90/100. O ativo foi restaurado à sua condição íntegra.

Conclusão

A loja que auditamos está funcionando normalmente. O Magento core estava atualizado e seguro. O problema estava em tudo que está ao redor: permissões, serviços, vetores de upload e configurações do servidor.

Essa é uma lição recorrente em auditorias de lojas Magento em produção: não basta manter o core atualizado. A segurança de uma loja — enquanto ativo digital — é tão forte quanto o mais fraco de seus elos. Em muitos casos, esse elo está em uma configuração negligenciada de infraestrutura, permissões de diretório ou serviços ativos sem controle adequado.

Se você opera uma loja Magento e nunca realizou uma auditoria completa — abrangendo não apenas a aplicação, mas todo o ambiente de infraestrutura — este é um ponto de atenção. Comprometimentos podem permanecer ativos por longos períodos sem sinais evidentes, especialmente na ausência de monitoramento e validação contínua.

A identificação de comprometimento ou vulnerabilidades requer análise técnica individual do ambiente. Este conteúdo tem caráter ilustrativo, baseado em um caso real.

Artigo preparado pela equipe técnica da HEX Ecommerce Solutions.
hexcommerce.com.br | [email protected]