Celebrating 20 years online :)
Web Dev + WordPress + Security

Block Greasy Uploads Scanner

Whether you’re running WordPress or not, your site may be getting hit by endless scanning for your site’s uploaded files and similar nonexistent resources. Specifically, the “Greasy Uploads Scanner” endlessly scans sites for nonexistent resources in the /uploads/ directory, even if the directory itself doesn’t exist. Just mindless scanning for all sorts of weird files. It steals your server resources and threatens your site security. We hates them. And we wants to block them.

What the scan looks like

To give you a better idea of the type of malicious scanning we’re talking about, here are some example URI requests taken directly from the log files:


Each greasy scan requests around 1,500 of these URIs within about 3 minutes. Until I blocked them, I was getting numerous scans like this every day. Was maddening.

So can we block these types of requests based on the requested URIs? To do so, we would need to block either /wp-content/ or /uploads/, which only makes sense if your site is NOT using those particular directories. If that sounds like you, then a few simple lines in your site’s root .htaccess file will block them all:

# Block Greasy Uploads Scanner (non-WP sites)
<IfModule mod_alias.c>
	RedirectMatch 403 ^/wp-content/uploads/

That code will stop the greasy scans cold. Again, you would only want to implement this technique on non-WP sites or WP sites that are NOT using the /uploads/ directory. If you are using WordPress, blocking via the request URI won’t work. So let’s continue the investigation until a solution presents itself.

Associated user agents

The greasy scans also provide an example of why it can be ineffective to block requests based on user agent. There are just too many strings that would need to be blocked. During the scan, the reported user agent changes. Here is a sampling:

Mozilla/5.0 (iPhone; CPU iPhone OS 9_0_2 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13A452 Safari/601.1

Mozilla/5.0 (Windows NT 10.0; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0

Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.71 Safari/537.36

Mozilla/5.0 (Linux; Android 4.2.2; SM-T111M Build/JDQ39) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.76 Safari/537.36

Mozilla/5.0 (Linux; Android 4.2.1; en-us; Nexus 5 Build/JOP40D) AppleWebKit/535.19 (KHTML, like Gecko; googleweblight) Chrome/38.0.1025.166 Mobile Safari/535.19

Mozilla/5.0 (Linux; U; Android 4.1.2; pt-br; GT-S5310B Build/JZO54K) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30

Mozilla/5.0 (Linux; Android 4.4.2; SM-T210 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/ Safari/537.36 GSA/

Mozilla/5.0 (Linux; Android 4.4.2; SM-G313ML Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.94 Mobile Safari/537.36

Mozilla/5.0 (iPhone; CPU iPhone OS 8_4_1 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) GSA/9.0.60246 Mobile/12H321 Safari/600.1.4

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.71 Safari/537.36

Mozilla/5.0 (Linux; Android 5.0.2; XT1069 Build/LXB22.99-16.3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.76 Mobile Safari/537.36

Mozilla/5.0 (Linux; Android 4.3; SM-G3502T Build/JLS36C) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.84 Mobile Safari/537.36

So even if we wanted to block based on the reported user agent, it would be virtually impossible because of similarities with legitimate agents. So after excluding legit strings like Mozilla, Linux, Android, Chrome, and so forth, there wouldn’t be any effective patterns to match against. Perhaps we can stop these scans based on the associated IP addresses? Let’s find out..

Associated IP addresses

If you’re familiar with my tutorials, you’ve probably heard me mention that in general blocking based on IP address is only recommended for blocking specific, individual threats. Like when you want to block some scumbag from lurking around and stalking your other users. Stuff like that. Attempts to block bots, scripts, and other automated requests via IP results in a LOT of false positives and ultimately is pretty ineffective. This is because most malicious activity is routed through some sort of proxy service to obscure identity. And the IPs used by proxies change constantly, so there’s no point in trying to block them. Besides, there are far better ways to block bad bots and bad requests.

With that in mind, the IPs associated with the Greasy Uploads Scanner serve as a perfect example of why blocking via IP address is futile. If there were only a handful of offending IPs, that would be great; we could easily block all greasy upload scans with a few choice directives. Unfortunately, the greasy scans report hundreds of different IPs. Check it out for yourself:

Right? That’s a lot of IPs to block, far too many to make it worthwhile. The server would have to work through each of those IPs for every request. So it would be better for performance to just let the greasy bastard scan your site.

For more information about blocking IPs, how I collect data, and other relevant details, read through my article, Worst IPs: 2016 Edition.

Associated referrers

Continuing our hunt for a simple, effective way to block the greasy uploads scans, we examine the reported referrer URLs. Here are some examples from the log file:


Yep, that will do it. Pretty much every reported referrer is from either trikaladay.com.br or todaperfeita.com.br. This presents a simple, effective solution that can be implemented via .htaccess:

# Block Greasy Uploads Scanner
<IfModule mod_rewrite.c>
	RewriteCond %{HTTP_REFERER} todaperfeita [NC,OR]
	RewriteCond %{HTTP_REFERER} trikaladay   [NC]
	RewriteRule (.*) - [F,L]

..aaand mission accomplished. Here we are checking the referrer for either offender, and then blocking them with a 403 “Forbidden” server response. Simple, effective, and elegant. Just for fun, we could also combine the two directives, like so:

RewriteCond %{HTTP_REFERER} (todaperfeita|trikaladay) [NC]

It’s just good times all around.

About the Author
Jeff Starr = Designer. Developer. Producer. Writer. Editor. Etc.
GA Pro: Add Google Analytics to WordPress like a pro.
Perishable Press is operated by Jeff Starr, a professional web developer and book author with two decades of experience. Here you will find posts about web development, WordPress, security, and more »
BBQ Pro: The fastest firewall to protect your WordPress.
Crazy that we’re almost halfway thru 2024.
I live right next door to the absolute loudest car in town. And the owner loves to drive it.
8G Firewall now out of beta testing, ready for use on production sites.
It's all about that ad revenue baby.
Note to self: encrypting 500 GB of data on my iMac takes around 8 hours.
Getting back into things after a bit of a break. Currently 7° F outside. Chillz.
Get news, updates, deals & tips via email.
Email kept private. Easy unsubscribe anytime.