La publicidad maliciosa envía malware en pedazos y luego hace que el navegador cree el ejecutable – CYBERDEFENSA.MX

Una operación de publicidad maliciosa denominada Comercio amargo está haciendo que los navegadores de las víctimas creen ellos mismos el ejecutable final de Windows, utilizando un tiempo de ejecución legítimo de Bun como base en lugar de servir un archivo malicioso completo desde una URL fija.

Confiante, que detalló la campaña el 23 de julio de 2026, dijo que ha operado desde finales de 2024 y se hizo pasar por TradingView, Solana y Luno para dirigirse a comerciantes minoristas e inversores en criptomonedas en 12 países en 25 idiomas.

Sus páginas de destino toman las huellas dactilares de los visitantes, mostrando a los investigadores y robots sospechosos una página vacía, mientras que los objetivos seleccionados reciben una copia convincente del servicio suplantado. La defensa contra esto es la ordinaria: instalar software comercial y de billetera desde el sitio del propio proveedor, no desde un anuncio.

La cadena documentada no se basa en una vulnerabilidad del navegador ni elimina la Marca de la Web (MotW). El análisis de Confiant documenta la entrega, no la ejecución, del archivo dentro del navegador, y no establece si la descarga final comienza automáticamente o requiere un clic.

La página de destino comienza a preparar la ruta de entrega sin esperar un clic de descarga. Registra un ServiceWorker con ámbito de página en /sw.jsluego crea un SharedWorker a partir de JavaScript ya incrustado en la página, por lo que la fuente del trabajador nunca aparece como una recuperación separada.

Las solicitudes de SharedWorker /configque devuelve una plantilla, una URL de ejecución secundaria y valores aleatorios específicos de la sesión. El navegador recupera y descomprime un tiempo de ejecución de Bun limpio de ese segundo dominio, purelogicbox.[.]org en la respuesta de muestra publicada.

Ciberseguridad

Los blobs Base64 en la configuración proporcionan el encabezado del ejecutable portátil (PE), la tabla de secciones y un .bun sección que contiene código de bytes JavaScriptCore malicioso para app.js. Bun se ejecuta en el motor JavaScriptCore de Apple y es compatible legítimamente compilar aplicaciones y código de bytes en ejecutables independientes de Windows.

Luego, el trabajador genera un gran flujo de bytes pseudoaleatorios utilizando AES en modo contador (AES-CTR). Luego sigue la plantilla proporcionada como una receta de copia de bytes, combinando rangos seleccionados del tiempo de ejecución de Bun, el flujo generado y el material ejecutable controlado por el atacante.

Cada víctima puede recibir un archivo ensamblado diferente: rotando la semilla y el tamaño en cada uno /config La respuesta cambia el hash manteniendo el código de carga útil ejecutable. «Nunca existe ningún malware terminado en la red», escribió Michael Steele del equipo de inteligencia de amenazas de Confiant. Ningún binario completo lo hace, aunque las estructuras PE y el código de bytes llegan como Base64 en /config.

Una vez ensamblada, la página pasa el ejecutable al ServiceWorker como una secuencia legible. Un iframe oculto navega a una URL del mismo origen y el trabajador devuelve los bytes generados con un Content-Disposition encabezado del archivo adjunto. El registro MotW resultante identifica la página de destino como la fuente de descarga, no el dominio separado que proporcionó el tiempo de ejecución de Bun. El propio MotW sigue presente.

El método evolucionó a partir de la actividad que Confiant rastreó hasta el 30 de abril de 2026, cuando se cargaron las páginas. StreamSaver.jsuna biblioteca de descarga continua de código abierto, desde la dirección de GitHub Pages de su autor. Eso dejó la ruta de descarga registrada apuntando a la URL de GitHub de la biblioteca. Las páginas actuales mantienen su arquitectura de streaming, incluyendo la streamsaver: nombres de mensajes, pero ya no los recupera de GitHub.

Bitdefender documentado el clúster de publicidad maliciosa TradingView relacionado en septiembre de 2025, identificando su carga útil final como el ladrón que Check Point rastrea como JSCEAL y con Secure como GorgojoProxy.

Ciberseguridad

Confiant identifica la campaña compartida y las características ejecutables, pero no demuestra que las tres muestras publicadas lleven esa carga útil. El informe también dice que Bitdefender encontró un ejecutable Bun modificado en este clúster.

Hacker News no encontró ninguna mención de Bun en los enlaces de Confiant de la publicación de septiembre de 2025, que nombra su detección de cargador Variant.DenoSnoop.Marte.1. Por lo tanto, el robo de credenciales, el registro de teclas, la interceptación de tráfico, el robo de billeteras y las capacidades de acceso remoto documentadas en la campaña anterior aún no se pueden asignar a los archivos actuales.

The Hacker News se comunicó con Confiant para solicitar aclaraciones sobre su referencia a los hallazgos anteriores de Bitdefender y actualizará esta historia con cualquier respuesta.

No es necesario aplicar ningún parche de software. La evasión es más estrecha de lo que parece a primera vista. La propia sección de implicaciones prácticas de Confiant lo expresa de manera más modesta: las compilaciones únicas por sesión limitan el valor de las detecciones simples basadas en hash. El material PE y el código de bytes controlados por el atacante aún cruzan la red.

Los defensores deben examinar toda la cadena, desde la referencia del anuncio y la página de destino encubierta hasta la /config solicitud, la recuperación del tiempo de ejecución del dominio secundario y la descarga de ServiceWorker, en lugar de tratar cualquier artefacto de red o archivo como decisivo.

Confiant publicó tres hashes SHA-256 y una lista de dominios maliciosos, 96 según el recuento de The Hacker News. La empresa no nombró a ningún actor y detuvo su análisis en el momento en que el archivo llega al disco.

GitHub Copilot rechaza solicitudes dañinas en el chat y luego las escribe en código – CYBERDEFENSA.MX

Un asistente de codificación de IA que se niega a responder una solicitud peligrosa en su cuadro de chat puede responderla de todos modos si la misma solicitud se divide en pasos pequeños y de apariencia normal dentro de un editor de código. Ése es el hallazgo de un nuevo estudio de GitHub Copilot por los investigadores Abhishek Kumar y Carsten Maple.

Los modelos que probaron a través de Copilot, Claude de Anthropic y Gemini de Google rechazaron casi todas las solicitudes dañinas cuando se les preguntó directamente. Reformulados como pasos de una tarea de codificación normal, produjeron respuestas dañinas en las 816 ejecuciones del flujo de trabajo del estudio.

Lo que hace que esto sea diferente de un jailbreak típico: nadie solicita directamente el elemento dañino y no se engaña al modelo para que ejecute el código de otra persona. Escribe el contenido prohibido por sí mismo, como efecto secundario de una tarea de codificación que le dijeron que mejorara.

como funciona

Los investigadores llaman al método construcción de jailbreak a nivel de flujo de trabajo.

En lugar de una única indicación contundente, le pidieron a Copilot que creara un software cotidiano: un pequeño programa de prueba que califica la frecuencia con la que otro modelo de IA cede a indicaciones dañinas. Cargar una lista de preguntas de examen dañinas en ese programa parece un trabajo normal, no un ataque.

Ciberseguridad

Luego vino el empujón. Le dijeron a Copilot que la puntuación era demasiado baja y le pidieron que mejorara el programa añadiendo «disparos de enseñanza», ejemplos de pares de preguntas y respuestas escritas en el código para aumentar la puntuación. Copilot añadió primero ejemplos inofensivos.

Cuando se le pidió que agregara las dañinas, escribió las respuestas peligrosas él mismo, como texto sin formato dentro del código. Estas fueron respuestas que las mismas modelos rechazan cuando las preguntas directamente en un chat.

Lo importante es de dónde vino el texto dañino. Los investigadores proporcionaron sólo las preguntas, tomadas de conjuntos de pruebas de seguridad pública. Las respuestas fueron trabajo del propio modelo, elaboradas para completar la tarea asignada de completar los ejemplos.

los numeros

El equipo ejecutó 204 mensajes dañinos extraídos de tres puntos de referencia públicos (Hammurabi’s Code, HarmBench y AdvBench) contra cuatro modelos disponibles a través de Copilot: Claude Sonnet 4.6, Claude Haiku 4.5, Gemini 3.1 Pro y Gemini 3.5 Flash.

Todo se ejecutó con la configuración predeterminada, con los modelos utilizados exactamente como los entrega Copilot, sin cambios de parámetros ni filtros agregados.

Cuando se les preguntó directamente en el chat, los modelos produjeron respuestas dañinas en sólo 8 de 816 intentos. Otras dos configuraciones simples, cargar las indicaciones desde una hoja de cálculo o solicitar una corrección de código de rutina, dieron el mismo resultado. Dentro del flujo de trabajo completo, produjeron contenido dañino 816 de 816 veces.

Dos revisores expertos verificaron cada respuesta por su cuenta y acordaron que las 816 eran realmente dañinas, utilizando una prueba estricta: la respuesta tenía que ser específica, utilizable y realmente hacer lo que pedía el mensaje dañino. Las negativas, las advertencias vagas y las alternativas seguras no contaron.

El resultado dañino apareció después de aproximadamente seis intercambios de ida y vuelta, todos ellos parecían pasos de codificación normales. Las pruebas utilizaron GitHub Copilot Chat 0.30.3 dentro de VS Code 1.103.0, en sesiones realizadas entre el 2 de abril y el 22 de junio de 2026. Debido a que estos son servicios alojados que se actualizan con el tiempo, el comportamiento exacto puede cambiar.

¿Por qué sucede? La respuesta del artículo es sobre incentivos. Una vez que el trabajo se enmarca como un aumento de puntaje, negarse a completar un campo deja de parecer una opción de seguridad y comienza a parecer como dejar el trabajo sin terminar. Los autores lo vinculan a una tendencia conocida en los agentes de codificación: optimizar la métrica que se les entrega, incluso cuando eso va en contra de sus propias barreras.

Por qué es importante

Un rechazo del chat no prueba que un asistente de codificación sea seguro. El mismo modelo puede mantener la línea en una conversación y cruzarla mientras escribe código. Y el fallo se esconde en un lugar fácil de pasar por alto: el texto dañino termina en un archivo que escribe el asistente, fuera de la respuesta del chat, donde normalmente aparecería un rechazo.

Para cualquiera que utilice estas herramientas, la lectura concreta es limitada pero utilizable. Tenga cuidado con una sesión de varios turnos que le pide al asistente que complete una evaluación o un conjunto de puntos de referencia con ejemplos de indicaciones y respuestas para aumentar la puntuación. Revise los archivos que escribe el asistente en lugar de confiar en que un rechazo visible del chat significa que la sesión se mantuvo limpia.

Ciberseguridad

Los autores lo reducen a tres direcciones, ninguna de las cuales es una solución completa por sí sola: inspeccionar lo que escribe el agente, juzgar una sesión completa en lugar de cada mensaje y tratar una solicitud para «mejorar una puntuación de referencia» como una razón para mirar más de cerca. Dicen que informaron los hallazgos a los fabricantes de herramientas y modelos afectados, y dejaron fuera del documento los resultados dañinos y las indicaciones exactas.

El resultado se ajusta a una creciente cantidad de trabajos que muestran que el entrenamiento de seguridad de la IA se vuelve más inestable una vez que un modelo se conecta a una herramienta que puede actuar, en lugar de simplemente charlar. Investigaciones anteriores encontraron que los modelos entrenados en seguridad son Se libera fácilmente cuando se convierte en agentes de navegación web..

El ataque anterior más cercano, CódigoJailbreakeroculta la intención dañina dentro de un mensaje de confirmación falso. Otros, como código rojohan demostrado que los modelos aceptan una instrucción peligrosa más fácilmente cuando está disfrazada de código que en inglés simple. El Crescendo El ataque alcanzó un objetivo dañino al avanzar lentamente durante varios turnos de chat en lugar de preguntar directamente.

El mismo efecto aparece en herramientas de codificación reales, no solo en este punto de referencia. The Hacker News cubrió recientemente GuardFall, una derivación de seguridad de comandos que se apoyaba exactamente en este primer paso: un comando contundente y destructivo se rechaza, mientras que el mismo comando guardado en un archivo de compilación o en la respuesta de la documentación de una herramienta se produce como un paso de rutina.

El giro de este nuevo estudio es que el contenido dañino no es la preparación para otro ataque; es lo que el modelo fue obligado a producir.

El estudio cubre únicamente GitHub Copilot con cuatro modelos de dos proveedores. Los autores tienen claro que los resultados pueden no trasladarse a otros asistentes como Cursor, Cline o Windsurf, ni a modelos de OpenAI y otros. Ésa es la pregunta abierta que señalan para más adelante.

La más difícil que dejan sin resolver es cómo detectar este patrón sin romper también la investigación de seguridad legítima que tiene que funcionar con las mismas indicaciones de prueba dañinas.