Sexta, 2h17. O SOC de uma processadora de pagamentos brasileira disparou. Chamou a Tech86. O analista de plantão disse: "cryptominer, já vimos isso." Quase deixou passar. Nós chegamos e a primeira coisa que bateu foi a discrepância. O que parecia um cryptominer clássico era, na verdade, dois atores distintos operando no mesmo ambiente — e o cryptominer era a cortina de fumaça.
O alerta que quase foi ignorado
O XMRig consumia CPU em três servidores. Sinal clássico de cryptominer — o SOC já tinha visto isso antes. O analista de plantão estava pronto para marcar como "resolvido" após contenção padrão. Mas quando chegamos, a primeira coisa que nos chamou a atenção foi a discrepância.
Havia tráfego de saída para dois domínios de C2 completamente diferentes. Não eram apenas domínios distintos — eram protocolos diferentes, com padrões temporais distintos. Um operava no horário comercial da Europa, janela de 9h às 18h no fuso de Frankfurt. O outro atuava na madrugada brasileira, entre 1h e 4h. Essa divergência temporal e de protocolo era o primeiro indicador de que não estávamos lidando com fases de uma única campanha, mas com campanhas separadas. Dois atores. Mesmo ambiente.
A discrepância que revelou dois atores
O primeiro ator tinha entrado 48 horas antes por uma vulnerabilidade recém-divulgada. Automatizado, rápido, instalou o cryptominer e estabeleceu persistência com web shell. O segundo explorou a mesma vulnerabilidade horas depois, mas com objetivo diferente: exfiltração de certificados digitais e dados de transações PIX.
A separação era invisível sem cruzar telemetria. Os artefatos do segundo ator pareciam "fase dois" da mesma campanha. Sem correlacionar logs de identidade, telemetria de endpoint e tráfego de nuvem, a equipe interna não teria como distinguir dois atores de um único ataque em estágios. Foi esse cruzamento que revelou a verdade: dois atores, duas motivações, uma porta de entrada.
O primeiro ator queria compute gratuito. O segundo queria ativos negociáveis — certificados que assinam transações e dados de PIX que valem dinheiro no mercado negro. A vulnerabilidade recém-divulgada foi a porta aberta que ambos encontraram, mas o que cada um procurou dentro da infraestrutura foi completamente diferente.
O cryptominer como cortina de fumaça
O cryptominer funcionou como cortina de fumaça. A equipe interna focou em conter a mineração — afinal, era o sinal mais óbvio. Enquanto isso, o segundo ator operava sem ser notado, exfiltrando certificados digitais e dados de transações PIX.
É aqui que a maioria das respostas a incidente falha. O SOC demarca o cryptominer como "resolvido", fecha o ticket, e o segundo ator continua operando. O runbook típico de SOC diz: identifique o minerador, isole o host, remova a persistência, feche o ticket. Esse runbook funciona quando há um único ator. Quando há dois, conter o primeiro dá ao segundo exatamente o que ele precisa: silêncio operacional.
Cryptominer em ambiente financeiro raramente é só cryptominer. É o canário. Se alguém está minerando na sua infraestrutura de pagamentos, a pergunta certa não é "como removemos isso?" É: quem mais entrou pela mesma porta?
A evacuação coordenada — kill-switch simultâneo
A solução foi evacuação coordenada. Contemos um ator de cada vez e o outro se esconde — você acha que está limpo, e a violação continua. Na Tech86, mapeamos toda a superfície de acesso antes de agir. Web shells, certificados comprometidos, contas persistidas, segmentos afetados — tudo inventariado antes de qualquer ação.
Depois, kill-switch simultâneo: revogação de certificados, isolamento de segmentos, remoção de web shells e recredenciamento total em uma janela de 14 minutos. Os 14 minutos foram divididos em três blocos. Nos primeiros 4 minutos, revogamos todos os certificados digitais comprometidos e invalidamos as sessões ativas baseadas neles. Dos minutos 4 ao 10, isolamos os segmentos de rede afetados e removemos os web shells dos três servidores. Dos minutos 10 ao 14, executamos recredenciamento total — senhas, chaves SSH, tokens de API, contas de serviço.
Ação sequencial daria tempo para o segundo ator se reconfigurar. A janela curta é o que garante que ambos os atores sejam contidos ao mesmo tempo, sem oportunidade de reação.
Dwell time e a pergunta certa
Segundo o relatório M-trends da Mandiant/FireEye, o dwell time global mediano é 14 dias. Aqui, foram 2 dias até a exfiltração começar — significativamente abaixo da mediana. Se o SOC tivesse demarcado o cryptominer como "resolvido" sem investigar mais fundo, o segundo ator teria operado por semanas.
A lição é clara. Cryptominer em ambiente financeiro raramente é só cryptominer. É o canário. A pergunta certa não é "como removemos o minerador?" — é "quem mais entrou pela mesma porta?" Essa mudança de perspectiva é o que separa uma contenção superficial de uma resposta a incidente completa.
Conclusão
Nós repetimos: cryptominer em ambiente de pagamentos é o canário, não a ameaça. Quando o SOC de uma processadora brasileira disparou naquela sexta às 2h17, o instinto foi tratar como cryptominer clássico. O que encontramos foram dois atores, dois objetivos, uma porta de entrada — e o cryptominer era a cortina de fumaça que escondia a exfiltração de certificados e dados PIX.
A diferença entre "resolvido" e "realmente resolvido" está em cruzar telemetria de identidade, endpoint e nuvem antes de agir, e em executar um kill-switch simultâneo em vez de contenção sequencial. Na Tech86, nós ajudamos empresas a responder a incidentes complexos — antes que o canário se torne a única coisa que você ouve.