← Volver al glosario Amenazas y ataques

Cryptojacking

¿Qué es el cryptojacking?

El cryptojacking es el uso no autorizado de la capacidad de cómputo de tus equipos, servidores, contenedores o cuentas cloud para minar criptomonedas en beneficio del atacante. A diferencia del ransomware, no rompe nada visible: el objetivo es pasar desapercibido el mayor tiempo posible mientras la víctima paga la factura en electricidad, hardware degradado o — el caso más caro — consumo cloud disparado. Es malware de monetización silenciosa: convierte cualquier CPU o GPU comprometida en dinero, casi siempre minando Monero con variantes de XMRig.

¿Por qué importa?

Porque el minero nunca es el problema completo: es la prueba de que alguien tiene ejecución de código en tu infraestructura. El mismo acceso que hoy mina criptomonedas puede mañana desplegar ransomware, robar datos o venderse a otro grupo; campañas como TeamTNT o Kinsing combinan minería con robo de credenciales y movimiento lateral hacia todo lo que encuentran. En cloud el impacto es directo y medible: con claves API filtradas, el atacante levanta instancias de cómputo — a menudo GPU — y la factura puede crecer decenas de miles de euros en días antes de que nadie mire el panel de facturación. En entornos de contenedores y Kubernetes, la minería es el payload por defecto de los bots que escanean Internet en busca de APIs de Docker expuestas o clústeres mal configurados: si tu infraestructura queda accesible, habrá un minero dentro en horas, no en semanas. Tratarlo como una molestia menor es leer mal la señal.

Puntos clave

Vectores de entrada habituales: vulnerabilidades en servicios expuestos (desde Log4Shell hasta paneles de administración sin parchear), imágenes de contenedor troyanizadas en registros públicos, dependencias comprometidas en la cadena de suministro, claves cloud filtradas en repositorios y credenciales comprometidas.

En el endpoint: mineros basados en XMRig camuflados como procesos legítimos del sistema, con throttling deliberado (limitan su propio consumo o se pausan cuando el usuario está activo) para no disparar sospechas ni ventiladores.

En cloud: el atacante no siempre infecta tus máquinas — con permisos suficientes crea las suyas. Instancias GPU o de gran tamaño en regiones que no usas, levantadas con credenciales robadas, donde el primer síntoma suele ser la factura. Las alertas de billing y de anomalías de uso son un control de seguridad, no solo financiero.

En contenedores y Kubernetes: APIs de Docker expuestas, dashboards sin autenticación y pods desplegados con nombres que imitan componentes del sistema. Campañas automatizadas como Kinsing o TeamTNT explotan estos fallos en minutos tras el despliegue; un CWPP con detección en runtime es la contramedida específica.

Detección: consumo anómalo y sostenido de CPU/GPU fuera de patrón, conexiones salientes a pools de minería (protocolo stratum, resoluciones DNS características), procesos con línea de comandos sospechosa y detecciones de EDR. La correlación de estas señales en un SOC distingue el minero del falso positivo.

Respuesta correcta: matar el proceso es lo de menos. Hay que identificar el vector de entrada, buscar persistencia (cron, systemd, DaemonSets, funciones serverless), rotar las credenciales implicadas y revisar qué más hizo el atacante con ese acceso. Sin eso, el minero vuelve — o vuelve algo peor.

Ejemplo: factura cloud disparada por minería en un clúster de Kubernetes

Una empresa de software detecta que su factura cloud mensual se ha multiplicado por tres sin cambios de negocio que lo expliquen. El análisis de costes apunta a un grupo de nodos con CPU al 100% sostenido en un clúster de desarrollo. Dentro, varios pods con nombres que imitan componentes legítimos del sistema ejecutan XMRig contra un pool de Monero. El origen: una API de Kubernetes accesible desde Internet con un rol demasiado permisivo, descubierta por un bot que desplegó los mineros de forma completamente automatizada — el mismo patrón de campañas como Kinsing.

La respuesta que funcionó fue tratarlo como incidente y no como avería: aislar el clúster, capturar evidencias, eliminar los DaemonSets de persistencia, cerrar la exposición de la API, rotar todas las credenciales y service accounts del clúster y revisar los logs en busca de movimiento lateral hacia otros proyectos. Después, prevención: políticas de admisión para imágenes, límites de recursos por namespace, alertas de billing con umbrales por proyecto y monitorización de conexiones salientes hacia pools de minería desde el SOC. El coste real no fue la factura: fue descubrir que cualquiera podía ejecutar código en ese clúster desde hacía semanas.

Errores habituales

  • Tratarlo como un problema menor porque 'solo mina'. El minero demuestra ejecución de código remoto en tu infraestructura; el mismo acceso sirve para ransomware o robo de datos, y a veces ya se ha usado para ambos cuando se descubre.
  • Limpiar el minero sin investigar el vector de entrada ni la persistencia. Si el agujero sigue abierto — la API expuesta, la clave filtrada, el servicio sin parchear — el minero reaparece en días, a menudo con mejoras.
  • No vigilar la facturación cloud como señal de seguridad. Las alertas de coste y de anomalías de uso detectan cryptojacking antes que muchos controles técnicos; sin umbrales por proyecto, la primera noticia es la factura de fin de mes.
  • Confiar solo en el antivirus tradicional. Los mineros en contenedores, los ataques fileless y las instancias creadas por el atacante en tu cuenta cloud no pasan por el disco de ningún endpoint; hacen falta EDR, detección en runtime y monitorización de red.
  • Ignorar los entornos 'que no importan': clústeres de desarrollo, máquinas de laboratorio, proyectos cloud secundarios. Tienen menos vigilancia, las mismas credenciales conectadas al resto y son exactamente donde los mineros viven más tiempo.

Términos relacionados

Servicios relacionados

Este concepto puede tener relación con servicios como:

Preguntas frecuentes

Nuestra factura cloud se ha duplicado este mes sin motivo aparente: ¿cómo confirmo si es cryptojacking?

Empieza por el desglose de costes: identifica qué servicio, proyecto y región concentran el aumento. Las señales típicas son instancias que tú no reconoces (sobre todo GPU o de gran tamaño), regiones que tu empresa no usa y consumo de CPU sostenido al máximo en recursos existentes. Después revisa los logs de auditoría del proveedor (CloudTrail, Azure Activity Log, GCP Audit Logs): quién creó esos recursos, con qué credencial y desde dónde. Si aparece una clave API o un service account que no debería tener esos permisos, asume compromiso: rota credenciales, aísla el proyecto y trátalo como incidente, no como error de configuración. Y deja configuradas alertas de presupuesto por proyecto: son el detector más barato que existe.

¿Cómo detecto cryptojacking en los equipos de mi empresa si no tenemos SOC propio?

Con tres capas asumibles. Primera, un EDR moderno en los endpoints: las familias de mineros más comunes (XMRig y derivados) están bien cubiertas por las detecciones de comportamiento, no solo por firmas. Segunda, señales de red: conexiones salientes a pools de minería usan patrones reconocibles (protocolo stratum, dominios de pools conocidos) que un firewall con filtrado DNS puede bloquear y alertar. Tercera, los síntomas físicos siguen valiendo en pymes: equipos que van lentos de forma sostenida, ventiladores disparados con el equipo "en reposo" y baterías que duran la mitad. Si no hay capacidad interna para vigilar esas señales, un SOC gestionado externaliza exactamente esa correlación y el triaje.

¿El cryptojacking es realmente peligroso si 'solo' roba capacidad de cálculo?

Sí, por tres razones. La primera es la que se ve: coste directo en electricidad, degradación de hardware y facturas cloud que pueden alcanzar decenas de miles de euros. La segunda es la que no se ve: el minero prueba que alguien ejecuta código en tu infraestructura, y grupos como TeamTNT o Kinsing no se limitan a minar — roban credenciales, instalan puertas traseras y se mueven lateralmente mientras el minero genera ingresos. La tercera es lo que revela: si un bot automatizado entró, tu superficie de ataque tenía un hueco que cualquier atacante dirigido también habría encontrado. Un minero descubierto merece la misma investigación que cualquier otra intrusión: vector, alcance, persistencia y qué más se hizo con ese acceso.

Desplegamos con contenedores y Kubernetes: ¿cómo evito que acaben minando para otros?

Cierra los tres huecos que explotan las campañas automatizadas. Uno: exposición — ninguna API de Docker ni de Kubernetes accesible desde Internet sin autenticación fuerte, y dashboards siempre detrás de acceso controlado. Dos: cadena de suministro — solo imágenes de registros confiables, escaneadas antes del despliegue, con políticas de admisión que rechacen imágenes no firmadas; los mineros embebidos en imágenes públicas populares son un clásico. Tres: runtime — límites de recursos por namespace (un pod que pide toda la CPU es señal, no normalidad), detección en ejecución con un CWPP o herramientas equivalentes, y monitorización de conexiones salientes. Una revisión de seguridad cloud periódica valida que estas barreras siguen en pie a medida que el clúster evoluciona.