IIS-ShortName-Scanner: Exploiting a 13-Year-Old Vulnerability Microsoft Won't Fix

Hook

Microsoft has known about the IIS short filename disclosure vulnerability for over 13 years and refuses to patch it. It still works on IIS 10 running Windows Server 2022.

Context

When Microsoft designed IIS, they maintained backward compatibility with DOS's 8.3 filename convention—a relic from the 1980s where filenames were limited to eight characters plus a three-character extension. When longer filenames exist, Windows automatically creates short filename aliases like PROGRA~1 for Program Files. In 2010, security researchers discovered that IIS would leak these short names through subtle differences in HTTP responses when specially crafted requests contained tilde characters.

The vulnerability works because IIS handles requests for short filenames differently than requests for non-existent files, creating measurable timing differences or distinct HTTP status codes. An attacker can systematically probe character combinations, observing these differences to reconstruct short filenames character by character. While this doesn't reveal full filenames, it dramatically reduces the search space for attackers trying to discover hidden files, backup archives, configuration files, or other sensitive resources that administrators assumed were protected through obscurity. Microsoft's position has been that this is a feature, not a bug, and the only mitigation is to disable 8.3 filename generation entirely—a change that can break legacy applications.

Technical Insight

The IIS-ShortName-Scanner implements a differential analysis attack through carefully orchestrated HTTP requests. At its core, the tool exploits the fact that when you request a file like *~1*/.aspx, IIS responds differently if a file matching that pattern exists versus when it doesn't. The scanner iterates through character positions and possible characters, building up the short filename piece by piece.

The attack works in multiple phases. First, the scanner determines which HTTP methods trigger the vulnerability on the target server. Not all IIS configurations respond the same way—some reveal information through GET requests, others through OPTIONS, DEBUG, or even custom methods. The tool tests multiple vectors:

// Simplified representation of the attack logic
String[] methods = {"GET", "OPTIONS", "POST", "DEBUG"};
String baseUrl = "http://target.com/";

for (String method : methods) {
    // Test if files exist by checking response to tilde patterns
    String testPattern = "*~1*/a.aspx";
    HttpResponse response = sendRequest(method, baseUrl + testPattern);
    
    if (response.getStatusCode() == 404) {
        // Likely vulnerable with this method
        // Start enumeration process
        enumerateShortNames(method, baseUrl);
    }
}

The enumeration phase is where the real work happens. The scanner tests each possible character at each position of the short filename. For a file named AddAccount.aspx, the short name might be ADDACC~1.ASP. The tool discovers this by testing patterns like A*~1*/.aspx, then AD*~1*/.aspx, continuing until it builds the complete short name:

// Character-by-character enumeration
String charset = "ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
String discovered = "";

for (int position = 0; position < 6; position++) {
    for (char c : charset.toCharArray()) {
        String pattern = discovered + c + "*~1*/.aspx";
        HttpResponse response = sendRequest(method, baseUrl + pattern);
        
        // If status code differs from baseline, character is correct
        if (response.getStatusCode() != baselineStatusCode) {
            discovered += c;
            break;
        }
    }
}

One of the scanner's most powerful features is its authentication bypass capability using NTFS stream notation. IIS directories have an index allocation stream ($I30:$Index_Allocation) that's accessible even when the directory itself requires authentication. By appending this stream notation to requests, the scanner can probe for files behind authentication:

// Bypass basic authentication using NTFS streams
String authProtectedPath = "http://target.com/admin/";
String bypassPath = authProtectedPath + ":$I30:$Index_Allocation/";

// This request may succeed even if /admin/ requires auth
HttpResponse response = sendRequest("GET", bypassPath + "*~1*/.aspx");

The tool also implements multi-threading to speed up the character-testing process, since each scan might require hundreds or thousands of requests. However, this introduces complexity—too many concurrent requests can trigger rate limiting, cause false positives due to server overload, or even crash poorly configured IIS servers. The XML configuration system allows tuning these parameters:

<config>
    <threads>20</threads>
    <delay>100</delay>  <!-- milliseconds between requests -->
    <maxRetries>3</maxRetries>
    <customHeaders>
        <header name="User-Agent" value="Mozilla/5.0..."/>
    </customHeaders>
</config>

The architecture also includes intelligent response analysis. Rather than relying solely on status codes, it can analyze response timing, content length, and response headers. Some IIS configurations return 404 for both existing and non-existing files but with measurably different response times. The scanner captures these timing differences and uses statistical analysis to determine which characters are valid.

Gotcha

The author himself describes this as 'spaghetti code' and recommends trying bitquark/shortscan first. This isn't false modesty—the codebase is genuinely challenging to work with, and the tool frequently requires multiple scan attempts to produce results. The fundamental issue is that IIS server responses vary wildly based on configuration, installed modules, ASP.NET settings, and network conditions. What works perfectly against one IIS 7.5 server might fail completely against another identically versioned server.

The scanner only reveals short filenames, which is merely the first step in exploitation. If you discover BACKUP~1.ZIP, you still need to guess the full filename—is it backup_2023.zip, backup-database.zip, or something else entirely? You'll need dictionary attacks, OSINT, or manual guessing to reconstruct actual paths. Additionally, the multi-threading system requires careful tuning. Set it too aggressive and you'll DoS yourself out of accurate results or potentially crash the target server (problematic during authorized penetration tests). Set it too conservative and scans take unreasonably long. There's no one-size-fits-all configuration, so expect to invest time tweaking parameters for each target. False positives are also common—the tool might report files that don't actually exist, especially when server response times are inconsistent.

Verdict

Use if: You're performing authorized security assessments against IIS servers and need to identify information disclosure vulnerabilities, especially when dealing with IIS 7.5-10 where other tools have failed. The authentication bypass feature alone makes this valuable for penetration testing scenarios where you've identified IIS behind authentication but need to enumerate what's there before investing time in credential attacks. It's also worth using if you're a security researcher studying IIS internals or need to demonstrate vulnerability impact to stakeholders who might not understand the severity of 'just' short filename disclosure. Skip if: You need production-ready automation, guaranteed first-run success, or are uncomfortable with Java dependencies and XML configuration. If you're scanning IIS servers as part of routine security scanning rather than targeted penetration testing, use modern alternatives like bitquark/shortscan (Go) or the Metasploit module instead—they offer better maintainability and more predictable behavior. Also skip this if your target IIS server has 8.3 filename generation disabled (run fsutil behavior query disable8dot3 to check), as the vulnerability won't exist regardless of how good your scanner is.