Starting yesterday, our sensors picked up a small number of scans for “wordfence-waf.php”. This particular script is used by Wordfence, a solution to protect WordPress sites. During the Wordfence install, the wordpress-waf.php file will be created in the site’s root directory [1].
The requests themselves are unremarkable, not including any headers like User-Agent. Just the bare minimum “Host” header, which is the IP address of the targeted site.
The file does not include any secrets or configuration parameters, but it includes other scripts intended to run before any WordPress code to assist with Wordfence’s integration. My best guess is that attackers may attempt to enumerate Wordfence-protected sites to limit detection. Wordfence collects intelligence from the sites it protects and often publishes information about newly detected attacks. This, in turn, “burns” exploit techniques, as other sites will not be able to protect themselves as well.
Another possible option is that these scans attempt to bypass Wordfence. By using the IP address instead of the hostname, the attacker may attempt to identify Wordfence-protected sites that are directly reachable. This could be used to bypass Wordfence protection and expose sites that rely on it to delays in patching. Web application firewalls and “virtual patching” are only temporary fixes; please follow Wordfence’s guidance on preventing the bypassing of its protection. But wordfence-waf.php is part of the “Extended Protection” feature, which is designed to help prevent this type of bypass.
[1] https://www.wordfence.com/help/firewall/optimizing-the-firewall/
—
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.