Una extensión de Claude Code manipulada en el marketplace de Cursor y un script de proveedor secuestrado en Polymarket, con pocas horas de diferencia.
El 29 de octubre, dos cosas salieron mal con pocas horas de diferencia, en dos lugares muy distintos.
Por la mañana, el marketplace de extensiones de Cursor empezó a distribuir una copia manipulada de la extensión Claude Code. Casi cada byte era el código real de Anthropic, más un pequeño cargador que instalaba una puerta trasera SSH.
Esa misma tarde, se sustituyó un script de monitorización del rendimiento que Polymarket cargaba desde su proveedor, DebugBear. En lugar de medir la velocidad de la página, usó las sesiones de los traders conectados para vender sus posiciones y mover sus fondos. Los analistas rastrearon unos 2.57 millones de dólares hasta la wallet del atacante.
Nadie instaló nada extraño. Los desarrolladores aceptaron una actualización de una extensión conocida. Los traders abrieron el sitio que usan siempre. La etiqueta era correcta. La receta había cambiado.
Así que este número se pregunta: ¿qué significa «fuente de confianza» cuando otra persona puede cambiar lo que entrega? El Análisis a fondo examina lo que un marketplace tendría que comprobar más allá del nombre del editor, e Investigación técnica explica cómo el drainer de Polymarket reutilizó el propio cliente de trading de la página.
En este número
🌡️ Nivel de amenaza: Alerta alta
⚡ Noticias: El FBI atribuye el robo a Binance a Corea del Norte, versiones de LiteLLM y OVHcloud CLI sustituidas, Storm-0940 ataca tenants de Microsoft 365 a través de un proveedor de copias de seguridad
🔎 Análisis a fondo: El editor era legítimo. La actualización estaba manipulada.
🎣 ¿Es phishing?
🔬 Investigación técnica: Medía la velocidad de la página. Luego vendía sus posiciones.
🛠️ Herramienta de la semana: osquery
👏 Persona de la semana: Paul McCarty
📅 Evento de la semana: Open Source SecurityCon 2026
📚 Libro de la semana: Software Supply Chain Security
😅 El meme
❓ Una pregunta antes de despedirnos
Vamos al grano.
🌡️Nivel de amenaza
⚡Sección 01: Noticias
Cripto, en tamaño gigante
El FBI atribuye a Corea del Norte el robo de 6.3 mil millones de dólares a Binance
Binance ha confirmado un robo de unos 6.3 mil millones de dólares, el mayor robo de criptomonedas registrado. Las empresas de inteligencia blockchain TRM Labs y Chainalysis lo atribuyeron a TraderTraitor, un grupo norcoreano, y el 31 de octubre el FBI lo confirmó, señalando a los mismos actores que estuvieron detrás del hackeo de 1.5 mil millones de dólares a Bybit en 2025.
Los primeros informes culparon a un único portátil comprometido. Desde entonces, Binance ha dicho que su investigación encontró otros puntos de intrusión, y el punto de entrada sigue sin estar claro. Binance afirma haber repuesto cerca del 90% de los fondos robados con dinero de la empresa, y Tether afirma haber congelado unos 1.57 mil millones de dólares en activos vinculados al robo.
Según el FBI, la mayor parte de los activos robados se está convirtiendo en ether, y espera que el resto se mueva a través de plataformas DeFi y servicios de intercambio instantáneo.
Por qué importa: El récord anterior, Bybit, lo estableció el mismo grupo hace menos de dos años. Este robo es aproximadamente cuatro veces mayor. TraderTraitor no es una banda oportunista que tuvo suerte una vez. Es una unidad estatal que sigue encontrando la forma de entrar en las empresas que tienen más dinero.
Observe lo que se pudo detener y lo que no. Tether congeló 1.57 mil millones de dólares porque Tether puede congelar los tokens que emite. Ether no tiene un emisor al que llamar. Cada hora que los atacantes dedican a convertir tokens robados en activos que nadie puede congelar reduce lo que se puede recuperar, y por eso la conversión ya está en marcha.
La versión cambiante sobre el punto de entrada también importa. «Un portátil comprometido» era una explicación limpia, y era errónea, o al menos incompleta. Las primeras explicaciones de las grandes brechas suelen serlo. Hasta que se conozca la ruta completa, nadie puede decir qué controles fallaron.
Si trabaja en el sector cripto o fintech, o cerca de él, trate el modus operandi documentado de TraderTraitor como una amenaza directa: falsos reclutadores, pruebas de programación para hacer en casa y paquetes maliciosos dirigidos a ingenieros. Mantenga la infraestructura de firma fuera de los portátiles que los ingenieros usan a diario, y establezca contactos con los emisores de stablecoins antes de necesitar una congelación, no después.
Detener el robo es la primera línea de defensa. Una vez que los tokens se convierten en ether, la ventana para la segunda se cierra.
Atribución del FBI (BleepingComputer) · Atribución de TRM Labs y Chainalysis · Actualización de la investigación de Binance (ITPro)
Versiones, recalentadas
Versiones de LiteLLM y OVHcloud CLI sustituidas por ladrones de secretos
El 21 de octubre se publicaron en PyPI compilaciones maliciosas de la versión 1.107.0 de LiteLLM, junto con imágenes de contenedor comprometidas, después de que los atacantes se hicieran con tokens OAuth de GitHub CLI. LiteLLM es una pasarela muy utilizada entre las aplicaciones y los proveedores de modelos de IA. La ventana de exposición en PyPI fue de unas dos horas. El análisis de Microsoft concluyó que el payload se ejecutaba mediante hooks de inicio de Python, de modo que un equipo que solo instalara el paquete podía filtrar secretos sin llegar a importarlo.
Dos días antes, el 19 de octubre, un atacante usó una cuenta de colaborador secuestrada para sustituir en GitHub las descargas de cinco versiones de OVHcloud CLI (v0.11.0 a v0.15.0) por compilaciones que robaban secretos, durante un máximo de 94 minutos. El atacante nunca tocó el pipeline de compilación de OVHcloud. La inmutabilidad de las versiones estaba desactivada, así que los archivos simplemente se podían cambiar. OVHcloud los eliminó, publicó una v0.16.0 limpia como versión inmutable y activó esa opción.
Por qué importa: En ambos casos, el ataque se produjo en el último paso: la versión que la gente descarga. El atacante de OVHcloud no tocó el pipeline de compilación en absoluto, y las compilaciones de LiteLLM se publicaron con tokens robados. Revisar el código fuente o proteger la CI no habría detectado ninguno de los dos.
Las ventanas cortas tranquilizan menos de lo que parece. Dos horas y 94 minutos son poco tiempo para una persona, pero los pipelines de CI que descargan la última versión se ejecutan constantemente. Y con LiteLLM bastaba con instalarlo. Cada runner de compilación y cada portátil que descargó la 1.107.0 entregó los secretos que tuviera, incluidas las claves de API que una pasarela de IA existe precisamente para gestionar.
El caso de OVHcloud también muestra cuánto esperan los atacantes. Como descubrió Paul McCarty (más detalles en la Persona de la semana de este número), la cuenta usada para sustituir las versiones llevaba siete meses comprometida. Las credenciales de desarrollador robadas no caducan solo porque nadie las haya usado todavía.
Fije las dependencias por hash, no solo por versión, y espere unos días antes de adoptar versiones recién publicadas cuando sea posible. Si mantiene un proyecto, active las versiones inmutables y use tokens de publicación de corta duración. Si instaló cualquiera de las dos herramientas durante su ventana, rote todos los secretos a los que pudiera acceder el equipo, desde un equipo limpio.
Un repositorio limpio le dice lo que escribieron los mantenedores. No le dice lo que usted descargó.
Compromiso de LiteLLM (SecurityWeek) · Compromiso de OVHcloud CLI (SecurityWeek) · Vínculo con GlassWorm (Dark Reading)
Copias de seguridad, con acceso de guarnición
Storm-0940 usó el acceso de las aplicaciones de un proveedor de copias de seguridad para atacar 2,250 tenants de Microsoft 365
ConnectWise divulgó una brecha en su servicio Cloud Backup (antes SkyKick) el 16 de octubre. El 21 de octubre, Microsoft atribuyó la actividad posterior a Storm-0940, un grupo alineado con China.
Cloud Backup permite a los proveedores de servicios de TI hacer copias de seguridad de los datos de Microsoft 365 de sus clientes, por lo que sus aplicaciones ya tenían consentimiento en esos tenants. Los atacantes usaron las identidades de esas aplicaciones para intentar iniciar sesión en más de 2,250 tenants. Microsoft dijo que la mayoría de los intentos fracasaron, pero el grupo logró persistencia con privilegios en varias organizaciones, en algunos casos menos de tres horas después de atacarlas por primera vez. China negó las acusaciones.
Por qué importa: Ningún usuario sufrió phishing y no se omitió ninguna solicitud de MFA, porque no intervino ninguna. Las aplicaciones inician sesión con sus propios secretos o certificados, y en muchos tenants las políticas de inicio de sesión y las alertas están pensadas para personas. Los inicios de sesión de aplicaciones suelen quedar fuera de ambas.
El propio acceso era el premio. Una aplicación de copias de seguridad necesita leer correo, archivos y sitios de todo el tenant, que es exactamente el acceso que busca un atacante. Un solo consentimiento, concedido una vez por un administrador, puede cubrirlo todo.
«La mayoría de los intentos fracasaron» tampoco es un gran consuelo. El modelo de proveedor de servicios implica que un proveedor se conecta a miles de tenants, así que incluso una tasa de éxito pequeña se acumula. Y menos de tres horas desde el primer intento hasta la persistencia deja poco tiempo para reaccionar.
La persistencia es lo que sobrevive a la corrección. Una vez que los atacantes tenían acceso con privilegios, podían añadir sus propias credenciales, aplicaciones o asignaciones de roles. Eliminar la aplicación del proveedor no elimina nada de eso.
Revise qué aplicaciones de terceros tienen consentimiento en su tenant y qué permisos tienen. Compruebe los registros de inicio de sesión de aplicaciones y busque credenciales, aplicaciones o asignaciones de roles añadidas desde mediados de octubre. Si un proveedor de servicios gestiona su tenant, pregúntele directamente si usaba Cloud Backup.
Revocar el acceso del proveedor es el paso fácil. La pregunta útil es qué se añadió mientras estaba ahí.
Atribución de Microsoft (Dark Reading)
🔎Sección 02: Análisis a fondo
El editor era legítimo. La actualización estaba manipulada.
Los desarrolladores que instalaron la extensión Claude Code desde el marketplace de Cursor el 29 de octubre hicieron lo que se les dice que hagan. Usaron la tienda integrada en su editor, eligieron una extensión de un editor conocido y aceptaron la actualización. Durante unas 11 horas, eso bastó para recibir una puerta trasera SSH.
El editor era real. La tienda también. Lo que cambió fue el paquete entre ambos, y el paquete manipulado llegó a los usuarios pese a los controles de distribución existentes.
Qué ocurrió
Cursor afirmó que un actor malicioso «usó el acceso al marketplace de Cursor para publicar una extensión manipulada dirigida a los usuarios de Cursor». Las compilaciones manipuladas, versiones 2.1.312 y 2.1.313 para Windows y macOS, estuvieron disponibles aproximadamente de 2:27 a.m. a 1:35 p.m. PT y llegaron como máximo a 5,000 usuarios. Cursor las eliminó, suspendió temporalmente todo su marketplace de extensiones, auditó los accesos y rotó las claves.
Anthropic afirmó que las versiones de sus canales oficiales no están afectadas, que la 2.1.313 nunca se publicó en Open VSX, en el Microsoft Visual Studio Marketplace ni en ninguno de sus hosts oficiales, y que el incidente «no fue un compromiso de los sistemas de Anthropic ni de los portátiles de sus empleados». Publicó una 2.1.314 limpia. Ninguna de las dos empresas ha dicho cómo obtuvo el atacante acceso de publicación.
Qué hacía la compilación manipulada
Según el análisis de StepSecurity, el atacante tomó la compilación limpia 2.1.312 de Anthropic y antepuso un cargador de 7,386 bytes a su extension.js. El resto del archivo coincidía con el original. El cargador no estaba ofuscado y se ejecutaba con Node.js estándar en cuanto se cargaba la extensión, sin necesidad de ninguna conversación con Claude.
En seis etapas, recopilaba datos del host y los nombres de las variables de entorno que coincidían con patrones como KEY, TOKEN y AWS, añadía una clave SSH etiquetada svc-telemetry a ~/.ssh/authorized_keys, activaba SSH, abría un túnel inverso hacia 134.209.82.225, establecía persistencia (un LaunchAgent llamado com.apple.sysmond en macOS, una tarea programada SysMon en Windows) e informaba de su estado al servidor del atacante.
Eliminar la extensión no elimina nada de eso.
Lo que un marketplace debe verificar más allá del nombre del editor
Una ficha le dice quién escribió el código original. No le dice quién compiló o subió este paquete concreto. El caso de Cursor apunta a tres comprobaciones que el nombre por sí solo no puede sustituir. Dos de ellas solo comprueban números de versión y habrían detectado la falsa 2.1.313. Solo la tercera comprueba el contenido, y es la que también habría detectado la 2.1.312 manipulada, que llevaba un número de versión real.
1. ¿Existe esta versión en el origen? La versión 2.1.313 nunca se publicó en ninguno de los canales oficiales de Anthropic. Una tienda que distribuye una copia de la extensión de otro puede rechazar cualquier versión que el editor nunca publicó. Eso detecta la 2.1.313, pero no una copia manipulada de la 2.1.312, una versión que sí existe.
2. ¿Es el paquete coherente consigo mismo? El paquete «2.1.313» seguía indicando version:”2.1.312” internamente. Solo el manifiesto reempaquetado llevaba el número más alto, y eso bastó para que los editores de código lo trataran como una actualización. Una discrepancia entre el manifiesto y el código que contiene es barata de detectar y es un claro indicio de reempaquetado. De nuevo, esto solo ayuda cuando el atacante sube el número de versión.
3. ¿Es este el artefacto real del editor? Esta es la comprobación que cubre ambas versiones. La 2.1.312 manipulada se diferenciaba de la 2.1.312 real de Anthropic en un único bloque al principio de un archivo, que lanzaba ssh, escribía en authorized_keys y creaba elementos de inicio. Comparar el hash de cada paquete con la versión publicada por el propio editor, y comparar las actualizaciones con la versión anterior en busca de nuevas ejecuciones de procesos, túneles de red o persistencia, examina lo que el paquete es y no cómo se llama.
Las firmas del editor son la forma más limpia de hacer esa tercera comprobación, pero solo si la firma procede del editor. Si una tienda vuelve a firmar o vuelve a alojar un paquete por su cuenta, una firma válida solo demuestra que la tienda lo distribuyó.
Dos plazos enfrentados
El atacante necesitó minutos: la actualización automática entregó el cargador y este se ejecutó al cargarse. Los defensores necesitaron unas 11 horas para retirar las versiones, y cada desarrollador afectado todavía tiene que eliminar la persistencia, rotar todas las credenciales desde un equipo limpio y decidir si reconstruye el sistema. La actualización automática mantiene parcheados a la mayoría de los desarrolladores, así que desactivarla no es la solución. Comprobar lo que instala, sí.
Las cuatro prioridades
Para los equipos de seguridad: Sepa qué editores usan sus desarrolladores y de qué marketplace descarga cada uno. En los equipos con acceso a producción, use listas de permitidos o fije las extensiones, y trate esos portátiles como dispositivos con acceso a producción, con la monitorización correspondiente. Tenga preparado un playbook de incidentes de extensiones: buscar persistencia, rotar desde un equipo limpio, reconstruir en caso de duda.
Para los operadores de marketplaces: Compruebe el contenido de cada paquete con la versión publicada por el propio editor antes de distribuirlo, no solo su número de versión. Rechace las versiones que el editor nunca publicó y las discrepancias de manifiesto, y revise las actualizaciones que añaden nuevas capacidades. Proteja el acceso de publicación como una clave de despliegue de producción.
Para los editores de extensiones: Publique una lista clara de los canales de distribución oficiales, con hashes o firmas que las tiendas y los usuarios puedan comprobar. Cuando aparezca una copia manipulada, indique de forma rápida y clara dónde está la auténtica, como hizo Anthropic en este caso.
Para los desarrolladores: Tras cualquier incidente de extensiones, compare las versiones que tiene instaladas con las notas de la versión o el registro de cambios del propio editor, y compruebe el marketplace desde el que realmente instaló. Si su versión no figura en la lista del editor, considere el equipo afectado.
La tensión de fondo
Casi todo el código que se ejecutó en esos equipos era de Anthropic. Todas las señales en las que se enseña a confiar a los desarrolladores, el nombre, la tienda, el aviso de actualización habitual, apuntaban en la dirección correcta.
Hasta que las tiendas puedan demostrar que lo que distribuyen es lo que el editor publicó realmente, «venía del marketplace oficial» describe de dónde procede un paquete. No le dice qué es.
🎣Sección 03: ¿Es phishing?
¿Legítimo o phishing?
🔬Sección 04: Investigación técnica
Medía la velocidad de la página. Luego vendía sus posiciones.
El 29 de octubre, se sustituyó el script de monitorización del rendimiento que Polymarket cargaba desde su proveedor, DebugBear. El nuevo archivo no robaba contraseñas ni claves. Encontraba el cliente de trading que ya se estaba ejecutando en el navegador de cada trader conectado y lo usaba para vaciar su cuenta.
Los investigadores recuperaron el script, y era JavaScript simple, sin ofuscar. Eso hace que sea inusualmente fácil ver cómo funcionaba. Este análisis se basa en los trabajos de ohey.ca, Report URI y Dancho Danchev.
Los hechos
Las páginas de Polymarket cargaban el script de Real User Monitoring (RUM) de DebugBear desde cdn.debugbear[.]com sin comprobación de integridad. Hacia las 16:54 UTC, el servidor que respondía para esa URL cambió: las cabeceras de respuesta pasaron de las de Google Cloud Storage a otras de estilo nginx, y el archivo se convirtió en un wallet drainer. DebugBear dijo más tarde que los atacantes habían comprometido sus registros DNS. Polymarket eliminó el script en una compilación a las 17:59 UTC y pasó al modo de solo cancelación unos minutos después.
BleepingComputer rastreó unos 2.57 millones de dólares hasta la wallet del atacante, y GoPlus Security contabilizó unas 700 wallets de depósito afectadas. Polymarket dijo que «uno de nuestros proveedores externos fue comprometido» y que reembolsará íntegramente a los traders afectados.
Cómo funcionaba el drainer
1. Encontrar un trader conectado. El script leía tres claves que la propia aplicación de Polymarket escribe en localStorage: polymarket.auth.params (tipo de inicio de sesión y wallet), polymarket.auth.proxyWallet (wallet de depósito) y poly_clob_api_key_map (credenciales de la API de trading). Sin sesión, no hay ataque. También llamaba al propio endpoint /api/geoblock de Polymarket y omitía a los visitantes que tenían bloqueado el trading.
2. Tomar prestado el cliente de trading de la página. El script no llevaba claves propias. En su lugar, recorría el árbol interno de componentes de React, a través de las propiedades __reactFiber$ que React asocia a los elementos del DOM, buscando un objeto con un método postOrder y un método createOrder o createMarketOrder. Ese objeto era el cliente de órdenes activo de Polymarket, con el firmante del usuario incluido. De forma simplificada, la búsqueda era así:
// Simplified illustration of the technique, not the attacker's exact code
for (const el of document.querySelectorAll("*")) {
const key = Object.keys(el).find(k => k.startsWith("__reactFiber$"));
// walk el[key] and its parents, return the first object that has
// postOrder() and createOrder(), plus a signer
}Si el cliente aún no estaba disponible, lo reintentaba 15 veces, con 250 ms de intervalo, y luego recargaba la página para forzar a la aplicación a crear uno.
3. Cargar su configuración. Pedía instrucciones a data.debugbear[.]com/metrics/init. Ese endpoint devolvió un 404 durante el ataque, así que se ejecutaron los valores predeterminados incrustados en el código:
return{recipient:N,minimalPerPosition:10,minimalToProcess:10,priorityToken:"POL"}N es la dirección de Polygon del atacante, 0x3F99139F1C5854bb628c2e576Aaf638e99dFfc18. Las cuentas con un valor inferior a 10 dólares se dejaban en paz.
4. Informar primero de la cuenta. Antes de mover nada, enviaba a /metrics/submit el valor de la cartera, el saldo en efectivo y cada posición, junto con las wallets, el tipo de inicio de sesión, el sistema operativo, la IP y el país.
5. Vaciarla, de dos maneras. Para los usuarios de wallets de navegador, construía un único lote EIP-712 que movía cada posición superior a 10 dólares al atacante con una sola llamada a safeBatchTransferFrom, y lo enviaba a través del propio relayer de Polymarket. Ese lote aparecía como una solicitud de firma de la wallet, así que estos usuarios tenían que aprobarlo. Las cuentas con inicio de sesión por correo electrónico seguían otra ruta, sin aviso de la wallet: vendía las posiciones con órdenes fill-and-kill al 97% del precio, luego al 50%, luego al tick mínimo, y retiraba el efectivo.
6. Cobrar. Cambiaba el efectivo a POL a través de fun.xyz, usando la clave de API del propio frontend de Polymarket, con el atacante como destinatario. Cada transferencia se notificaba a /metrics/update o /metrics/handle con su hash de transacción.
Dónde falló la frontera
Cada paso usaba algo que la página de Polymarket tenía legítimamente: sus claves de almacenamiento, su cliente de órdenes, su relayer, la clave de API de su proveedor de intercambio. Un script de terceros se ejecuta con todos los privilegios de la página que lo carga, así que el script de monitorización y la interfaz de trading eran, en la práctica, el mismo programa.
La Content Security Policy de Polymarket no sirvió de nada, porque todos los hosts que usaba el drainer ya estaban permitidos. script-src-elem permitía cdn.debugbear[.]com, y connect-src permitía data.debugbear[.]com, *.polymarket.com, *.alchemy.com y *.fun.xyz. Como dijo Report URI, «de todos modos no se iba a bloquear nada».
La página confiaba en una URL, no en un archivo. La URL nunca cambió, así que no hizo falta cambiar nada del lado de Polymarket para que el ataque funcionara.
La cadena de ataque paso a paso
[DebugBear URL now serves drainer] -> [polymarket.com loads it, no SRI]
-> [Reads localStorage: login, wallet, CLOB keys] -> [Finds React order client + signer]
-> [Reports portfolio to /metrics/submit] -> [Sells or batch-transfers positions]
-> [Swaps cash to POL via fun.xyz] -> [Attacker wallet] Lo que deberían aprender los defensores
Fije los scripts de terceros con Subresource Integrity: El archivo manipulado tenía un hash distinto del limpio (0525f046…). Un atributo integrity en la etiqueta script habría hecho que el navegador se negara a ejecutarlo. Si el script de un proveedor cambia con demasiada frecuencia para fijarlo, aloje usted mismo una copia revisada.
No trate una lista de permitidos de CSP como integridad: CSP controla desde dónde se carga el código, no qué es ese código. Añada controles basados en hash y un endpoint de notificación, para que un script modificado genere una alerta incluso cuando su host está permitido.
Mantenga los scripts de monitorización fuera de las páginas que pueden mover dinero: RUM y la analítica rara vez necesitan ejecutarse donde un usuario puede operar o retirar fondos. Cárguelos en las páginas de marketing, o en un iframe en sandbox que no pueda acceder al estado de la aplicación.
Exija una acción reciente del usuario para las operaciones de alto valor: Venderlo todo o mover fondos debería requerir una confirmación que el usuario dé activamente, idealmente con un autenticador resistente al phishing, como una passkey o una llave de seguridad física, para que el código que ya está en la página no pueda hacerlo en silencio.
Genere alertas ante comportamientos imposibles: Cientos de cuentas liquidándose en cuestión de minutos es una señal. Disponga de una forma de pausar rápidamente las acciones de alto valor, como hizo Polymarket con el modo de solo cancelación.
🛠️Sección 05: Herramienta de la semana
¿Puede revisar todos los portátiles de desarrollo en busca de la misma puerta trasera en minutos?
Cuando se produce un incidente como el de la extensión de Cursor, la pregunta no es solo «¿la instalamos?». Es «¿sobrevivió algo de lo que dejó?». osquery responde a ese tipo de preguntas en muchos equipos a la vez.
osquery es una herramienta de código abierto, creada originalmente en Facebook y alojada ahora por la Linux Foundation, que expone el sistema operativo como un conjunto de tablas de base de datos. En lugar de escribir un script distinto para cada sistema operativo, se hacen preguntas en SQL: qué claves SSH están autorizadas, qué LaunchAgents y tareas programadas existen, qué procesos se están ejecutando y a dónde se conectan.
# Quickstart (macOS)
brew install --cask osquery
osqueryi-- macOS: look for the LaunchAgent named in the Cursor incident
SELECT label, path, program_arguments FROM launchd WHERE label = 'com.apple.sysmond';
-- Windows: look for the SysMon scheduled task and the Startup folder fallback
SELECT name, action, path, enabled FROM scheduled_tasks WHERE name LIKE '%SysMon%';
SELECT name, path FROM startup_items WHERE name LIKE '%sysmon%';
-- macOS and Linux: list authorized SSH keys for every local user, and look for svc-telemetry
SELECT u.username, k.key_file, k.comment
FROM users u JOIN authorized_keys k USING (uid);
-- Windows: no authorized_keys table, so find the key files and open them
SELECT path, mtime FROM file
WHERE path LIKE 'C:\Users\%\.ssh\authorized_keys'
OR path = 'C:\ProgramData\ssh\administrators_authorized_keys';La tabla authorized_keys no existe en Windows. Allí, la consulta anterior solo encuentra los archivos de claves, así que revise cada uno en busca de la clave svc-telemetry, u obténgalos de su inventario de gestión de la configuración.
Sepa lo que no le dirá. osquery le muestra lo que hay en un equipo en este momento. No le dirá lo que un atacante ya hizo con una credencial robada, y un resultado limpio tras la limpieza no significa que no se llevaran nada. Úselo para encontrar rápidamente los equipos afectados y, después, rote las credenciales y, donde el túnel llegó a conectarse, reconstruya el equipo.
👏Sección 06: Persona de la semana
Paul McCarty
Esta semana destacamos a Paul McCarty, fundador de OpenSourceMalware, una base de datos abierta e impulsada por la comunidad de paquetes maliciosos encontrados en registros como npm, PyPI, RubyGems y Open VSX.
Cuando un paquete o una extensión se vuelve malicioso, los defensores necesitan saberlo rápido: qué versiones, qué indicadores y si el mismo atacante ya lo ha hecho antes. OpenSourceMalware pone esa inteligencia de amenazas a disposición de todos, para que cualquiera pueda consultar un paquete sospechoso en lugar de esperar al informe de un proveedor.
Su trabajo apareció en las noticias de este número. Tras el compromiso de OVHcloud CLI, McCarty vinculó el ataque a la campaña GlassWorm a través de una dirección de wallet de Solana usada en operaciones anteriores de GlassWorm, y descubrió que la cuenta de desarrollador usada para sustituir las versiones llevaba siete meses comprometida.
Por rastrear paquetes maliciosos de forma abierta, donde cualquier defensor puede aprovechar los hallazgos, Paul McCarty es nuestra Persona de la semana. 👏
📅Sección 07: Evento de la semana
Open Source SecurityCon 2026
Open Source SecurityCon es un evento de un día organizado conjuntamente por la Cloud Native Computing Foundation y la Open Source Security Foundation (OpenSSF), que se celebra junto a KubeCon + CloudNativeCon North America.
Sus sesiones abarcan la seguridad de la cadena de suministro, el desarrollo de software seguro, la identidad y el acceso, la arquitectura y las políticas, y las políticas públicas sobre código abierto. OpenSSF y CNCF albergan gran parte de las herramientas para verificar lo que se instala, como TUF, in-toto y Sigstore, así que aquí es donde quienes construyen la firma de paquetes y la verificación de compilaciones comparan experiencias.
📍 Salt Lake City, Utah (Salt Palace Convention Center) 📅 9 de noviembre de 2026
📚Sección 08: Libro de la semana
Todo lo que no escribió, pero aun así distribuye
Software Supply Chain Security: Securing the End-to-End Supply Chain for Software, Firmware, and Hardware, de Cassie Crossley, trata el código, los componentes y los servicios de los que depende una organización pero que no construye ella misma.
Crossley recorre toda la cadena, desde los componentes y las herramientas de los que usted depende hasta cómo se compila, firma, distribuye y actualiza el software, y dónde pueden intervenir los atacantes por el camino. Aborda controles prácticos como las listas de materiales de software, la integridad de las compilaciones y el riesgo de proveedores, y está escrito para quienes tienen que implantar esos controles, no solo hablar de ellos.
Para trazar el mapa del código que distribuye sin haberlo escrito, Software Supply Chain Security es un buen punto de partida.
😅Sección 09: El meme
Si uno de los scripts de sus proveedores o una de las extensiones de sus desarrolladores hubiera cambiado esta mañana, ¿cómo se enteraría?
Esto es todo por este número. Revise sus extensiones, haga una lista de sus scripts de terceros y nos vemos en el próximo número.
The Breach Brief, equipo de Ostorlab