Servidores IIS sob mira: como configurações negligenciadas viram alvo em bug bounty

O artigo fonte é um guia prático de exploração, mas o que ele não diz é que essas técnicas não são curiosidades históricas. São vetores ativos, com relatos reais de RCE via web.config em 2024 e ataques em massa com chaves ASP.NET expostas em 2025. A enumeração de nomes curtos (tilde) ainda funciona porque o Windows Server 2022 e 2025 mantêm a geração de 8.3 names por padrão para compatibilidade, e só é desativada manualmente via registro (NtfsDisable8dot3NameCreation). Isso não é uma falha do IIS: é uma decisão arquitetural do NTFS que se torna um vetor de ataque quando combinada com má configuração.

A exposição de DLLs via bin/ não depende mais de sessões sem cookies habilitadas, pesquisas recentes confirmam que o truque com ::$INDEX_ALLOCATION e caminhos mal normalizados burla até restrições de acesso baseadas em ACLs no IIS. E o HPP? Não é teoria: testes em 2025 mostraram que payloads duplicados com id=1&id=2 contornam WAFs em mais de 70% dos casos em aplicações ASP.NET, graças à concatenação nativa com vírgula no pipeline de requisição.

Em abril de 2026, a CEVIU já havia reportado servidores SharePoint expostos com falhas de spoofing ligadas ao Patch Tuesday, mas aquele era um cenário isolado. Agora, em junho de 2026, o foco mudou para a *persistência* da superfície de ataque IIS: não são apenas servidores esquecidos, mas instâncias ativamente mantidas, com mais de 4 milhões de sites ativos rodando IIS hoje. A evolução está na escala operacional: enquanto o relatório de março de 2026 (fonte) descrevia técnicas manuais, ferramentas como GSNW e shortnameguesser agora integram BigQuery e GitHub Code Search em pipelines automatizados, e isso está sendo usado em programas de bug bounty com SLA de 72h.

Porque IIS não é um alvo residual. É um componente crítico em ambientes bancários, governamentais e de saúde, e sua segurança depende menos de atualizações pontuais e mais de disciplina de configuração. Um web.config com machine key exposta não é um 'erro de desenvolvimento': é um rompimento na cadeia de confiança do ASP.NET, permitindo RCE mesmo em aplicações .NET 8.0 com todas as atualizações aplicadas. Para equipes de DevSecOps, isso significa que testes de segurança não podem parar no scan de vulnerabilidades conhecidas, precisam validar políticas de exposição de erros, restrição de verbos HTTP, permissões de diretório e desativação explícita de funcionalidades legadas como tilde enumeration e cookieless sessions.