El descubrimiento de un minero de criptomonedas con Claude Code expone una paradoja de seguridad mayor
Según se informa, Claude Code encontró un minero de criptomonedas que consumía un 1.175 % de CPU mientras ayudaba a un desarrollador a investigar un Mac que alcanzó los 112 grados Celsius.
Ese descubrimiento de un minero de criptomonedas con Claude Code parece una clara victoria para la IA agéntica. El agente de programación siguió lecturas de temperatura sospechosas, identificó un proceso XMRig y ofreció eliminar los archivos vinculados a él.
Sin embargo, el incidente también expone una contradicción incómoda. El sistema demostró ser útil porque podía inspeccionar procesos y proponer cambios en el sistema, precisamente las mismas capacidades que hacen riesgosos a los agentes de programación.
El relato procede del usuario de Reddit UntilHEX, no de una investigación forense publicada. Las capturas de pantalla disponibles y los comentarios posteriores respaldan una secuencia plausible, pero no establecen cómo llegó el software.
Esa brecha de verificación importa. Claude Code parece haber detectado un problema operativo real, pero los lectores no deberían confundir un informe viral con una evaluación validada de malware.
Claude Code siguió el calor hasta XMRig
La parte más destacable de la historia no es que Claude Code reconociera XMRig. Es que el agente investigó una señal física inesperada.
UntilHEX dijo que había pedido a Claude Code crear una aplicación de monitorización de temperatura para Mac. La aplicación mostró valores brutos de sensores que parecían anormalmente altos, lo que llevó al agente a investigar la actividad de la CPU.
Según el relato original de Reddit, Claude identificó un proceso xmrig que consumía aproximadamente un 1.175 % de CPU. El agente interpretó esa lectura como unos 12 núcleos sometidos a una carga intensa.
Los porcentajes por encima de 100 son normales en los informes de procesos de macOS cuando el software utiliza varios núcleos lógicos. Por ello, un proceso que ocupe casi 12 núcleos puede aparecer cerca del 1.200 %.
La documentación de Apple explica que Monitor de Actividad muestra el consumo de CPU de los procesos activos y el uso total del sistema en todos los núcleos. Lecturas sostenidas de esta magnitud apuntan a una carga de trabajo intensiva, aunque la interpretación exacta depende del Mac.
Según los informes, Claude relacionó el proceso con lecturas de temperatura que alcanzaban un máximo de 112 grados Celsius. Esa cifra procedía de la salida de monitorización del usuario y no se ha reproducido de forma independiente.
El agente identificó entonces lo que parecía ser un mecanismo de inicio. Las capturas revisadas en la cobertura original sugerían que los archivos relacionados estaban configurados para reiniciar el minero al arrancar el Mac.
Claude describió la situación con claridad: el equipo estaba ejecutando un minero de criptomonedas que, según el agente, no había instalado. Ofreció detener el proceso, desactivar su entrada de inicio y poner en cuarentena los archivos asociados.
Posteriormente, el usuario afirmó que Claude completó la mayor parte de la limpieza. Según se informa, un archivo requirió eliminación manual porque el agente no tenía el acceso necesario.
UntilHEX ejecutó entonces Malwarebytes como comprobación secundaria. El relato público no incluye un informe completo del análisis, muestra de malware, hashes de archivos, indicadores de red ni un análisis forense independiente.
Esas omisiones limitan las conclusiones posibles. Impiden que los investigadores identifiquen la familia precisa de malware, el vector de instalación, el mecanismo de persistencia o el destino de la minería.
XMRig en sí no es inherentemente malicioso. Su documentación oficial lo describe como una aplicación legítima y de código abierto para minería con CPU y GPU, disponible en varios sistemas operativos.
El problema de seguridad depende de la autorización. Ejecutar XMRig en una máquina con el consentimiento de su propietario es minería de criptomonedas ordinaria. Instalarlo u operarlo en secreto es cryptojacking.
Esta distinción es esencial porque identificar un proceso xmrig no demuestra qué instalador lo colocó allí. Tampoco muestra si el binario fue modificado, incluido con otro malware o disfrazado mediante nombres de archivo relacionados.
Por tanto, la historia viral respalda una conclusión más limitada. Claude Code detectó un uso extremo de recursos y lo rastreó hasta software asociado con la minería de criptomonedas.
Sigue siendo un resultado útil. No establece que Claude identificara la intrusión original ni que eliminara todos los componentes responsables de ella.
Por qué importa el descubrimiento del minero de criptomonedas con Claude Code
Claude Code no pareció comenzar con una tarea de detección de malware. Llegó al hallazgo de seguridad al comprobar si el equipo coincidía con la salida de su propio software.
Esa secuencia distingue esta historia de una alerta antivirus convencional. El agente ayudaba a crear una herramienta de monitorización cuando los datos de los sensores le obligaron a cuestionar el entorno circundante.
El software tradicional suele detenerse en el límite de su función asignada. Una utilidad de temperatura puede mostrar una cifra sin determinar por qué es anómala.
Un agente puede investigar la discrepancia. Puede inspeccionar procesos en ejecución, comparar el uso de recursos, examinar entradas de persistencia y proponer acciones correctivas dentro de un único flujo de trabajo conversacional.
Ese comportamiento representa el atractivo práctico de los agentes de programación. Pueden conectar código, estado del sistema operativo, registros e intención del usuario sin exigir una interfaz independiente para cada paso.
En este caso, los síntomas físicos proporcionaron la pista. El Mac caliente y lento creó pruebas que la aplicación en desarrollo no podía explicar por sí sola.
Según se informa, el agente pasó de la validación de sensores al diagnóstico de procesos. Es un pequeño ejemplo de lo que los sistemas agénticos hacen de forma distinta a las herramientas de autocompletado de código.
Un asistente de autocompletado de código predice o genera texto dentro de un editor. Un agente puede recopilar evidencia adicional y utilizar herramientas para actuar en un equipo.
La presión recae primero sobre los flujos de trabajo tradicionales de resolución de problemas. Normalmente, un desarrollador abriría Monitor de Actividad, ordenaría por CPU, investigaría el proceso sospechoso e inspeccionaría manualmente las ubicaciones de inicio.
Claude Code comprimió varios de esos pasos en un diálogo. El usuario siguió controlando la decisión final, pero el agente reunió una explicación plausible y un plan de limpieza.
Eso no vuelve obsoleto a Monitor de Actividad. Apple lo incluye desde hace tiempo en macOS, y puede revelar el mismo tipo de demanda sostenida de CPU sin una suscripción a IA.
La diferencia tiene que ver con la iniciativa y la síntesis. Según se informa, el usuario pidió una aplicación de temperatura, mientras que Claude amplió la investigación cuando los datos resultantes parecían incorrectos.
Esa iniciativa es valiosa para desarrolladores que gestionan sistemas desconocidos. También puede ayudar cuando los síntomas atraviesan los límites entre código de aplicación, configuración del sistema y seguridad.
La historia se parece más al trabajo de observabilidad que a la detección antivirus convencional. La observabilidad comienza con señales del sistema y las utiliza para determinar por qué el comportamiento difiere de las expectativas.
Claude no necesitó una firma que afirmara que un archivo era malicioso. Según se informa, detectó que la temperatura y la actividad del procesador no encajaban con la carga de trabajo prevista.
Este enfoque tiene límites. Un uso elevado de CPU puede proceder de compilación, renderizado de vídeo, modelos locales, procesos del navegador, indexación o minería legítima.
El contexto convierte una anomalía en una advertencia significativa. Aquí, el usuario estaba creando un monitor ligero, no ejecutando intencionadamente una carga sostenida de criptomonedas.
En consecuencia, el caso presiona de formas distintas a los proveedores de seguridad y a los creadores de herramientas para desarrolladores. Los productos de seguridad deben explicar los hallazgos con claridad, mientras que los agentes de programación deben demostrar que pueden investigar sin crear nueva exposición.
También cambia las expectativas de los usuarios. Una vez que un agente puede inspeccionar el estado del sistema en directo, los desarrolladores esperarán que detecte conflictos evidentes que afecten a la tarea.
Esa expectativa se extiende más allá del malware. Los agentes podrían detectar almacenamiento agotado, servicios en segundo plano defectuosos, puertos en conflicto, presión de memoria o credenciales ubicadas en archivos inseguros.
Los equipos que adopten estas herramientas necesitarán registros consultables de lo que un agente observó y modificó. Una base de conocimientos de ingeniería estructurada puede conservar esas decisiones para revisiones posteriores.
Por ello, la afirmación sobre la detección de malware con Claude Code resulta interesante incluso con sus limitaciones probatorias. Muestra cómo una tarea de programación puede convertirse en una investigación operativa cuando un agente recibe suficiente contexto local.
El agente útil y el permiso peligroso son la misma cosa
La inversión central es simple: Claude Code ayudó porque tenía visibilidad significativa del sistema, pero esa visibilidad también define su riesgo de seguridad.
Un agente de programación que no pueda inspeccionar procesos, leer archivos de proyecto o ejecutar comandos de diagnóstico habría tenido dificultades para rastrear el Mac que se sobrecalentaba.
Conceder esas capacidades amplía lo que el agente puede lograr. También amplía las consecuencias de un comando equivocado, un prompt malicioso, una dependencia comprometida o una aprobación descuidada.
La propia guía de sandboxing de Anthropic describe esta tensión. Claude Code utiliza permisos y límites del sistema operativo para controlar el acceso a archivos y redes.
Anthropic afirma que Claude Code es de solo lectura por defecto y solicita confirmación antes de la mayoría de los comandos que modifican el estado. Los comandos seguros pueden recibir un tratamiento diferente, mientras que las operaciones sensibles requieren aprobación.
La empresa introdujo el sandboxing para reducir solicitudes repetidas sin conceder acceso sin restricciones. Un sandbox define dónde puede escribir el agente y a qué recursos de red puede acceder.
Anthropic informó de que el sandboxing redujo las solicitudes de permisos en un 84 % durante su uso interno. Esa cifra, comunicada por la empresa, mide la fricción del flujo de trabajo, no la protección frente a todos los ataques.
La distinción importa porque los usuarios optimizan frecuentemente los agentes para la comodidad. Las aprobaciones repetidas pueden generar fatiga, animando a las personas a aprobar comandos sin examinar sus consecuencias.
Eliminar las solicitudes por completo crea otro problema. El agente puede actuar más rápido, pero un plan defectuoso puede alcanzar más archivos y servicios antes de que intervenga el usuario.
El incidente del Mac ilustra por qué los permisos deberían seguir siendo visibles. Según se informa, Claude propuso detener el minero y mover archivos en lugar de eliminarlos silenciosamente.
Esa cautela es una característica. El nombre de un proceso por sí solo no es prueba suficiente de que todos los archivos asociados sean maliciosos, especialmente cuando XMRig puede utilizarse legítimamente.
La cuarentena es más segura que la destrucción inmediata porque preserva las pruebas y permite la recuperación. También puede respaldar análisis posteriores si los archivos se gestionan de forma segura.
Sin embargo, permitir que un sistema de IA lleve a cabo la remediación sigue requiriendo criterio humano. Un modelo de programación no es un motor de detección de endpoints de confianza simplemente porque pueda ejecutar comandos de shell.
Puede interpretar mal un árbol de procesos, leer incorrectamente un archivo de configuración o eliminar un elemento de inicio que pertenezca a software legítimo. También puede pasar por alto un componente de persistencia independiente.
Por ello, la seguridad de los agentes de programación con IA depende de controles en capas. El razonamiento del modelo es una capa, mientras que las restricciones del sistema operativo, las reglas de aprobación, el registro, las copias de seguridad y la protección de endpoints aportan otras.
Apple describe tres capas en sus defensas contra malware de macOS: prevenir la ejecución, bloquear malware conocido y remediar software que se ha ejecutado.
Gatekeeper comprueba el software descargado frente a requisitos de firma y notarización. XProtect utiliza firmas y análisis de comportamiento para detectar y eliminar malware conocido o sospechoso.
Esos mecanismos no garantizan que todos los programas maliciosos sean detenidos. Las nuevas variantes, los binarios modificados, las herramientas legítimas utilizadas indebidamente y la ejecución aprobada por el usuario pueden complicar la detección.
El informe no determina si Gatekeeper o XProtect fallaron. No revela la versión de macOS, la configuración de seguridad, el origen del instalador ni las acciones que precedieron a la infección.
Sería igual de prematuro atribuir a Claude el haber sorteado un punto ciego en las defensas de Apple. La evidencia pública no permite saber si XProtect había evaluado los archivos relevantes.
El agente también operó después de que los síntomas se volvieran graves. Una máquina que consumía casi 12 núcleos y alcanzaba la temperatura reportada ya estaba señalando un problema importante.
No se trató de una detección preventiva y silenciosa. Fue un diagnóstico reactivo después de que el supuesto minero se volviera lo bastante evidente como para degradar el ordenador.
El mismo acceso que permitió ese diagnóstico merece límites cuidadosos. Los desarrolladores no deberían responder otorgando a cada agente de programación un control sin restricciones sobre archivos personales, credenciales o servicios del sistema.
Una configuración más segura limita al agente al directorio de trabajo siempre que sea posible. Los destinos de red y los comandos privilegiados deben recibir un escrutinio independiente.
Los desarrolladores también deberían mantener a los agentes alejados de secretos no relacionados. Los repositorios de código fuente suelen coexistir con credenciales de nube, claves de firma, sesiones de navegador y configuraciones de producción.
Un comando de diagnóstico aparentemente útil puede exponer esos activos si su salida entra en el contexto del modelo o en los registros de sesión. El riesgo existe incluso cuando el agente no tiene una intención maliciosa.
La lección de esta historia no es que un acceso más amplio siempre produzca mejor seguridad. Es que un acceso controlado puede permitir a los agentes conectar evidencias que las herramientas aisladas dejan dispersas.
Una detección viral no es un informe forense
La afirmación sigue siendo lo bastante creíble como para analizarla, pero demasiado incompleta para demostrar que Claude eliminó una infección de malware completa.
La evidencia original consiste principalmente en una publicación de Reddit, capturas de pantalla, comentarios de usuarios y posterior cobertura mediática. Ningún investigador independiente parece haber examinado la máquina ni los archivos.
Las cifras centrales también proceden de ese relato. Los periodistas no reprodujeron la lectura de CPU del 1.175 % ni verificaron de forma independiente el pico reportado de 112 grados.
Tom’s Hardware enmarcó correctamente el incidente como un descubrimiento reportado por un usuario. Su relato publicado señala que se desconocía el número de núcleos del Mac no identificado.
Esa incertidumbre afecta a la interpretación. El proceso fue descrito claramente como exigente, pero el material público no identifica el modelo exacto de Mac ni el método de medición térmica.
Las herramientas de temperatura también pueden etiquetar los sensores de forma diferente. Un pico reportado podría representar un núcleo concreto, un sensor del chip, un punto caliente o un valor interpretado, en lugar de una temperatura universal de la CPU.
Nada de esto refuta el relato. Simplemente marca el límite entre una narrativa convincente basada en capturas de pantalla y evidencia técnica reproducible.
La vía de infección es una laguna aún mayor. UntilHEX no estableció públicamente qué descarga, instalador, script, extensión o paquete comprometido introdujo el minero.
Sin esa respuesta, otros usuarios no pueden determinar si comparten la misma exposición. Los investigadores de seguridad tampoco pueden crear indicadores fiables basándose únicamente en el informe.
El nombre XMRig solo ofrece un punto de partida. Los operadores de malware suelen abusar de software de minería legítimo porque ya realiza el costoso trabajo computacional que necesitan.
El malware histórico para Mac demuestra ese precedente. Malwarebytes documentó el malware BirdMiner, que utilizaba XMRig mediante un emulador de Linux y consumía los recursos informáticos de las víctimas.
Ese ejemplo histórico no identifica el software presente en el Mac de UntilHEX. Solo muestra que XMRig ya ha aparecido anteriormente en operaciones de minería no autorizadas en Mac.
La diferencia entre identificar un minero y limpiar una infección es considerable. Una investigación completa examinaría la persistencia, los procesos padre, los archivos descargados, las conexiones de red, las cuentas y las acciones administrativas recientes.
También preservaría hashes y marcas de tiempo antes de la eliminación. Esos detalles pueden mostrar si un supuesto actualizador pertenece a la misma operación o representa otra cosa.
Eliminar el minero visible podría detener el consumo actual de CPU y, al mismo tiempo, dejar un descargador detrás. Un mecanismo de persistencia superviviente podría reinstalar la carga útil más adelante.
La exposición de credenciales plantea otra preocupación. Un malware con acceso a la cuenta de un desarrollador podría alcanzar tokens, datos del navegador, código fuente, material SSH o archivos de entorno.
La cuenta de Reddit no afirma que ese acceso se produjera. Aun así, finalizar el proceso del minero no puede demostrar que las credenciales permanecieran intactas.
Una respuesta profesional trataría el equipo como potencialmente comprometido hasta comprender la persistencia y la vía de entrada. La respuesta adecuada depende del papel y la sensibilidad de la máquina.
Un ordenador personal de pruebas y una estación de trabajo con credenciales de producción conllevan riesgos diferentes. El segundo caso puede justificar la rotación de contraseñas, la revocación de tokens, una revisión forense más profunda o una reconstrucción desde un sistema fiable.
Por tanto, la ayuda de Claude en la limpieza no debería convertirse en la prueba final de seguridad. El análisis de seguimiento de Malwarebytes realizado por el usuario fue una comprobación secundaria sensata, pero la publicación pública no ofrece sus resultados.
La respuesta escéptica también se aplica a las afirmaciones sobre el rendimiento de la IA. Un único éxito no puede medir la precisión de Claude Code para detectar malware, sus falsos positivos ni su fiabilidad ante ataques variados.
Una evaluación real utilizaría un conjunto controlado de máquinas limpias e infectadas. Los investigadores compararían los hallazgos con herramientas consolidadas y repetirían las pruebas con permisos documentados.
Ese estudio tendría que medir las amenazas no detectadas y las correcciones perjudiciales, no solo las detecciones exitosas. Un agente que detecta un minero pero elimina servicios de inicio legítimos no sería fiable.
Por ahora, el evento se entiende mejor como un caso de resolución de problemas especialmente ilustrativo. Muestra a un agente estableciendo una conexión útil, mientras deja sin demostrar las afirmaciones de seguridad más amplias.
Lo que deben demostrar los próximos casos de seguridad de Claude Code
La próxima evidencia útil procederá de investigaciones reproducibles, registros de permisos y pruebas de que la corrección sobrevive a un reinicio.
La primera señal que conviene observar es si UntilHEX o un investigador de seguridad publica indicadores técnicos de este caso. Hashes de archivos, rutas, entradas de inicio y destinos de red harían posible un análisis independiente.
Si esos detalles permiten identificar una familia de malware reconocida y una cadena de persistencia confirmada, el relato se vuelve mucho más sólido. Si no aparecen artefactos, seguirá siendo una anécdota instructiva pero no verificada.
La segunda señal es la durabilidad de la limpieza. Un proceso eliminado debería seguir ausente después de cerrar sesión, reiniciar y realizar otro análisis.
Su reaparición demostraría que Claude trató un síntoma en vez del mecanismo completo. Su ausencia continuada reforzaría la afirmación de que la corrección propuesta alcanzó los archivos de persistencia pertinentes.
Aun así, la ausencia por sí sola no demostraría que ninguna credencial ni archivo no relacionado resultó afectado. Solo validaría el resultado más limitado de la limpieza.
La tercera señal se refiere a cómo los proveedores de agentes exponen las acciones locales. Los desarrolladores necesitan registros más claros de qué comandos se ejecutaron, qué archivos cambiaron, qué acceso se denegó y de dónde procedía la evidencia.
El trabajo continuado de Anthropic sobre permisos y sandboxing será importante aquí. Los agentes útiles necesitan suficiente autonomía para investigar, mientras que las organizaciones necesitan límites aplicables y registros revisables.
Los proveedores de seguridad también tienen una oportunidad. Pueden incorporar hallazgos verificados de endpoints a los flujos de trabajo de agentes sin pedir a un modelo de lenguaje que decida de forma independiente si un proceso es malicioso.
Ese enfoque combina fortalezas distintas. Las herramientas de endpoint aportan firmas, telemetría y controles de corrección, mientras que los agentes explican la evidencia y coordinan los pasos aprobados.
El descubrimiento reportado de un minero de criptomonedas mediante Claude Code apunta hacia ese modelo híbrido. El agente detectó una anomalía y reunió contexto, mientras que el software de seguridad establecido proporcionó un paso de validación independiente.
Los desarrolladores deberían mantener esa separación hoy. Dejen que el agente ayude a interpretar los síntomas y a redactar un plan de respuesta, pero confirmen el hallazgo con herramientas del sistema operativo y de seguridad.
También deberían revisar cada acción privilegiada. Un agente que pide permiso para eliminar, desactivar o poner algo en cuarentena presenta una propuesta, no emite un veredicto verificado.
El incidente no ofrece motivos para entrar en pánico por la aparición de XMRig en cada Mac. Sí ofrece motivos para investigar el calor sostenido, el bajo rendimiento, las entradas de inicio inesperadas y la demanda de CPU sin explicación.
También cuestiona una suposición habitual sobre los agentes de programación. Su valor no termina cuando el código generado compila.
La capacidad más interesante es su habilidad para comparar la salida del software con el estado real del ordenador. Eso puede revelar problemas del entorno que la solicitud original nunca mencionó.
La compensación sigue siendo inevitable. Un mayor contexto favorece un mejor diagnóstico, mientras que un acceso más amplio aumenta el daño que puede causar un agente equivocado o manipulado.
Quien experimente con la detección de malware mediante Claude Code debería empezar con permisos limitados, registros conservados y un escáner independiente. Las máquinas sensibles merecen límites más estrictos y una ruta documentada de respuesta a incidentes.
La próxima vez que un agente encuentre un proceso sospechoso, formule tres preguntas antes de celebrarlo: ¿Qué evidencia lo identifica, cómo persistió y qué demuestra que siguió eliminado? Esas respuestas determinarán si el agente encontró una molestia, contuvo una intrusión o simplemente produjo una historia persuasiva.
