Core Concepts

Shortscan employs a sophisticated multi-stage process to identify and enumerate short filenames. Understanding this process can help you interpret its results and configure it more effectively.

The Three-Stage Scan Process

A scan is broken down into three main stages:

Stage 1: Vulnerability Detection

Before enumerating files, shortscan must determine if the target IIS server is vulnerable. It does this by sending requests for non-existent files and comparing their responses to requests for potentially existing 8.3-formatted files (e.g., *~1*).

To find a reliable detection method, shortscan iterates through a list of common HTTP methods (like OPTIONS, GET, DEBUG) and path suffixes (like /, .aspx). It searches for a combination that produces a consistent, distinguishable response (e.g., a 404 Not Found for non-existent files vs. a 400 Bad Request for existing short filename patterns).

The --patience flag controls how many methods and suffixes are tested.

Stage 2: Character Set Discovery

Once vulnerability is confirmed, shortscan identifies which characters are actually used in the filenames on the server. For each character in its test set (defined by --characters), it sends a request like *c*~1* (where c is the character) to see if it gets a positive response. This builds a map of valid characters for both filenames and extensions, significantly reducing the number of requests needed in the next stage.

Stage 3: Recursive Enumeration

This is the core brute-force stage. shortscan builds filenames character by character (e.g., A*~1*, B*~1*, ...). When it gets a positive response (e.g., for W*~1*), it recurses deeper (e.g., WE*~1*, WB*~1*, ...).

This process continues until it has found a complete filename part (up to 6 characters) and extension part (up to 3 characters). If a directory is discovered, it is added to the queue for a full scan.

Autocomplete and Full Filename Discovery

Finding the short filename (e.g., WEB~1.CON) is only half the battle. The real goal is to find the long filename (e.g., web.config). shortscan's autocomplete feature automates this using a wordlist and several detection modes (-a flag).

  • method Mode: This is often the most reliable method. It sends a request to a candidate long filename (e.g., GET /web.config) using an invalid HTTP method like _. A vulnerable IIS server will often respond with 405 Method Not Allowed if the file exists, and 404 Not Found if it does not.

  • status Mode: This mode establishes a baseline of HTTP status codes for non-existent files with a certain extension. It then requests a candidate long filename and if the response status code is not in the baseline, it's considered a match.

  • distance Mode: This is the most complex mode. It samples the response bodies of several non-existent files to calculate a baseline Levenshtein distance (a measure of text difference). It then compares the response body of a candidate long filename against this baseline. A significant deviation in distance indicates a likely match. This is useful when status codes are not distinct.

De-checksumming with Rainbow Tables

When Windows encounters a filename collision while generating an 8.3 name, it creates a name like FILENA~1, FILENB~1, etc. After a few collisions, it switches to a checksum-based algorithm, producing names like FI1A2B~1.TXT.

The shortutil tool can pre-compute these checksums for a given wordlist, creating a "rainbow table". When shortscan is provided this table via the --wordlist flag, it can reverse-lookup these checksums to find the original long filename, a feature unique to shortscan.