Análisis de SMBGhost en Latinoamérica

DeepSecurity • June 24, 2020

Un mapa azul de América del Sur tiene un fondo azul oscuro.

Escaneando Latinoamérica con GoGhost

SMBGhost (CVE-2020-0796) es una vulnerabilidad de ejecución remota de código, no autenticada, en Microsoft Server Message Block 3.1.1 (SMBv3). La vulnerabilidad sólo requiere que el puerto 445 esté abierto, y un atacante podría conectarse y ejecutar comandos sin necesidad de tener usuario o contraseña.

Esta vulnerabilidad, debido al servicio en el que se encuentra Microsoft SMB tiene un enorme potencial de efecto tipo gusano. Esto quiere decir que, si se infecta una PC en una LAN (Local Area Network), puede replicar el ataque de forma local e infectar a todos los demás ordenadores de la red. Dicha vulnerabilidad explota una ejecución remota de comandos via SMB puerto 445 expuesto, igual a la usada por el ransomware WannaCry en 2017 que infectó en un solo día más de 140,000 PCs en todo el mundo.

En DeepSecurity, entendemos la gravedad de este tipo de vulnerabilidades y queremos ayudar a fortalecer la ciberseguridad e infraestructura del mercado local y de países de la región. En ese sentido, dada la coyuntura y la exposición masiva de PCs y Servidores con Windows a Internet. Donde vimos el potencial de realizar herramientas de seguridad en lenguajes de programación de nueva generación como “Go”, lenguaje creado por Google y que originalmente fue diseñado para crear infraestructura y backend capaces de procesar un gran volumen de datos usando pocos recursos. El lenguaje está centrado netamente en el performance y empresas como CloudFlare y Facebook ya la están usando para optimizar su velocidad.

Decidimos crear GoGhost, herramienta con potencial para escanear segmentos completos de Internet, y que nos permitió realizar un escaneo de más de 125 millones de direcciones IP de Latinoamérica en busca de estadísticas sobre esta vulnerabilidad. GoGhost no realiza escaneos intrusivos, ni ejecución de pruebas de corrupción de memoria en los servidores Windows. GoGhost realiza pruebas con paquetes SMB diseñados para encontrar servidores que soportan específicamente el algoritmo de compresión “LZNT1” en el protocolo emulando una petición maliciosa sin explotar la vulnerabilidad en sí.

Nuestro análisis se enfocó principalmente en hallar todos los servicios SMB (445/tcp) que tuviesen compresión y estuviesen expuestos a internet. Usando GoGhost, validamos todas las direcciones IPv4 de latinoamérica registradas en LACNIC (lacnic.net), un total de aproximadamente 125 millones de direcciones.

Un gráfico que muestra el porcentaje de servidores potencialmente vulnerables

Colombia fue el país que mostró mayor porcentaje de servidores potencialmente vulnerables, un 17% del total de 1203 servidores SMB expuestos (tcp/open) a Internet. Este porcentaje representa más de 150 servidores, que corren el riesgo de ser expropiados por ciberdelincuentes para ser utilizados en minería de criptomonedas, ser infectados por ransomware o ser utilizado como parte de una enorme Botnet. Microsoft califica esta vulnerabilidad como crítica (CVE-2020-0796) y debería ser parchada cuanto antes. En Brasil, un país que cuenta con un porcentaje relativamente bajo, debido a su desarrollo tecnológico y desarrollo digital, expone más de 700 servidores Windows potencialmente vulnerables.

A graph showing cantidad de servidores potencialmente vulnerables

En Perú se encontró que el 7% de los servidores con SMB expuestos, resultan ser potencialmente vulnerables, resultado bastante cercano al promedio de 8% de la región. Fueron más de 100 servidores potencialmente vulnerables los encontrados, menor que los encontrados en el análisis de Windows SMB BlueKeep.

Un gráfico circular que muestra el número de servidores en cada país.

GoGhost es una herramienta programada 100% en Go, lo que permitió al equipo de investigadores de DeepSecurity realizar escaneos masivos confirmando 22,500 direcciones IP potencialmente vulnerables a SMBGhost (CVE-2020-0796) en solo 2 segundos.

El potencial de escaneo de esta herramienta nos revela el verdadero paradigma de Internet, todo está conectado y accesible desde cualquier IP. Se realizó un análisis comparativo entre Nmap y GoGhost para encontrar direcciones IP potencialmente vulnerables a SMBGhost (CVE-2020-0796) , los resultados se adjuntan a continuación:

Usando el siguiente script de NMAP “smb2-capabilities_patched.nse” para validar la vulnerabilidad de SMBGhost (CVE-2020-0796) , se escanearon casi 25,000 direcciones IP de un segmento de Internet. El escaneo de NMAP demoró cerca de 650 segundos en terminar vs GoGhost que tardó solo 2.5 segundos.

Una captura de pantalla de un programa llamado goghost.

MAP realizó el escaneo de 24,576 direcciones IP en 645.5 segundos, cabe indicar que se utilizó -T5 para tratar de dar la mayor velocidad soportada (insane – T5).

Una imagen borrosa de texto sobre un fondo negro

Se contrastaron los resultados de ambas herramientas, donde se validó la misma cantidad de puertos 445/tcp abiertos usando la misma muestra 24,576 direcciones IP de Latinoamérica.

Una imagen borrosa de la pantalla de una computadora con mucho texto.

GoGhost es una herramienta OpenSource disponible en código fuente 100% Go : GitHub: https://github.com/deepsecurity-pe/GoGhost

Como conclusión, existen miles de servidores potencialmente vulnerables a SMBGhost en latinoamérica y que corren el riesgo de convertirse en víctimas de ciberdelincuentes que se encuentran en búsqueda de nuevos servidores para vulnerar.

Para evitar que tu servidor sea vulnerable, puedes deshabilitar la compresión en Windows SMB con la siguiente línea en powershell:

Set-ItemProperty -Path «HKLM:\SYSTEM\CurrentControlSet\Services\ LanmanServer\Parameters» DisableCompression -Type DWORD -Value 1 -Force

Microsoft, además, ya ha publicado parches de seguridad que aseguran la compresión SMB para evitar la vulnerabilidad y pueden descargarse desde la web oficial de Microsoft.

Versiones de windows afectadas:

Windows 10 Version 1903 for 32-bit Systems
Windows 10 Version 1903 for ARM64-based Systems
Windows 10 Version 1903 for x64-based Systems
Windows 10 Version 1909 for 32-bit Systems
Windows 10 Version 1909 for ARM64-based Systems
Windows 10 Version 1909 for x64-based Systems
Windows Server, version 1903 (Server Core installation)

Windows Server, version 1909 (Server Core installation)

< Entrada anterior

Entrada más reciente >

CVE-2025-14340 De XSS Reflejado a Takeover Completo de Administrador en Payara Server

24 de marzo de 2026

Análisis rápido Durante una revisión de la interfaz REST de administración de Payara Server se identificó una cadena de explotación en la que un XSS reflejado podía combinarse con un flujo inseguro de cambio de contraseña para derivar en takeover completo de la cuenta administrator. La severidad real del caso no estaba en una sola falla, sino en la forma en que varias decisiones de diseño reducían la resistencia del panel frente a ejecución de JavaScript en el mismo origen. El impacto no dependía únicamente del XSS. La cadena se volvía crítica por la combinación de cuatro elementos: - XSS reflejado en un endpoint administrativo - Cambio de contraseña sin validar la contraseña actual - Basic Auth enviada automáticamente por el navegador - Protección anti-CSRF débil basada en X-Requested-By En conjunto, esto permitía que un administrador autenticado, al visitar un enlace malicioso, terminara ejecutando una solicitud válida contra el endpoint de cambio de contraseña. Por esta vulnerabilidad me asignaron el CVE-2025-14340 XSS y el punto de entrada El primer componente era un XSS reflejado en el endpoint de versión de la consola: GET /management/domain/version?xss= HTTP/1.1 Host: panel.example.com:4848 En una consola de este tipo, un XSS no solo afecta la vista del usuario. También permite interactuar con funciones sensibles usando el mismo contexto autenticado del administrador. El CSRF que convierte el bug en takeover El segundo componente estaba en /management/domain/change-admin-password . De forma resumida, el flujo aceptaba una solicitud similar a esta: POST /management/domain/change-admin-password HTTP/1.1 Host: panel.example.com:4848 X-Requested-By: GlassFish REST HTML interface Content-Type: application/x-www-form-urlencoded id=admin&newpassword=[REDACTED]&password=[REDACTED] Lo problemático no era solo que cambiara credenciales, sino dos agravantes de diseño: No exigía la contraseña actual La “protección” anti-CSRF se basaba en X-Requested-By . Ese header funcionaba como una cabecera personalizada para marcar que la solicitud provenía del frontend esperado. El problema es que no era un control fuerte frente a JavaScript malicioso ejecutándose same-origin . ¿Header X-Requested-By ? X-Requested-By era, en la práctica, la señal que el backend utilizaba para distinguir una solicitud “esperada” de una solicitud arbitraria. La lógica era simple: si la request incluía la cabecera esperada, el servidor la trataba como legítima. Ese enfoque puede frenar algunos intentos externos básicos, pero deja de ser útil cuando un atacante consigue ejecutar JavaScript dentro del mismo origen de la consola. A nivel práctico, el comportamiento observado podía resumirse en un payload como la siguiente POC . fetch ( '/management/domain/change-admin-password' , { method: 'POST' , headers: { 'X-Requested-By' : 'GlassFish REST HTML interface' , 'Content-Type' : 'application/x-www-form-urlencoded' }, body: 'id=admin&newpassword=admin123&password=admin123' }); Y ahí aparecía el punto crítico de la cadena: el backend aceptaba una solicitud con la cabecera esperada, mientras el navegador adjuntaba automáticamente las credenciales administrativas mediante Basic Auth. https://panel.example.com:4848/management/domain/version?xss Full exploit: https://github.com/DeepSecurityResearch/CVE-2025-14340 Explotación y Same-Origin La explotación no dependía de una petición cross-origin convencional, sino de la ejecución de JavaScript dentro del mismo origen de la consola administrativa. ¿Por qué el CSRF solo es explotable mediante el XSS? Debido a que el endpoint usa Basic Authentication, explotarlo remotamente desde un origen externo es imposible: - CORS bloquea requests cross-origin al endpoint de administración - Basic Auth no puede forzarse desde otro dominio sin cooperación del navegador - El header X-Requested-By no puede añadirse en requests cross-origin Ese detalle era determinante. Una vez obtenido el XSS, el atacante podía interactuar con el endpoint de cambio de contraseña desde el mismo contexto que la interfaz legítima, incluyendo X-Requested-By y aprovechando el estado autenticado del administrador. En ese punto, el XSS dejaba de ser un hallazgo aislado y se convertía en la primitive necesaria para comprometer directamente la cuenta administrativa. Vectores de ataque Campaña de Phishing Dirigido Un atacante envía un email convincente con apariencia de "actualización de seguridad" que contiene el enlace malicioso. Cuando el administrador hace clic mientras está logueado, la contraseña se cambia silenciosamente. Watering Hole El atacante compromete un sitio interno frecuentemente visitado e inyecta un iframe invisible con el exploit. Al visitar el sitio, el exploit se ejecuta automáticamente en segundo plano sin indicación visible. Supply Chain Un atacante compromete la documentación de una herramienta usada por el equipo de operaciones. Al seguir un enlace de la documentación para troubleshooting, la cuenta queda comprometida. Capacidades del Atacante con acceso a la consola de administración: - Desplegar aplicaciones maliciosas (WAR/EAR files) - Modificar configuración del servidor - Acceder a datos de aplicaciones desplegadas - Crear mecanismos de persistencia - Extraer credenciales de datasources Conclusión CVE-2025-14340 demuestra cómo vulnerabilidades moderadas se convierten en críticas cuando se encadenan. Un XSS reflejado (severidad media) combinado con ausencia de protección CSRF (severidad baja-media) resultó en account takeover completo de administrador. La falla no residía únicamente en el XSS reflejado, sino en la forma en que esa primitive podía encadenarse con una operación sensible insuficientemente protegida. En este caso, el resultado final era claro: un XSS en contexto administrativo terminaba habilitando el takeover completo del administrador. Nota sobre el Coordinated Disclosure Esta vulnerabilidad fue reportada siguiendo prácticas de divulgación responsable. El período de coordinación de 113 días permitió al vendor desarrollar y desplegar un fix antes de la divulgación pública. Sin embargo, el proceso presentó desafíos. A pesar del compromiso inicial del vendor de coordinar la publicación del CVE y asegurar la atribución apropiada, la comunicación fue inconsistente. El CVE fue publicado sin la notificación prometida y sin la atribución acordada, situación que se corrigió posteriormente tras solicitarlo. Esta experiencia subraya la importancia de: Políticas claras de disclosure Comunicación proactiva durante el proceso Respeto a los acuerdos de atribución Documentación exhaustiva de todas las interacciones

CVE-2025-58765: XSS Reflejado en Wayback Machine - Wabac.js

por Camilo Galdos • 4 de marzo de 2026

Análisis Rápido: XSS en Wayback Machine CVE-2025-58765

Introspector Framework: Out-Of-Band Pentest Tool

por Camilo Galdos • 20 de febrero de 2026

Introspecto r es un framework ofensivo diseñado para analizar y explotar comportamientos HTTP avanzados que ocurren “fuera” de la respuesta inmediata desde el servidor web (OOB - out of band). Más allá de un simple request/response, el objetivo es reconstruir la ruta de ejecución completa de un payload incluyendo patrones de redirección, resoluciones DNS, ejecución de solicitudes encadenadas y seguimiento de recursos servidos por el backend. En escenarios reales, muchas vulnerabilidades críticas no se manifiestan en el HTML de salida (response), sino en la infraestructura intermedia y el comportamiento del backend: balanceadores, reverse proxies, WAFs, CDN, resolvers DNS, caches, microservicios internos y clientes HTTP automatizados . Introspector está diseñado para capturar ese “lado invisible” del flujo, registrando redirecciones, reintentos, resoluciones DNS, follow-ups automáticos, y solicitudes encadenadas que pueden ocurrir segundos después y en hosts completamente distintos. Fue creada por el equipo de research de DeepSecurity específicamente para ir más allá de Burp Collaborator , permitiendo observar no solo si existe interacción OOB, sino cómo ocurre , qué componente la dispara, qué endpoint exacto la origina y qué cadena de ejecución se activa después (DNS, redirects, retries, fetches secundarios, etc.). En la práctica, Introspector ha sido utilizado tanto en proyectos con clientes como en iniciativas de research y bug bounty , sirviendo como base para hallazgos reales y reportes públicos, incluyendo Blind SSRF en Microsoft Ads , Host Header Injection + DoS en Microsoft , y vulnerabilidades CVE 2025 - 2026 reportadas responsablemente a plataformas como GlassFish y Payara . ¿Por qué usar Introspector en un pentest avanzado? Este tipo de visibilidad es clave para explotar y validar vulnerabilidades modernas como: SSRF (incluyendo SSRF ciego y SSRF con pivot a redes internas) Host Header Injection (en especial cuando la app construye URLs absolutas para resets de password, links de verificación, callbacks, etc.) Comportamientos anómalos en balanceadores / proxies (reescritura de Host, X-Forwarded-Host, X-Forwarded-Proto, Forwarded) HTTP Request Smuggling (cuando el front-end y back-end interpretan distinto Content-Length / Transfer-Encoding) Vulnerabilidades HTTP basadas en headers (cache poisoning, routing inconsistencies, internal URL generation, open redirect indirecto)

Host Header Injection + DoS en Microsoft

por Camilo Galdos • 30 de agosto de 2025

¿Qué es Host Header Injection?

Blind SSRF en Microsoft Ads

por Camilo Galdos • 24 de julio de 2025

Server-Side Request Forgery para Pentesters

Un fondo azul con dos manos y las palabras

Ethical Hacking Smart Contracts

4 de septiembre de 2023

¿Por qué se siguen reportando incidentes en los Smart Contracts? Hay varias razones por las que los smart contracts siguen siendo un objetivo para un actor de amenaza, aca les mencionamos las principales.

Una langosta verde en una rama, y el mensaje de pruebas de penetración vs bug bounty

Bug Bounty vs Penetration Testing: ¿Cuál es el enfoque correcto para tu organización?

8 de agosto de 2023

Los programas de bug bounty (recompensas por errores) y penetration testing (pruebas de penetración son dos enfoques distintos para las pruebas de seguridad, cada uno con sus propios beneficios y consideraciones. Si bien algunos pueden verlos como métodos opuestos, en realidad pueden funcionar en conjunto para mejorar la postura de seguridad de una organización. Es importante comprender las diferencias entre los dos y evaluar qué enfoque se alinea mejor con las metas, el objetivo y los recursos específicos de la organización.

Un virus azul sobre fondo negro con las palabras reporte de ciberinteligencia

Reporte de Ciberinteligencia - Operación: APAKUY

por DeepSecurity • 1 de junio de 2020

Durante nuestras investigaciones de ciberinteligencia encontramos un grupo en Telegram donde se mencionan distintos temas desde hacking de aplicaciones web hasta robo de tarjetas (carding). Encontramos que algunos de los 550 ciberdelincuentes miembros de este grupo publicaban información sobre un fallo en la web del bono universal que permitía apropiarse del bono de los beneficiarios.

Una estatua de un oso está comiendo una hoja sobre un fondo negro.

Reporte de Ciberseguridad en las Aplicaciones Móviles de Home banking en Perú

por DeepSecurity • 21 de mayo de 2020

El último año ha sido clave para la expansión digital de los bancos peruanos. Se han lanzado al mercado todo tipo de utilidades y aplicaciones que ayudan a las personas a gestionar su dinero de una manera más fácil. En DeepSecurity, nos preocupamos por la ciberseguridad del sistema financiero local y por eso hemos llevado a cabo un análisis pasivo (no-intrusivo) de las aplicaciones móviles de 12 bancos del Perú.

Una mano sostiene una pieza de ajedrez sobre un fondo azul.

Análisis de BlueKeep en Perú

por DeepSecurity • 14 de abril de 2020

BlueKeep (CVE-2019-0708) es una vulnerabilidad de ejecución remota de código, no autenticada, en Remote Desktop Services (Servicio de RDP). La vulnerabilidad solo requiere que el puerto de RDP esté abierto y un atacante podría conectarse sin necesidad de tener usuario o contraseña.