Viernes, 2:17. Se disparó el SOC de una procesadora de pagamentos brasileña. Llamaron a Tech86. El analista de turno dijo: "cryptominer, ya lo vimos". Casi lo dejan pasar. Nosotros llegamos y lo primero que saltó a la vista fue la discrepancia. Lo que parecía un cryptominer clásico era, en realidad, dos actores distintos operando en el mismo entorno, y el cryptominer era la cortina de humo.
El alerta que casi fue ignorado
El XMRig consumía CPU en tres servidores. Señal clásica de cryptominer, el SOC ya la había visto antes. El analista de turno estaba listo para marcarlo como "resuelto" tras la contención estándar. Pero cuando llegamos, lo primero que nos llamó la atención fue la discrepancia.
Había tráfico de salida hacia dos dominios de C2 completamente diferentes. No eran solo dominios distintos, eran protocolos diferentes, con patrones temporales distintos. Uno operaba en el horario comercial de Europa, ventana de 9h a 18h en el huso de Frankfurt. El otro actuaba en la madrugada brasileña, entre 1h y 4h. Esa divergencia temporal y de protocolo era el primer indicador de que no estábamos lidiando con fases de una única campaña, sino con campañas separadas. Dos actores. Mismo entorno.
La discrepancia que reveló dos actores
El primer actor había entrado 48 horas antes por una vulnerabilidad recién divulgada. Automatizado, rápido, instaló el cryptominer y estableció persistencia con web shell. El segundo explotó la misma vulnerabilidad horas después, pero con un objetivo diferente: exfiltración de certificados digitales y datos de transacciones PIX.
La separación era invisible sin cruzar telemetría. Los artefactos del segundo actor parecían "fase dos" de la misma campaña. Sin correlacionar logs de identidad, telemetría de endpoint y tráfico de nube, el equipo interno no habría podido distinguir dos actores de un único ataque por etapas. Fue ese cruce el que reveló la verdad: dos actores, dos motivaciones, una puerta de entrada.
El primer actor quería compute gratuito. El segundo quería activos negociables, certificados que firman transacciones y datos de PIX que valen dinero en el mercado negro. La vulnerabilidad recién divulgada fue la puerta abierta que ambos encontraron, pero lo que cada uno buscó dentro de la infraestructura fue completamente diferente.
El cryptominer como cortina de humo
El cryptominer funcionó como cortina de humo. El equipo interno se concentró en contener la minería; al fin y al cabo, era la señal más obvia. Mientras tanto, el segundo actor operaba sin ser notado, exfiltrando certificados digitales y datos de transacciones PIX.
Aquí es donde falla la mayoría de las respuestas a incidentes. El SOC marca el cryptominer como "resuelto", cierra el ticket, y el segundo actor sigue operando. El runbook típico de SOC dice: identifique al minero, aísle el host, remueva la persistencia, cierre el ticket. Ese runbook funciona cuando hay un único actor. Cuando hay dos, contener al primero le da al segundo exactamente lo que necesita: silencio operativo.
Un cryptominer en un entorno financiero rara vez es solo cryptominer. Es el canario. Si alguien está minando en su infraestructura de pagos, la pregunta correcta no es "¿cómo lo removemos?". Es: ¿quién más entró por la misma puerta?
La evacuación coordinada: kill-switch simultáneo
La solución fue la evacuación coordinada. Si contenemos un actor a la vez, el otro se esconde: usted cree que está limpio, y la violación continúa. En Tech86 mapeamos toda la superficie de acceso antes de actuar. Web shells, certificados comprometidos, cuentas persistidas, segmentos afectados, todo inventariado antes de cualquier acción.
Después, kill-switch simultáneo: revocación de certificados, aislamiento de segmentos, remoción de web shells y reacreditación total en una ventana de 14 minutos. Los 14 minutos se dividieron en tres bloques. En los primeros 4 minutos, revocamos todos los certificados digitales comprometidos e invalidamos las sesiones activas basadas en ellos. De los minutos 4 al 10, aislamos los segmentos de red afectados y removimos los web shells de los tres servidores. De los minutos 10 al 14, ejecutamos la reacreditación total: contraseñas, llaves SSH, tokens de API, cuentas de servicio.
La acción secuencial habría dado tiempo para que el segundo actor se reconfigurara. La ventana corta es lo que garantiza que ambos actores sean contenidos al mismo tiempo, sin oportunidad de reacción.
Dwell time y la pregunta correcta
Según el informe M-trends de Mandiant/FireEye, el dwell time global mediano es 14 días. Aquí, fueron 2 días hasta que la exfiltración comenzó, significativamente por debajo de la mediana. Si el SOC hubiera marcado el cryptominer como "resuelto" sin investigar más a fondo, el segundo actor habría operado por semanas.
La lección es clara. Un cryptominer en un entorno financiero rara vez es solo cryptominer. Es el canario. La pregunta correcta no es "¿cómo removemos al minero?", es "¿quién más entró por la misma puerta?". Ese cambio de perspectiva es lo que separa una contención superficial de una respuesta a incidentes completa.
Conclusión
Lo repetimos: un cryptominer en un entorno de pagos es el canario, no la amenaza. Cuando el SOC de una procesadora brasileña se disparó aquel viernes a las 2:17, el instinto fue tratarlo como cryptominer clásico. Lo que encontramos fueron dos actores, dos objetivos, una puerta de entrada, y el cryptominer era la cortina de humo que escondía la exfiltración de certificados y datos PIX.
La diferencia entre "resuelto" y "realmente resuelto" está en cruzar telemetría de identidad, endpoint y nube antes de actuar, y en ejecutar un kill-switch simultáneo en lugar de una contención secuencial. En Tech86 ayudamos a empresas a responder incidentes complejos, antes de que el canario se convierta en lo único que usted escucha.