Recognize wordlist-scanning behavior
What you are learning
Wordlist scanning is a systematic way to try many possible names or values from a prepared list. In web testing, repeated requests for candidate paths can help identify resources by comparing HTTP responses. Defenders can recognize the resulting pattern in HTTP or WAF logs, DNS activity, request rates, and response-status patterns. This lesson explains the basic process before showing how individual responses and repeated activity should be interpreted.
- Explain how repeated candidate requests characterize wordlist scanning.
- Identify HTTP, WAF, DNS, and rate-related evidence that can reveal the behavior.
- Distinguish one failed request from a sustained systematic scanning pattern.
- Describe investigation and risk-reduction actions a defender could take without performing the scan.
Organizations see automated requests from search engines, monitoring tools, vulnerability scanners, bots, and hostile scanners. Defenders need context and a normal baseline instead of treating all automation as malicious. In real environments, the same kind of traffic may come from legitimate troubleshooting, asset discovery, monitoring, or security testing. Defenders therefore compare the pattern with approved work before deciding that the activity is suspicious.
Use a repeatable web-testing method
Connect this ATT&CK training activity to the WSTG approach: establish expected behavior, identify the relevant attack surface, change one controlled input or observation at a time, compare the response with the baseline, and record evidence before drawing a conclusion.
For reconnaissance-oriented lessons such as T1595, treat reachability, exposed services, and observable application behavior as information gathering. A reachable service is evidence about exposure; it is not by itself proof of a vulnerability.
Open WSTG web security fundamentalsUnderstanding Wordlist Scanning
Wordlist scanning means giving a tool a prepared list of possible names or values and having the tool try them automatically. Instead of manually guessing one possibility at a time, the tool can quickly work through many likely possibilities.
During an authorized web application test, a tester might use a content-discovery wordlist containing common page or directory names. The tester compares the responses because a response can provide useful evidence even when access is denied.
Wordlists are not limited to web paths. Depending on the activity, candidate lists can contain filenames, usernames, passwords, hostnames, subdomains, or other values. These are different security activities, but the common idea is systematically trying likely candidates rather than guessing them individually.
- /admin → 404 Not Found — the requested resource was not found.
- /backup → 404 Not Found — the requested resource was not found.
- /login → 200 OK — the resource appears to exist and is accessible.
- /uploads → 403 Forbidden — the resource may exist, but the server is refusing access.
What you should take away: The important evidence is the pattern and the differences between responses. For defenders, one failed request is weak evidence; many candidate names requested rapidly by the same source are more meaningful. HTTP/WAF logs, request rate, response status patterns, DNS logs, and source or session details can help distinguish approved automation from suspicious discovery activity.
Practice Preparation
Use these lesson concepts for the ungraded practice activity below. You do not need outside research.
- Evidence sources can include HTTP or WAF access logs, proxy or application logs, DNS logs, request-rate information, response-status patterns, and source/session details.
- Activity is more suspicious when one source rapidly tries many unusual or nonexistent candidate names, especially when the pattern is sustained and does not match an approved crawler, health check, or authorized scanner.
- Useful controls include rate limiting, monitoring and alerting on unusual failed-request patterns, reducing unnecessary exposed content, and comparing automation with approved scanning or monitoring activity.
This is ungraded practice. Use the lesson material above; exact wording is not required. Identify three data sources that could show a wordlist-scanning pattern. Then name two features that would make the activity more suspicious than one failed request and two controls that could improve detection or reduce risk. No scanning command or external target interaction is required.
Check your understanding
Answer the questions shown below. You must answer at least 2 correctly before marking this concept lesson complete.
One failed request is weak evidence. A repeated, structured pattern is more useful when combined with context. Defenders should interpret this result with other evidence and context before deciding what it means.
Useful evidence includes HTTP or WAF logs, proxy logs, DNS logs, application logs, request rate, response status patterns, and source or session details. Compare the pattern with expected crawlers, health checks, and approved scanning. Reduce risk with rate limiting, monitoring, less unnecessary exposed content, and alerts for unusual failed-request patterns.