Cadena de suministro Notepad++: cómo un analista colombiano detectó al APT Lotus Blossom

Imagina que tu herramienta de confianza —ese editor de texto que llevas años instalando en cada equipo— se convierte en el vector de infección. El 21 de octubre de 2025, Diego Alejandro Gamboa, analista colombiano de respuesta a incidentes, detectó la primera cepa de lo que terminaría siendo uno de los compromisos de cadena de suministro Notepad++ más graves del año: un ataque atribuido al grupo APT Lotus Blossom, presuntamente patrocinado por un gobierno chino. Lo más incómodo del caso no es la sofisticación del malware —que la tiene—, sino que los EDR sí alertaron y las alertas pasaron desapercibidas. La historia completa, contada por su protagonista, es la charla "Who is Don Ho?" de la DragonJAR Security Conference 2026, y en este artículo la diseccionamos de principio a fin: la línea de tiempo real, las técnicas del atacante, la colaboración global que validó los hallazgos y las lecciones que tu SOC puede aplicar desde hoy.

Who is Don Ho (y por qué importa la pregunta)

Don Ho es el seudónimo del creador de Notepad++, uno de los editores de texto más populares del mundo entre desarrolladores, administradores de sistemas y analistas de seguridad. La charla lleva su nombre porque durante meses él fue el centro del silencio: la pregunta que se hacía la comunidad internacional era quién había detrás de un actualizador que repartía malware desde el sitio legítimo de Notepad++.

La respuesta salió a la luz el 2 de febrero de 2026, cuando Notepad++ confirmó públicamente el compromiso del canal de actualización. Pero la historia empezó mucho antes, y no en un laboratorio de reversing, sino en una alerta de bajo nivel que un analista colombiano decidió no ignorar.

La detección: una alerta de bajo nivel que nadie más revisó

Diego Gamboa lleva años trabajando en respuesta a incidentes en múltiples países: desde industrias de petróleo en Argelia hasta banca en Brasil y telecomunicaciones en México. Ese recorrido le dejó una convicción que resume el problema de fondo de la detección moderna: comprar un EDR no me hace seguro; tener personal revisando alertas mejora muchísimo ese entorno.

El 21 de octubre de 2025, mientras analizaba una empresa (no a Notepad++), una alerta de masquerading llamó su atención: un ejecutable corría con el nombre "Bluetooth Service" cuando en realidad era otra cosa. Ese disfraz —una alerta de muy bajo nivel en cualquier EDR— fue la puerta de entrada a todo el caso. El EDR no bloqueó; solo alertó. Y como suele pasar, la diferencia entre un incidente descubierto y uno invisible fue el análisis humano: ese human-in-the-loop que ninguna herramienta reemplaza.

El canal de actualización: la confianza implícita como vector

¿Para qué comprometer cien empresas si puedo comprometer la cadena de suministro y atacarlas todas de una sola vez? Esa es la lógica económica de un ataque de cadena de suministro, y en este caso el vector fue el canal de actualización de Notepad++: un componente separado, el ejecutable gup.exe, que consulta el servidor oficial y descarga instaladores. El canal recibe confianza implícita: todos los usuarios confiaban en Notepad++ y su actualizador. Para que una máquina quedara infectada bastaba con que alguien le diera a "Actualizar".

El hijacking del updater: cómo funcionaba

El flujo legítimo era simple: gup.exe hacía una petición a notepadplusplus.org, el servidor respondía con una URL que contenía la nueva versión, el actualizador la descargaba y la instalaba. El problema: no verificaba que esa versión descargada fuera legítima y no contuviera malware. Al comprometer los servidores o el servicio de hosting de Notepad++, el atacante podía responder con una URL de un actualizador malicioso. Eso fue exactamente lo que pasó: comprometieron el hosting, y la descarga legítima sirvió un dropper.

La corrección silenciosa de noviembre

Aquí viene uno de los puntos más incómodos de la historia. En noviembre de 2025, Don Ho publicó una corrección del actualizador —verificar que el archivo sí es producido por Notepad++ antes de instalarlo— pero no mencionó ningún compromiso. "Arreglé esto", dijo, sin explicar el porqué. Para Diego, eso es un problema de comunicación de incidentes: que una empresa sea comprometida no es raro; el problema es que lo oculte. La comunicación genera confianza, y en este caso el silencio dejó a los usuarios expuestos desde junio de 2025 mientras el ecosistema esperaba señales de vida.

Línea de tiempo del incidente: de junio 2025 a febrero 2026

La cronología que Diego reconstruye en la charla une todos los puntos hacia atrás, como decía el investigador que él cita:

• Junio 2025: se compromete la cadena de suministro de Notepad++. Desde esa fecha, todo usuario que le diera a actualizar descargaba actividad maliciosa.
• 21 de octubre de 2025: Diego Gamboa hace la primera detección de la cepa a partir de la alerta de masquerading.
• 23 de octubre de 2025: entrega la detección y los indicadores de compromiso a firmas de seguridad. Empieza el trabajo en equipo.
• 25 de octubre de 2025: investigación a nivel de red. En ese momento la hipótesis era un compromiso de DNS que redirigía tráfico hacia el sitio malicioso; aún no se sabía que el sitio legítimo era el comprometido.
• 28 de octubre de 2025: CrowdStrike publica la IP como indicador de compromiso detectado (siete días de retraso frente a la detección inicial). La IP 95.179.2.3, que Diego había identificado como origen del payload, aparecía analizada en fuentes abiertas.
• Noviembre 2025: Notepad++ corrige el actualizador en silencio, sin comunicar el compromiso.
• 2 de diciembre de 2025: según Don Ho, el actor pierde acceso a la infraestructura. Todos los equipos con Notepad++ instalado estuvieron expuestos durante medio año.
• 11 de diciembre de 2025: Kevin Beaumont publica su investigación preliminar sobre un posible compromiso. Diego lo contacta y comienzan a compartir hallazgos.
• 2 de febrero de 2026: Notepad++ confirma el incidente públicamente y publica indicadores de compromiso.
• 3 de febrero de 2026: publicación conjunta con la comunidad y las firmas de seguridad. La atribución cierra: Lotus Blossom.

Disección de la cadena de infección

update.exe: el loader que ninguna herramienta detectaba

La cadena arrancaba con gup.exe descargando update.exe, el dropper o loader. Este binario no lo detectaba ninguna herramienta en ese momento. Sus tácticas eran deliberadamente minimalistas: no descargaba nada más, sino que creaba en disco todo lo necesario — el ejecutable disfrazado "Bluetooth Service", el log.dll que era el payload real, un archivo sin extensión que no se pudo recuperar — y finalmente se autodestruía tras ejecutarse.

DLL sideloading abusando de Bitdefender

El payload usaba DLL sideloading, la forma más usada actualmente para evadir EDR: la DLL maliciosa se coloca junto a un ejecutable legítimo que la carga. En este caso el ejecutable legítimo era de Bitdefender — sí, un antivirus — que tenía una vulnerabilidad de DLL side-loading: al abrirse, cargaba la DLL presente en su mismo directorio. El malware aprovechó esa confianza para ejecutarse. Para el analista, el indicio fue doble: la empresa analizada ni siquiera tenía Bitdefender (¿por qué se ejecuta un binario de Bitdefender?), y dentro cargaba una DLL con API hashing y sin imports visibles.

API hashing: llamar a Windows sin nombrarlo

El malware no importaba textualmente las librerías de Windows. En lugar de eso, recorría el PEB de la memoria, identificaba las librerías cargadas, calculaba el hash de cada nombre y lo comparaba con una tabla de hashes almacenada. Solo cuando el hash coincidía resolvía la dirección de memoria de la API y la llamaba. Resultado: ningún nombre de función aparece en texto plano en el binario, y las firmas estáticas de antivirus y EDR se quedan sin nada que morder. El análisis de Rapid7 identificó además los algoritmos de cifrado FNV1A y MurmurHash — este último con su cadena característica anti-avalancha, un sello que los analistas de malware aprenden a reconocer a simple vista.

conf.c y TinyCC: shellcode compilada en el momento del ataque

Un detalle casi surrealista: el loader ejecutaba un binario renombrado como un proceso de sistema (cbs-host/sbchost), que en realidad era el compilador TinyCC. Ese compilador compilaba en caliente conf.c, una shell en C que venía en texto claro — no compilada — y que se ejecutaba desde ahí. El código ofensivo viajaba como simple texto y solo se convertía en ejecutable en el instante del ataque, otra capa de evasión para el análisis estático.

El command and control: RC4, sockets no estándar y 16 operaciones

La comunicación con el C2 no usaba la librería Wininet de Windows — abrir Wininet dispara alertas inmediatas en los EDR. En su lugar, el malware abría un socket propio no estándar. La comunicación iba cifrada con RC4, protegiendo el canal con una clave que el malware construía concatenando nombre del equipo, nombre de usuario y versión del sistema operativo, y se comunicaba vía HTTP POST por el puerto 4443. El reversing de Rapid7 identificó 16 operaciones del C2: shell interactiva, crear procesos, crear y borrar archivos en disco... capacidad de operación completa. Un detalle que delata la humanidad del adversario: en el protocolo había un error de tipeo — escribieron "slash-do" donde debía ir "slash-domain" — exactamente el tipo de pista que un analista entrenado detecta cuando el EDR solo pasa de largo.

Warbird: la evasión que nació en una conferencia

Durante la charla, Diego dedica un bloque entero a Warbird, una funcionalidad de Windows que permite ejecutar código cifrado a nivel de kernel. La referencia viene de Alex Ionescu, líder de investigación de CrowdStrike, que la presentó en su charla de la Ekoparty y explicó cómo, tras una exfiltración de código de Microsoft, se logró analizarla: entregas código cifrado al kernel de Windows junto con la clave y el hash, el kernel lo descifra, lo monta en memoria RWX y lo ejecuta. Nadie —ningún EDR— lo ve. El sitio Down with the App y la empresa de seguridad Cyrosec unieron ese análisis a una prueba de concepto funcional.

¿Por qué importa aquí? Porque Lotus Blossom estudió y adoptó técnicas basadas en Warbird. Como señala Diego con una mezcla de admiración y alarma, el método de evasión salió de la propia comunidad: una charla pública, un análisis publicado, una PoC... y un APT patrocinado por un gobierno terminó ejecutándolo. La investigación de atribución —el análisis de malware y la identificación de Warbird— fue trabajo de Rapid7; Diego entregó el análisis forense completo de la intrusión.

Atribución: Lotus Blossom

Con los TTPs, los indicadores de compromiso y los indicadores de ataque sobre la mesa, la conclusión fue unánime: el actor es Lotus Blossom, un grupo patrocinado por el gobierno chino según la documentación de la mayoría de investigadores, que ataca a las empresas más grandes de gobierno, defensa, militar y telecomunicaciones, con especial predilección por ataques de cadena de suministro. Es la amenaza que más le teme el mundo corporativo: la APT patrocinada por gobiernos, la más avanzada de la pirámide.

¿Por qué falló la detección?

La charla no busca culpar a las herramientas sino mostrar el hueco real:

• Los EDR sí alertaron, pero nadie revisaba. En la mayoría de incidentes de su carrera, Diego encuentra que todos los EDR presentaban alerta; el problema es comprar el EDR sin contemplar el costo humano de tener personas analizándolas.
• Darktrace en modo escucha. En un incidente de ransomware que Diego analizó, la empresa tenía Darktrace —uno de los mejores analizadores de red del mercado— alertando de un command and control en la red tres meses antes... y nadie revisaba esas alertas.
• Comunicación tardía del vendor. Notepad++ corrigió en noviembre de 2025 pero no informó del compromiso hasta febrero de 2026, dejando a los usuarios sin contexto para cazar el indicador.
• Falta de Blue Team dedicado. La respuesta a incidentes es un trabajo con mucha demanda y poca gente dispuesta a hacerla; la escasez de talento especializado deja huecos críticos.

Recomendaciones prácticas para tu SOC

De la charla y del bloque de preguntas salen cinco líneas de acción concretas:

1. Refuerza el liderazgo técnico. Patrón repetido: 10 o 20 analistas SOC liderados por alguien con experiencia administrativa pero no técnica. Hay que encontrar líderes senior capaces de transmitir conocimiento, con sesiones de lessons learned y shadowing.
2. Presupuesta el costo humano de cada herramienta. Una herramienta fabulosa en manos sin entrenamiento no sirve: hay que saber en manos de quién se pone. Verifica que haya SLAs internos para revisar alertas de bajo nivel, que son justo las que delatan a los APT.
3. Sincroniza y correlaciona fuentes. Como contó el público, sin EDR sincronizados con la NDR no hay correlación; y a veces el reto es incluso el ETL para entregarle la información a la herramienta. Las comunicaciones no se pueden ocultar: con un firewall en medio —y mejor aún con Sysmon— el C2 aparece.
4. Verifica firmas y hashes en el proceso de actualización. La raíz del caso Notepad++ fue un updater que no validaba lo que descargaba. Audita que tus procesos de actualización verifiquen la firma del binario.
5. Entrena a tu equipo en técnicas de evasión. DLL sideloading, API hashing, masquerading y Warbird deben ser vocabulario de tu equipo. Detectar que un "proceso de sistema" no lo es, o leer un error de tipeo en un protocolo C2, es la diferencia entre seis meses de compromiso y una detección temprana.

Preguntas frecuentes

¿Qué fue el ataque de cadena de suministro a Notepad++?

Fue el compromiso del canal de actualización de Notepad++ detectado el 21 de octubre de 2025 por el analista colombiano Diego Gamboa. Al comprometer el hosting de notepadplusplus.org, el atacante redirigió las descargas del actualizador gup.exe hacia un loader malicioso (update.exe). Desde junio de 2025, cualquier usuario que ejecutara "Actualizar" podía descargar malware. El caso se atribuyó al APT Lotus Blossom y se confirmó oficialmente el 2 de febrero de 2026.

¿Qué técnicas usó el malware de Notepad++?

Combinó DLL sideloading abusando de un ejecutable legítimo de Bitdefender, API hashing para llamar a las APIs de Windows sin importarlas (FNV1A y MurmurHash), masquerading de procesos de sistema, compilación en caliente de la shellcode conf.c con TinyCC, socket no estándar en lugar de Wininet y un C2 cifrado con RC4 vía HTTP POST en el puerto 4443 con 16 operaciones identificadas por Rapid7.

¿Por qué el EDR no detectó el malware de Notepad++?

En realidad sí lo detectó: alertó del masquerading, aunque de bajo nivel. El fallo fue organizacional: nadie revisaba esas alertas. El caso demuestra que comprar un EDR o un NDR como Darktrace sin analistas capacitados que revisen las alertas deja la detección en nada.

¿Quién es Don Ho?

Es el seudónimo del creador y mantenedor de Notepad++. Su nombre da título a la charla porque durante meses fue el personaje central del silencio: corrigió el actualizador en noviembre de 2025 sin comunicar el compromiso, y solo el 2 de febrero de 2026 confirmó el incidente y publicó indicadores de compromiso, agradeciendo a los investigadores que compartieron la historia de la investigación.

Conclusión: la detección es humana

El caso Notepad++ demuestra que un ataque de cadena de suministro puede permanecer invisible durante medio año cuando la detección depende exclusivamente de herramientas sin personal capacitado. La investigación liderada por Diego Gamboa y validada con la comunidad —Kevin Beaumont, Rapid7, CrowdStrike— dejó tres lecciones: compartir información rápidamente multiplica el alcance (una alerta de un analista colombiano se convirtió en alerta global cuando la contó quien tenía la audiencia), contar con analistas con experiencia real es insustituible, y los procesos de verificación de firmas y actualización segura deben existir en todas partes. La frase que resume la charla: comprar la herramienta no soluciona la vida; hay que saber en manos de quién se pone.

Para seguir aprendiendo sobre seguridad ofensiva a partir de casos reales, regístrate en https://www.dragonjarcon.org. Allí podrás acceder a charlas como la que acabas de leer y conocer más sobre DragonJARCON, el congreso anual que reúne en Colombia a profesionales e investigadores de la seguridad informática.

Y si tu organización necesita este mismo nivel de análisis y escrutinio, conoce los servicios de seguridad ofensiva de DragonJAR en https://www.dragonjar.org/servicios-de-seguridad-informatica.

Mira la Charla Completa Sobre el caso Notepad++

Toda la charla de Diego Gamboa —de la detección del 21 de octubre a la atribución a Lotus Blossom y las preguntas del público— está disponible en YouTube: