Ransomware Pay2Key mira servidores Linux e eleva risco em ambientes críticos
O ransomware Pay2Key passou a explorar, de forma sistemática, servidores Linux por meio de uma nova variante desenvolvida especificamente para ambientes de missão crítica. A mudança de foco amplia o nível de alerta para empresas que dependem intensamente de infraestrutura baseada em Linux para manter aplicações, bases de dados e operações em nuvem em funcionamento contínuo.
De acordo com análises recentes, a amostra identificada como Pay2Key.I2 vem sendo observada em atividade desde o final de agosto de 2025. Diferentemente de ondas anteriores de ransomware que priorizavam estações de trabalho e endpoints de usuários finais, essa campanha concentra seus esforços em servidores corporativos, hosts de virtualização e workloads em ambientes de cloud computing.
Essa estratégia demonstra clara mudança de postura dos operadores: em vez de buscar volume de máquinas infectadas, o foco está em atingir diretamente a espinha dorsal da infraestrutura corporativa. Ao comprometer servidores que hospedam serviços essenciais, o impacto operacional é imediato e profundo, aumentando o poder de negociação dos criminosos no momento da cobrança do resgate.
Pesquisadores da Morphisec apontam que a variante para Linux é totalmente guiada por arquivos de configuração e só consegue ser executada com privilégios de root. Isso indica que o Pay2Key não é usado na fase inicial de invasão, mas entra em cena quando o atacante já obteve alto nível de acesso ao ambiente. Em outras palavras: quando o ransomware é disparado, a rede provavelmente já está sob controle do invasor há algum tempo.
Antes de iniciar o processo de criptografia dos dados, o malware executa uma etapa de preparação voltada a enfraquecer a defesa do sistema e reduzir qualquer chance de interrupção do ataque. O código malicioso interrompe serviços, finaliza processos em execução e desativa mecanismos de segurança fundamentais no ecossistema Linux, como SELinux e AppArmor.
A desativação desses controles é particularmente grave. SELinux e AppArmor foram criados para impor políticas de controle de acesso mais rígidas, limitando o que cada processo pode fazer no sistema. Ao neutralizá-los, o Pay2Key remove importantes barreiras que poderiam impedir ou ao menos restringir a ação do ransomware. Justamente no momento em que o ataque se torna mais agressivo, a superfície de proteção é drasticamente reduzida.
Outro ponto crítico é a forma como o malware garante persistência. A análise técnica indica que o Pay2Key cria uma entrada de cron para ser executado novamente após a reinicialização do servidor. Isso significa que, mesmo que a equipe de TI tente conter o incidente por meio de um simples reboot, o código volta a ser carregado automaticamente, mantendo a operação criminosa ativa e tornando a resposta rápida muito mais complexa.
O potencial de dano dessa campanha é elevado, sobretudo porque os alvos típicos são ambientes que concentram componentes altamente sensíveis: bancos de dados corporativos, backends de aplicações de negócio, hipervisores que hospedam dezenas ou centenas de máquinas virtuais, além de cargas críticas em nuvem. Um único servidor comprometido pode impactar múltiplos sistemas e serviços, desencadeando uma reação em cadeia de indisponibilidade.
Para organizações que dependem de alta disponibilidade, como empresas de telecomunicações, instituições financeiras, provedores de serviços de TI, indústrias e hospitais, esse cenário é particularmente preocupante. A paralisação de serviços centrais pode significar indisponibilidade de canais de atendimento, interrupção de operações industriais, atraso em transações financeiras ou até impacto direto na assistência a pacientes, em casos de ambientes hospitalares.
A evolução do Pay2Key também se conecta a um movimento mais amplo do mercado de cibercrime, que passou a mirar infraestrutura crítica justamente porque ela concentra ativos de alto valor. Nos últimos anos, observou-se crescente profissionalização de grupos especializados em ataques a data centers, ambientes de nuvem e sistemas de virtualização, muitas vezes com planejamento semelhante ao de operações militares, envolvendo reconhecimento extenso, movimentação lateral silenciosa e ataques coordenados.
Paralelamente, houve forte avanço no ecossistema de defesa. Empresas especializadas em cibersegurança ofensiva, que simulam ataques reais para encontrar brechas em ambientes corporativos, passaram a receber investimentos que, somados, ultrapassam a casa do bilhão de dólares. Esse volume de capital mostra que o mercado reconhece a necessidade de testar continuamente a resiliência das infraestruturas, inclusive as baseadas em Linux, que antes eram vistas como “mais seguras por natureza”.
Nesse contexto, a demanda por serviços e soluções de Threat Intelligence também cresceu de forma consistente. As organizações perceberam que não basta reagir aos incidentes; é preciso antecipar movimentos de grupos como os operadores do Pay2Key. Informações sobre novas variantes, indicadores de comprometimento, táticas, técnicas e procedimentos, bem como campanhas em curso, tornam-se elementos essenciais para ajustar controles defensivos e priorizar mitigação antes que o ataque atinja seu estágio mais destrutivo.
Outra resposta importante a esse cenário é a adoção de metodologias de pentest mais maduras e orientadas a cenários reais de ataque. Em vez de avaliações pontuais focadas apenas em aplicações ou em perímetro, cresce o uso de testes que simulam cadeias completas de ataque, desde o acesso inicial até o comprometimento de servidores críticos de Linux, hosts de virtualização e ambientes em nuvem. Esse tipo de abordagem ajuda a revelar falhas de configuração, credenciais fracas, ausência de segmentação e falta de monitoramento em pontos sensíveis.
Para reduzir o risco de ser vítima de ameaças como o Pay2Key, organizações que utilizam Linux em larga escala precisam reforçar práticas de segurança básicas, mas muitas vezes negligenciadas. Isso inclui controle rigoroso de privilégios de root, adoção de autenticação multifator para acessos administrativos, segmentação de rede para separar camadas de aplicação, banco de dados e gestão, além de políticas estritas de atualização e correção de vulnerabilidades.
Também é fundamental blindar os próprios mecanismos de proteção, como SELinux e AppArmor, evitando que sejam facilmente desativados por scripts ou serviços. Monitoramento de integridade de configurações, uso de listas de controle de acesso reforçadas e auditoria constante de alterações em arquivos sensíveis ajudam a detectar tentativas de enfraquecimento da postura de segurança antes do estágio final do ataque.
Outra camada indispensável é a de visibilidade e detecção. Soluções de monitoramento de comportamento em servidores, análise de logs, sistemas de detecção e resposta a ameaças (EDR/XDR) com foco em Linux podem identificar atividades anômalas, como encerramento em massa de processos, alterações em políticas de segurança ou criação suspeita de tarefas em cron, que podem indicar estágio preparatório de um ransomware.
Planos robustos de backup e recuperação também são peça-chave. Backups offline ou imutáveis, armazenados em locais segregados da rede principal, permitem restaurar serviços críticos sem ceder à pressão dos operadores de ransomware. Porém, esses planos só são eficazes se forem testados regularmente, com simulações realistas de desastre, garantindo que a restauração de servidores Linux e workloads em nuvem possa ocorrer em prazos compatíveis com as necessidades do negócio.
Por fim, a governança de segurança precisa acompanhar a evolução técnica. A combinação de políticas claras, treinamento contínuo das equipes de infraestrutura e desenvolvimento, simulações de incidentes e alinhamento entre áreas de TI, segurança e negócio é o que permite responder de forma coordenada a ataques sofisticados. Em um cenário em que o Pay2Key e outras famílias de ransomware passam a mirar diretamente o coração da infraestrutura, tratar a segurança de servidores Linux como prioridade estratégica deixou de ser opção e passou a ser questão de sobrevivência operacional.