La guía de bug bounty sobre IIS que está arrasando en Hacker News

El 18 de marzo de 2026, el blog mll.sh publicó "Humiliating IIS servers for fun and jail time", un artículo de 13 minutos de lectura que desmenuza todas las técnicas de reconocimiento y explotación de servidores Microsoft IIS. La comunidad de seguridad lo convirtió en tendencia inmediata.

Lo que diferencia este artículo de los típicos tutoriales de bug bounty es que no teoriza. Cada sección incluye comandos copiables, herramientas concretas y trucos que el autor ha usado en programas reales. He probado varios de estos métodos en mi propio laboratorio y funcionan incluso contra IIS 10 en Windows Server 2022.

Encontrar servidores IIS: Shodan, Google Dorks y fingerprinting

El artículo arranca con tres métodos para localizar servidores IIS que la mayoría de la gente se salta. El primero es Shodan: con queries como ssl:"target.com" http.title:"IIS" encuentras servidores de staging, paneles de administración olvidados y herramientas internas que nadie sabía que estaban expuestas a Internet.

El segundo método son los Google Dorks específicos para IIS: buscar carpetas como aspnet_client o _vti_bin (extensiones FrontPage) dentro del scope del objetivo. Si Google las ha indexado, tienes un blanco. El truco con site:*.*.target.com para pillar subdominios anidados me ha funcionado personalmente más de una vez.

El tercero es fingerprinting activo con httpx a escala: buscas las cabeceras Server: Microsoft-IIS/10.0 y X-Powered-By: ASP.NET en toda la superficie del objetivo. Simple pero efectivo.

La joya: IIS Tilde Enumeration

Esta es, según el autor y según mi experiencia, la técnica más infravalorada. IIS hereda el comportamiento de nombres cortos 8.3 de DOS. Con herramientas como shortscan puedes enumerar nombres de archivo y directorio incluso sin listado de directorios habilitado.

El flujo es así: shortscan te devuelve fragmentos como WEB~1.CON (obviamente web.config) o SITEBA~1.ZIP. Luego toca adivinar el nombre completo. Aquí el artículo propone cuatro métodos en cascada:

• LLMs: pedirle a ChatGPT o Claude que genere variaciones del shortname
• GitHub Dorks: buscar en GitHub archivos que empiecen igual usando path:/siteba*.zip
• BigQuery: consultar el dataset público de GitHub (bigquery-public-data.github_repos.files) para encontrar nombres reales usados en proyectos — técnica desarrollada por Assetnote
• Fuerza bruta con crunch: generar todas las combinaciones posibles de los caracteres restantes

Este enfoque en capas — de lo más inteligente a lo más bruto — es exactamente como trabajo yo. Primero tiras de IA, luego de datos públicos, y solo al final sacas la artillería pesada.

web.config: las llaves del reino

Si consigues leer el archivo web.config de un servidor IIS — ya sea por path traversal (../../web.config), por una copia de seguridad mal ubicada (web.config.bak), o mediante la enumeración de shortnames — has ganado.

La razón es simple: estos archivos a menudo contienen machine keys, las claves criptográficas que IIS usa para firmar y cifrar el ViewState. Con esas claves puedes forjar un payload malicioso de ViewState y conseguir ejecución remota de código mediante deserialización. ysoserial.net genera el payload una vez que tienes las claves.

El artículo también detalla un método particularmente astuto: extraer DLLs del directorio bin abusando de las sesiones cookieless de ASP.NET. La URL /(S(X))/b/(S(X))in/Newtonsoft.Json.dll parece basura, pero IIS interpreta los segmentos (S(X)) como tokens de sesión, los elimina durante la normalización, y te sirve /bin/Newtonsoft.Json.dll. Metes esa DLL en JetBrains dotPeek o dnSpy y estás leyendo el código fuente descompilado: credenciales hardcodeadas, API keys, todo.

Bypass de WAF, reverse proxy y otros trucos

La sección sobre bypass de WAF mediante HTTP Parameter Pollution (HPP) es corta pero letal. IIS y ASP.NET concatenan parámetros duplicados con una coma. Si el WAF bloquea tu payload en un solo parámetro, lo divides en dos: ?param=<svg/&param=onload=alert(1)>. El WAF ve dos fragmentos inofensivos, pero IIS los junta al otro lado.

Otro truco que me sorprendió: la confusión de path en reverse proxy. Si /admin/ devuelve 403, pruebas con /anything/..%2fadmin/. El proxy ve /anything/ y deja pasar la petición, pero IIS decodifica el %2f como barra, resuelve el path traversal y te sirve /admin/. El control de acceso se ha esfumado.

Y para cuando encuentras un formulario de subida de archivos, el artículo lista extensiones que IIS sirve como HTML por defecto (.cer, .hxt, .htm) — perfectas para stored XSS — y el truco eterno de los puntos al final del nombre de archivo: shell.aspx. o shell.aspx.... IIS los elimina y sirve el archivo como .aspx. La gente sigue sin filtrar esto en 2026.

Por qué esto importa ahora mismo

El artículo de mll.sh no revela vulnerabilidades nuevas. Lo que hace — y por eso ha pegado tan fuerte en Hacker News — es compilar en un solo lugar técnicas que antes estaban dispersas en charlas de conferencias (NahamCon2021 "Hacking IIS", "THE POWER OF RECON" de Orwa Atyat), posts de blog y herramientas sueltas.

He pasado años haciendo auditorías de seguridad y si hay algo que he aprendido es que los servidores IIS son los grandes olvidados. Todo el mundo persigue la última vulnerabilidad de React o Next.js mientras estas máquinas Windows filtran IPs internas, sirven sus propios archivos de configuración y tienen la enumeración de shortnames abierta de par en par.

La próxima vez que veas la pantalla azul de IIS, no pases de largo. Como dice el autor: "Recon harder".