← На главную

Shodan, nuclei и shortscan открывают RCE в IIS через machine keys

16.06.2026 22:53 · hackernews

Друг автора однажды сказал: если увидел синий экран IIS, не останавливайся — там что-то есть. Он был прав. За стандартной страницей IIS часто прячется один из самых криво настроенных веб-серверов в интернете.

Для начала автор советует найти цели. Shodan поможет сразу: ssl:"target.com" http.title:"IIS". Google доделывает грязную работу: site:target.com intitle:"IIS Windows Server". Запросы вроде aspnet_client или _vti_bin — верные признаки. Активное распознавание через httpx -l targets.txt -td | grep IIS тоже работает.

Что делать, когда IIS найден? Первым делом — сбор бесплатной информации. Отправь HTTP/1.0-запрос, и сервер может выдать внутренний IP в заголовке Location. Например: Location: https://192.168.5.237/owa/. Уже есть утечка.

Дальше — ядро атаки. Автор запускает nuclei с тегами microsoft,windows,asp,aspx,iis,azure,config,exposure. Многие видят ошибку HTTPAPI 2.0 404 и думают, что там пусто. На самом деле сервер просто не получил правильный Host. Нужно либо проверить SSL-сертификат, либо перебрать виртуальные хосты через ffuf.

Одна из самых недооценённых техник — IIS tilde enumeration. Инструмент shortscan вытаскивает короткие имена файлов в стиле DOS 8.3: WEB~1.CON (это web.config) или SITEBA~1.ZIP. Дальше нужно угадать полное имя. Автор использует LLM для генерации догадок, GitHub-дампы через утилиту GSNW, BigQuery с публичным датасетом GitHub, а если ничего не помогло — чистый брутфорс через crunch и ffuf.

Отдельный разговор — fuzzing. Для IIS нужны свои wordlist'ы: web.config, trace.axd, elmah.axd, connectionstrings.config. trace.axd показывает логи запросов с куками и учётками. elmah.axd — то же самое, но для ошибок. Никто их не выключает.

Если удалось прочитать web.config — считай, победа. Там часто лежат machine keys, которыми подписывается ViewState. С ними ysoserial.net сделает RCE. Ещё один трюк — кража DLL из папки bin через cookieless сессии: GET /(S(X))/b/(S(X))in/MyCustomAPI.dll. Скачал, сунул в dnSpy — и читаешь исходники с хардкоженными паролями.

Автор упоминает обход прокси через %2f, NTFS-фокусы с $INDEX_ALLOCATION, загрузку файлов с точками на конце (shell.aspx.) и HTTP Parameter Pollution для обхода WAF.

Вывод простой: все бегают за модными JavaScript-уязвимостями, а сервера IIS стоят, текут внутренними IP, отдают конфиги и не закрывают shortname enumeration. Не пропускай синий экран.

Читать оригинал →