Ataque a Notepad++

El compromiso de uno de los editores más populares entre desarrolladores demuestra que ningún software está a salvo de los ataques sofisticados de actores estatales.

La pesadilla de todo desarrollador

Imagina que tu herramienta de trabajo diaria, ese programa que usas decenas de veces al día y en el que confías ciegamente, se convierte silenciosamente en un vector de ataque. No porque tenga un fallo de seguridad, sino porque actores respaldados por gobiernos extranjeros secuestraron su mecanismo de actualización durante seis meses.

Esto no es ciencia ficción. Es exactamente lo que ocurrió con Notepad++, uno de los editores de texto más populares entre programadores y usuarios técnicos de todo el mundo.

La cronología del ataque

Junio 2025: Los atacantes comprometen la infraestructura de hosting de Notepad++ a nivel del proveedor de alojamiento.

Junio-Diciembre 2025: Durante seis meses, interceptan selectivamente el tráfico de actualización de usuarios específicos, dirigiéndolos hacia servidores maliciosos que distribuyen versiones envenenadas del software.

Diciembre 2025: Se lanza Notepad++ versión 8.8.9 para corregir las vulnerabilidades en el proceso de verificación de actualizaciones.

2 de diciembre 2025: Se termina finalmente el acceso de los atacantes al proveedor de hosting.

Enero 2026: Un usuario en los foros comunitarios de Notepad++ reporta un comportamiento extraño del actualizador que se conecta a un servicio temp.sh sospechoso.

Febrero 2026: Se revela públicamente el alcance completo del incidente. Notepad++ migra a un nuevo proveedor de hosting con medidas de seguridad reforzadas.

Cómo funcionó el ataque: Una maestría técnica

Lo que hace especialmente peligroso este ataque es su sofisticación multinivel y su naturaleza selectiva.

El compromiso inicial

Los atacantes no vulneraron el código fuente de Notepad++ ni su repositorio oficial. En su lugar, atacaron la infraestructura de hosting compartido donde se alojaba el sitio web notepad-plus-plus.org. Esto les dio control sobre:

El tráfico HTTP entre los usuarios y los servidores de actualización

Las credenciales de servicios internos (mantuvieron acceso incluso después de perder el control del servidor en septiembre 2025)

La capacidad de redirigir solicitudes de actualización hacia servidores bajo su control

La distribución selectiva

Este no fue un ataque indiscriminado. Los ciberdelincuentes:

• Monitorizaban el tráfico para identificar objetivos de alto valor

• Redirigían solo a ciertos usuarios hacia servidores maliciosos (aproximadamente una docena de máquinas fueron comprometidas)

• Cambiaban constantemente los servidores de comando y control, dominios y técnicas de infección

Los objetivos confirmados incluyen:

• Individuos en Vietnam, El Salvador y Australia

• Una organización gubernamental en Filipinas

• Una organización financiera en El Salvador

• Un proveedor de servicios TI en Vietnam

Las tres cadenas de infección

Investigadores de Kaspersky y Rapid7 han identificado tres secuencias de ataque diferentes que evolucionaron durante los seis meses de la campaña:

Cadena #1 (Julio-Agosto 2025): El "update.exe" malicioso recopilaba información del sistema (whoami, tasklist) y la enviaba a temp.sh. Utilizaba DLL side-loading abusando de un ejecutable legítimo de ProShow para desplegar dos shellcodes: uno falso como distracción y otro real que descargaba un beacon de Cobalt Strike.

Cadena #2 (Septiembre 2025): Los atacantes refinaron su técnica, recopilando más información del sistema (agregando netstat a los comandos anteriores) y desplegando scripts Lua diseñados para ejecutar shellcode. La información se enviaba ahora a self-dns.it.com/list.

Cadena #3 (Octubre 2025-Diciembre 2025): La versión más sofisticada. Introdujo el backdoor Chrysalis, una herramienta personalizada capaz de:

• Recopilar información detallada del sistema

• Establecer conexión con servidores de comando y control

• Generar shells interactivas

• Crear procesos arbitrarios

• Realizar operaciones de archivos (subir/descargar/eliminar)

• Auto-eliminarse para borrar rastros

Todo esto usando esteganografía – ocultando código malicioso dentro de archivos de imagen PNG aparentemente inofensivos.

El arsenal tecnológico del atacante

Los investigadores han documentado un impresionante nivel de sofisticación técnica:

Abuso de software legítimo

Los atacantes utilizaron binarios legítimos y firmados digitalmente para cargar DLLs maliciosas (técnica conocida como DLL side-loading):

• Bitdefender Submission Wizard

• Trend Micro ejecutables

• ProShow software

Esto permite evadir la detección, ya que el proceso legítimo aparece como confiable en el sistema operativo.

Microsoft Warbird

Descubrieron y adaptaron un framework interno de Microsoft no documentado llamado Warbird, originalmente diseñado para proteger código, para ejecutar shellcode malicioso. Se basaron en una investigación pública de apenas meses antes.

Herramientas comerciales

Combinaron malware personalizado (Chrysalis) con frameworks comerciales ampliamente usados en operaciones legítimas:

• Metasploit

• Cobalt Strike

Esta mezcla dificulta la atribución y hace más difícil distinguir entre actividad legítima y maliciosa.

La atribución: Lotus Blossom (APT31)

Rapid7 ha atribuido este ataque con "confianza media" a un grupo de amenazas persistentes avanzadas (APT) conocido como Lotus Blossom, también referido como:

• Billbug

• Bronze Elgin

• Lotus Panda

• Raspberry Typhoon

• Spring Dragon

• Thrip

• Violet Typhoon

• APT31

Este grupo, vinculado al gobierno chino, es conocido por:

• Atacar organizaciones gubernamentales y del sector financiero en el sudeste asiático

• Usar DLL side-loading como técnica principal

• Combinar herramientas personalizadas con software comercial

• Mantener campañas prolongadas y sigilosas

La conexión se estableció basándose en:

• Similaridades en las técnicas (DLL side-loading de Bitdefender y Trend Micro)

• Infraestructura superpuesta con campañas previas

• Objetivos geográficos consistentes (sudeste asiático)

• Metodología de ataque

Por qué este ataque es diferente

No fue un bug, fue un secuestro de infraestructura

A diferencia de los típicos ataques de supply chain que explotan vulnerabilidades en el código, este fue un compromiso a nivel de infraestructura de hosting. Esto significa que:

• El código fuente de Notepad++ nunca fue comprometido

• El repositorio oficial permaneció seguro

• Los desarrolladores hicieron todo "bien" desde el punto de vista del código

Y aun así, los usuarios fueron infectados.

La verificación de integridad falló

Notepad++ confiaba en su actualizador WinGUp para verificar la autenticidad de las actualizaciones. Sin embargo, la verificación era insuficiente cuando un atacante podía:

• Interceptar el tráfico de red

• Servir archivos diferentes a usuarios seleccionados

• Mantener las apariencias de normalidad para la mayoría

Duró seis meses sin detectarse

A pesar de que:

• Los sensores de seguridad del DHS (en casos de agencias estadounidenses afectadas) generaron múltiples alertas

• Los usuarios reportaron comportamientos extraños en los foros

• El tráfico sospechoso era visible

...Los atacantes mantuvieron acceso durante medio año, adaptando constantemente sus técnicas.

Las lecciones críticas para desarrolladores y usuarios

Para desarrolladores de software

1. La infraestructura de hosting es parte de la superficie de ataque

• Eligir proveedores con prácticas de seguridad rigurosas

• Implementar controles adicionales más allá de la firma de código

• Monitorizar activamente el tráfico de actualización

2. La verificación de integridad debe ser robusta

• No confiar únicamente en HTTPS

• Implementar firma criptográfica de múltiples capas

• Validar no solo el paquete, sino también el origen

3. La visibilidad es crucial

• Logs detallados de todas las solicitudes de actualización

• Sistemas de alerta ante patrones anómalos

• Transparencia con los usuarios sobre incidentes

3. Separar responsabilidades

El hosting del sitio web y el hosting de actualizaciones pueden ser diferentes

Diversificar proveedores para limitar el radio de explosión

Para usuarios y organizaciones

1. Incluso el software de confianza puede ser vector de ataque

• Notepad++ es de código abierto, ampliamente revisado y confiable

• Y aun así fue comprometido a nivel de distribución

2. Las actualizaciones automáticas son convenientes pero arriesgadas

• Considerar desactivarlas para software crítico

• Implementar períodos de espera antes de actualizar

• Revisar notas de cambio y verificar firmas manualmente

3. Los sistemas de detección importan

• Los sensores de seguridad del DHS detectaron las conexiones sospechosas

• Sin EDR (Endpoint Detection and Response) o monitorización de red, nunca lo habrías sabido

4. La confianza debe verificarse constantemente

• Auditar regularmente el software instalado

• Monitorizar conexiones de red salientes

• Investigar comportamientos inusuales incluso de aplicaciones "confiables"

Señales de compromiso

Si usaste Notepad++ entre junio y diciembre de 2025, verifica lo siguiente:

Conexiones de red sospechosas:

• temp.sh

• self-dns.it.com

• api.skycloudcenter.com

• 45.76.155.202

• 45.32.144.255

• 95.179.213.0

Archivos sospechosos:

• update.exe, install.exe o AutoUpdater.exe descargados fuera del flujo normal

• ProShow.exe o BluetoothService.exe en ubicaciones inusuales

• Scripts Lua inesperados

• Archivos PNG en directorios de sistema

Comportamiento del sistema:

• Procesos que ejecutan comandos como whoami, tasklist, netstat, systeminfo sin intervención del usuario

• Conexiones a dominios cloud inusuales cada 48 horas

• DLLs cargadas desde ubicaciones no estándar

La respuesta de Notepad++

El mantenedor Don Ho ha tomado las siguientes medidas:

• Migración completa de hosting a un nuevo proveedor con "prácticas significativamente más fuertes"

• Rotación de todas las credenciales asociadas con la infraestructura

• Fortalecimiento del proceso de actualización con salvaguardas adicionales

• Transparencia total con la comunidad sobre el incidente

La versión 8.8.9 y posteriores incluyen mecanismos de verificación mejorados que hacen este tipo de ataque mucho más difícil.

El panorama más amplio: Supply chain, el campo de batalla actual

Este incidente de Notepad++ es solo uno más en una creciente lista de ataques a la cadena de suministro de software:

• SolarWinds (2020): Comprometieron el proceso de compilación

• 3CX (2023): Infectaron instaladores oficiales

• XZ Utils (2024): Intentaron insertar backdoor en biblioteca crítica de Linux

• Notepad++ (2025): Secuestraron la infraestructura de distribución

La tendencia es clara: los atacantes evolucionan más rápido que las defensas.

Por qué los atacantes prefieren los ataques supply chain

1. Economía de escala: Un solo compromiso afecta a miles o millones de usuarios

2. Confianza implícita: Los usuarios confían en las actualizaciones de software conocido

3. Evasión de defensas: El código malicioso viene firmado y de fuentes legítimas

4. Persistencia: Mantienen acceso mientras la víctima use el software

El dilema de las actualizaciones automáticas

Las actualizaciones automáticas fueron diseñadas para mejorar la seguridad, asegurando que los usuarios reciban parches rápidamente. Pero también crean un vector de ataque perfecto:

• Los usuarios no revisan manualmente las actualizaciones

• La confianza es automática

• Las alertas de seguridad raramente se activan

• La superficie de ataque es enorme

No hay una respuesta fácil. Desactivar las actualizaciones automáticas te expone a vulnerabilidades conocidas. Mantenerlas activas te expone a compromisos de la cadena de suministro. La clave está en el equilibrio y la vigilancia.

Qué hacer ahora mismo

Si usaste Notepad++ entre junio-diciembre 2025:

1. Actualiza inmediatamente a la versión 8.8.9 o posterior

2. Ejecuta un escaneo completo con un antivirus actualizado y herramientas anti-malware

3. Revisa logs de red buscando las direcciones IP y dominios mencionados

4. Considera una reinstalación limpia de tu sistema operativo si detectas signos de compromiso

5. Cambia contraseñas de cuentas críticas si tu máquina procesó información sensible

Como medida preventiva general:

1. Implementa monitorización de red para detectar comportamientos anómalos

2. Usa herramientas EDR que puedan detectar técnicas como DLL side-loading

3. Mantén software actualizado pero con un período de prueba para actualizaciones críticas

4. Diversifica tus fuentes de software y evita depender de un único proveedor

5. Educa a tu equipo sobre los riesgos de supply chain