Detecting and Mitigating Wordlist Scanning (T1595.003)

Wordlist Scanning (T1595.003) is part of Active Scanning in the reconnaissance tactic. It is listed for the PRE platform, because it comes before any compromise.

The method is brute force, but the target is different. MITRE says this technique uses methods similar to Brute Force, yet the goal is to identify content and infrastructure, not to find valid credentials.

Think of someone trying every door in a hallway to see which ones are unlocked, then writing down what is behind each.

How attackers use it

Adversaries iteratively probe infrastructure with brute-forcing and crawling. Wordlists may hold generic, commonly used names and file extensions, or terms specific to a certain piece of software. MITRE adds that adversaries can build custom, target-specific wordlists from data collected with other reconnaissance techniques, such as gathering victim organization information or searching victim-owned websites.

Two examples on the MITRE page matter for defenders.

Web content discovery. Adversaries may use web content discovery tools, named by MITRE as Dirb, DirBuster and GoBuster, with generic or custom wordlists to enumerate a site's pages and directories. The payoff is old, vulnerable pages or hidden administrative portals that can become targets for Exploit Public-Facing Application or Brute Force.

Cloud storage. Cloud storage solutions typically use globally unique names. Adversaries may use target-specific wordlists with tools such as s3recon and GCPBucketBrute to enumerate public and private buckets. Once storage objects are found, MITRE notes they may be used to collect data from cloud storage, which can then be exfiltrated or used to escalate privileges and move laterally.

The lesson is that obscurity is not a control. A hidden admin path or an oddly named bucket is findable if the name is guessable, and a name built from your company name, product names and common words usually is.

How to detect it

MITRE's detection advice is to monitor for suspicious network traffic that could indicate scanning, such as large quantities of requests originating from a single source, especially if the source is known to be associated with an adversary or botnet.

Where to look:

• Web server and reverse proxy logs: one client, many requests, many different paths, mostly 404 or 403 responses.
• WAF or CDN analytics: spikes in not-found responses, grouped by source.
• Cloud storage access logs, where enabled: many requests for object or bucket names that do not exist, or listing attempts from outside your normal users.

Rate and shape matter more than any single request. One request for an admin path means little. Several hundred in a minute from one address means someone is running a list.

How to reduce the risk

MITRE lists two mitigations.

1. Disable or Remove Feature or Program. Remove or disable access to any systems, resources and infrastructure that are not explicitly required to be available externally. This is the strongest control. A page that is not there cannot be found.
2. Pre-compromise. MITRE says the technique is outside the scope of enterprise defenses, so effort should go to minimizing the amount and sensitivity of data available to external parties.

Turn that into work items:

• Delete old pages, test environments, backup files and forgotten admin panels from public servers.
• Put administrative portals behind a VPN or an identity-aware proxy instead of relying on an unlisted URL.
• Make sure cloud storage that does not need to be public is private, and review which buckets are listed to the world.
• Choose resource names that do not follow an obvious pattern from your brand.
• Rate limit requests that produce a large number of not-found responses from a single source.

Check your own environment

Count not-found responses per client in an Nginx or Apache access log (Linux, standard text tools; adjust the field number for your log format):

awk '$9 == 404 {print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

A client with thousands of 404 responses is a scanner or a broken script.

Then review:

• Which paths on your public sites should not exist at all?
• Which buckets or containers are reachable without authentication?
• Are admin interfaces reachable from the public internet?
• Do you have alerting on a spike in not-found responses?

Try it yourself

A dynamic scan of your own web app finds the same forgotten pages and exposed paths a wordlist scan would, before someone else does.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• MITRE ATT&CK, Wordlist Scanning (T1595.003)