Manuel Roccon : 6 noviembre 2025 06:58
En septiembre se publicó una nueva vulnerabilidad que afecta a Notepad++. Esta vulnerabilidad, identificada como CVE-2025-56383, puede consultarse en el sitio web del NIST para obtener más información. CVE-2025-56383 es una vulnerabilidad de secuestro de DLL que afecta al editor de texto Notepad++ versión 8.8.3 y posiblemente a versiones posteriores.
Al explotar esta debilidad, un atacante puede engañar a la aplicación para que cargue una DLL maliciosa que tiene el mismo nombre que una biblioteca legítima requerida por el programa (un ejemplo común involucra archivos DLL en la carpeta de complementos).
Si el ataque tiene éxito, el código malicioso se ejecuta con los mismos permisos que el usuario que ejecuta Notepad++, lo que permite la ejecución de código arbitrario en el sistema objetivo.
Sin embargo, es crucial tener en cuenta que esta CVE ha sido etiquetada como «Disputada» por varias fuentes.
Esto sucede porque el ataque solo es posible si el usuario ha instalado Notepad++ en un directorio que, por error o mala configuración, permite el acceso de escritura a usuarios sin privilegios.
En las instalaciones estándar de Windows, un usuario normal no debería tener permiso para modificar archivos en la carpeta de instalación del programa, lo que reduce el problema de una vulnerabilidad inherente del software a un riesgo resultante de una configuración insegura del sistema operativo.
Se ha publicado un pequeño archivo que muestra, con algunas capturas de pantalla, cómo es posible realizar el secuestro de la biblioteca NppExport.dll, visible en el siguiente enlace, utilizando Notepad++.
El secuestro de DLL es un método de ataque que explota la forma en que el sistema operativo Windows busca y carga las bibliotecas de vínculos dinámicos (DLL) que una aplicación necesita para ejecutarse.
En esencia, un atacante engaña a una aplicación legítima para que cargue y ejecute una DLL maliciosa en lugar de la DLL original esperada.
El secuestro de DLL es similar a la inyección de DLL, pero difiere en su mecanismo: la inyección de DLL es una técnica genérica que fuerza a un proceso en ejecución a cargar una DLL arbitraria (a menudo maliciosa) directamente en la memoria, mientras que el secuestro de DLL explota la gestión incorrecta de la ruta de búsqueda de una DLL existente o faltante para provocar que se cargue la versión maliciosa en su lugar.
Analicemos qué se entiende por secuestro de DLL y probémoslo directamente en Notepad++.
Existen varias variantes de esta técnica:
Secuestro del orden de búsqueda de DLL : Aprovecha el orden de búsqueda predeterminado de Windows. El atacante coloca la DLL en una carpeta con prioridad (por ejemplo, la misma carpeta que el ejecutable de la aplicación).
Carga lateral de DLL: Una forma muy común. El atacante copia un ejecutable legítimo y de confianza (por ejemplo, un programa con firma digital) y su DLL maliciosa (con el nombre de la DLL esperada) a una carpeta externa, a menudo accesible para el usuario. El código malicioso se ejecuta en el contexto de un proceso de confianza, eludiendo las comprobaciones de seguridad basadas en la integridad o las listas blancas de ejecutables.
Sustitución de DLL: Un enfoque más agresivo y directo donde el atacante omite el orden de búsqueda para sobrescribir la DLL original y legítima con un archivo malicioso en la misma ruta exacta.
Secuestro de DLL fantasma: Esta técnica aprovecha una aplicación que intenta cargar una DLL que no existe en el sistema (quizás debido a un error de programación o una dependencia innecesaria). El atacante coloca la DLL maliciosa con el nombre de archivo faltante, forzando así su carga.
Cuando una aplicación necesita cargar una DLL y no especifica su ruta completa y absoluta, Windows busca en un conjunto de directorios predefinidos en un orden específico.
El orden de búsqueda de las DLL (que puede variar ligeramente según las API de carga y las configuraciones del sistema) normalmente incluye:
Un atacante aprovecha entonces esta secuencia para colocar una DLL maliciosa (con el mismo nombre que la DLL legítima faltante, esperada o de reemplazo) en uno de los directorios que Windows controla, antes de la ubicación de la DLL real.
Cuando se inicia la aplicación, Windows encuentra y carga la DLL maliciosa antes de llegar a la ubicación de la DLL legítima (o cargando una DLL diferente si ha sido reemplazada).
El código malicioso que contiene esta DLL se ejecuta posteriormente, a menudo con los mismos privilegios que la aplicación que la cargó.
Esta técnica es popular entre los atacantes porque les permite:
Ejecución sigilosa: El código malicioso se ejecuta dentro del proceso de una aplicación legítima (a menudo incluso firmada), lo que dificulta su detección por parte de los sistemas antivirus o de monitoreo tradicionales.
Persistencia: Una vez instalada, la DLL maliciosa puede garantizar que el código del atacante se vuelva a ejecutar cada vez que se inicie la aplicación legítima.
Escalada de privilegios: Si la aplicación legítima se ejecuta con privilegios elevados (por ejemplo, como SYSTEM), el código malicioso también heredará esos mismos privilegios.
Este ejemplo es muy sencillo y utilizaremos Notepad++ para analizar este método de ataque.
Sustituiremos la biblioteca original por una que contenga únicamente una carga útil que inicie la calculadora.
En este caso utilizamos el siguiente script para generar una nueva DLL donde en el MAIN hay una carga útil que se ejecutará.
#include #include void Payload() { STARTUPINFO si; PROCESS_INFORMATION pi; char cmd[] = "calc.exe"; ZeroMemory(&si, sizeof(si)); si.cb = sizeof(si); ZeroMemory(&pi, sizeof(pi)); CreateProcess(NULL, cmd, NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi); } BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved) { switch (fdwReason) { case DLL_PROCESS_ATTACH: Payload(); break; case DLL_THREAD_ATTACH: break; case DLL_THREAD_DETACH: break; case DLL_PROCESS_DETACH: break; } return TRUE; }Luego compilamos la biblioteca usando mingw32-gcc.
x86_64-w64-mingw32-gcc -shared -o NppExport.dll versión.c
Tras sustituir NppExport.dll e iniciar la aplicación, se abre la calculadora.
Lamentablemente, la aplicación detecta algún problema relacionado con la biblioteca y devuelve un error.
La razón es muy simple: no contiene las exportaciones originales, por lo que hay una comprobación que le avisa de esto, un obstáculo que veremos cómo superar en el siguiente paso.
A pesar de este error, Notepad++ sigue funcionando con normalidad.
Cabe señalar que, en otros casos, esta sustitución podría provocar un error crítico e impedir que la aplicación se ejecute, ya que contiene funciones esenciales para la propia aplicación.
El ejemplo anterior mostró cómo compilar una nueva biblioteca y reemplazar la original para que la aplicación pudiera ejecutar contenido malicioso. Sin embargo, este reemplazo podría provocar que la aplicación fallara o generara diversos errores.
Analicemos ahora una técnica de secuestro de DLL mediante proxy. El secuestro de DLL mediante proxy es una técnica avanzada de ciberataque que permite a un atacante ejecutar código malicioso dentro de una aplicación legítima sin que el programa se bloquee o finalice.
El concepto es muy simple.
Aquí tenéis un diagrama simplificado del procedimiento:
Analicemos en la práctica en qué consiste este ataque; para mayor comodidad, utilizaremos un repositorio existente que contiene todo lo necesario para este propósito.
https://github.com/tothi/dll-hijack-by-proxying
Clonemos el proyecto.
En su interior hay una biblioteca básica (que usamos en el ejemplo anterior) para ejecutar una carga útil una vez que se carga en la aplicación.
Consideramos que la DDL ha sido secuestrada, en este caso NPPExport.dll, que ha sido renombrada.
Generamos el archivo version.def que contiene las redirecciones de exportación a través del script de Python mediante el script deng_def.py.
El archivo .def contiene una sección llamada EXPORTS que enumera todas las funciones que la DLL necesita exponer, para que pueda redirigirlas a la DLL legítima original.
Ya desde aquí se puede ver que varios nombres de funciones se redirigen a NppExport_orig.dll.
Finalmente, compilamos la biblioteca usando mingw-w64:
Las opciones de compilación son similares al primer ejemplo, pero en este vamos a agregar las definiciones de las exportaciones adicionales que necesita esta biblioteca (version.def).
Ahora colocamos la nueva biblioteca junto a la original modificada.
NppExport.dll redirigirá todas las llamadas a funciones exportadas al archivo legítimo NppExport_orig.dll , evitando que las aplicaciones informen de fallos de funcionamiento.
Si ejecutamos el software, no se producirán errores y el código malicioso se ejecutará correctamente.
Un comando de servicio casi olvidado ha vuelto a cobrar protagonismo tras ser detectado en nuevos patrones de infección de dispositivos Windows. Considerado durante décadas una reliquia de los inici...
En el porche de una vieja cabaña en Colorado, Mark Gubrud , de 67 años, mira distraídamente el anochecer distante, con su teléfono a su lado y la pantalla todavía en una aplicación de noticias. ...
El trabajo remoto ha dado libertad a los empleados , pero con él también ha llegado la vigilancia digital . Ya comentamos esto hace tiempo en un artículo donde informamos que estas herramientas de ...
La empresa israelí NSO Group apeló un fallo de un tribunal federal de California que le prohíbe utilizar la infraestructura de WhatsApp para distribuir su software de vigilancia Pegasus. El caso, q...
Se ha identificado una vulnerabilidad de omisión de autenticación en Azure Bastion (descubierta por RHC gracias a la monitorización constante de CVE críticos en nuestro portal), el servicio gestio...
