APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Keeping Microsoft Exploits out of your apache log files

© January 2005 Bruce Garlock

(Traditional format)

Mon Jan 24 20:37:06 2005 Keeping Microsoft Exploits out of your apache log files
Posted by Bruce Garlock
Search Keys: WebDAV, redirection, apache logs, microsoft, exploits

Another new Microsoft IIS exploit, for WebDAV is hitting the net pretty hard, and each request adds 32k of junk to your apache logs. Since I have a few web servers on the net, that log to a logging host, the disk space started getting filled up quicker than usual. I noticed the following was taking up a good size of these logs: - - [24/Jan/2005:13:37:06 -0500] "SEARCH /\x90\x02�\x02�\x02�\x0

All in all, it totals about 32k, per request. I did a 'wc -l' on my access logs for a couple of my servers, and I have well over 5,000 lines of this junk.

Although I am not going to be hacked, certainly this would probably cause some issues when trying to search the access_log, or for any log file processors like webalizer. Depending on how you have written your home grown scripts, this request could possibly make them choke, or give you undesireable results.

So, I decided to try and find a way to block these requests, so they would not be logged. At first, I was going to blacklist the IP's at the firewall, but I soon found out that they were coming from all over the place, so someone probably has written some kind of IP spoofing into this script to fool webmasters. I turned to google, and saw lots of recent posts about this issue, along with some peoples' suggestions for combatting this attack. I decided to use a redirection rule, to send the request to the company that makes all these exploits possible: Microsoft.

Here is the solution that I chose to deploy, since it takes care of some other MS only exploits. I also have another solution from the google searches, following this solution.

# Send MS IIS Exploits to the company who makes them all possible!
<IfModule mod_rewrite.c>
RedirectMatch permanent (.*)cmd.exe(.*)$  https://www.microsoft.com 
RedirectMatch permanent (.*)root.exe(.*)$  https://www.microsoft.com 
RedirectMatch permanent (.*)\/_vti_bin\/(.*)$  https://www.microsoft.com 
RedirectMatch permanent (.*)\/scripts\/\.\.(.*)$  https://www.microsoft.com 
RedirectMatch permanent (.*)\/_mem_bin\/(.*)$  https://www.microsoft.com 
RedirectMatch permanent (.*)\/msadc\/(.*)$  https://www.microsoft.com 
RedirectMatch permanent (.*)\/MSADC\/(.*)$  https://www.microsoft.com 
RedirectMatch permanent (.*)\/c\/winnt\/(.*)$  https://www.microsoft.com 
RedirectMatch permanent (.*)\/d\/winnt\/(.*)$  https://www.microsoft.com 
RedirectMatch permanent (.*)\/x90\/(.*)$  https://www.microsoft.com 

Here is another possibility:

# Stupid MS IIS WebDAV exploit filling up logs
RewriteEngine On
RewriteRule ^.* - [F,L]

Hopefully my logs will start calming down a bit, since I saw an average of 26 times the normal log sizes on my web servers from this junk. I can imagine some sites are really being hammered even more. Why don't these kids who write this junk, at least check to make sure the machine they are targetting is running the right software. I guess they think that if they through enough *hit at the wall, some of it will stick.


Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> Microsoft Exploits out of your apachelog files


Inexpensive and informative Apple related e-books:

iOS 8: A Take Control Crash Course

Take Control of Preview

Take Control of Apple Mail, Third Edition

Take Control of Upgrading to El Capitan

Sierra: A Take Control Crash Course

More Articles by © Bruce Garlock

---January 25, 2005

No spoofing, just a whole bunch of script kiddies.


Yup - since they don't even bother to check the type of server they are running their exploit against, you can tell that they don't even have a clue. Have you seen any of these in your logs yet?


---January 25, 2005

I have not, but I may have already short-circuited those with something else I did a while ago - can't really remember right now and haven't had a chance to go look if that's the reason.. I will check eventually.


---January 25, 2005

This does not seem to be working, so I will have to see why. I know I sent a SIGHUP to apache, to get the changes, so there must be something else. I am thinking I may just disable SEARCH, and only allow GET, PUT, and a few others.


---January 27, 2005

Load average on our busy "Secure" Linux HTTPS server hit 10.00! This article helped me find the problem, and return the load average to a more normal < 0.50. Thanks!

Ben Smith

---January 31, 2005

Hi Ben,

Have you figured out a better fix than the one I presented? I am still searching for an easier way to filter out these requests. I have not spent much time on it yet, but I hope to today, since my logs are getting hammered even more!


---January 31, 2005

The re-write stuff can go in .htaccess too..


---February 2, 2005

Another take is this from the Mandrake Community TWiki. It both redirects the "attack" to a non existant IP number, but it also ensure that the huge log entries they make don't get made. This keeps log analyzers like Webalizer etc from choking. I've been using this since Oct last year on 3 sites and so far no hassle. I also get a lot cleaner log stats now than before. The things that hit my site are real, not infected winboxen.


--James Sparenberg

---February 4, 2005

I, too, was seeing my logs bloat 4x, and although overall I like the suggestion from James/Mandrake the best (redirecting to a dummy IP) for many situations, I've got to admit that I liked the idea of redirects to Microsoft.

Feeling a little spiteful, I used the redirects Bruce had listed (James hadn't posted his resolution yet), and discovered that the redirects to microsoft.com failed as well. Since they seemed to be popular with Google (I had searched quite a bit myself), I had a hunch and just extended the URL beyond the base domain, redirecting to the Microsoft IIS page's location instead.

It seems to be working like a charm, as for three days my logs were clean as a whistle (well, with regards to junk that is). I changed it back to the base domain as a test, and sure enough, the crud's showing back up in my logs. I'm changing it back now to confirm, but feel pretty sure that just using MS's base domain was the problem (perhaps they were getting extra-hammered and did something with their own configs?).

If you want to vent a little yourself, just use the URL:

in your redirects and it will send the zombie-stench onward!

--David Scribner

Mon Jun 27 09:49:57 2005: 723   anonymous

I redirect this kind of stuff to www.fbi.gov. The reasoning behind this is that if there is a way to cause grief to a hacker, then this will be it. Sure enough, even if someone uses 200 zombies to send out the packets or simply spoofs his IP address, it is very well possible (at a high cost, of course) to track the offender down. Since the FBI won't appreciate being the target of a hacking attack, chances are good they'll spend time and money on making some people unhappy. And as a governmental institution, their abilities are better than those of MS :)

Tue Jun 28 01:17:41 2005: 729   BigDumbDinosaur

I like this idea. I really haven't seen much of this crud show up on any of the servers under my control. However, I think I'll set it up anyhow, just in case.

Mon Jun 26 18:02:42 2006: 2175   anonymous

redirecting script kiddies to is what I prefer doing :)



Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version

UNIX is simple. It just takes a genius to understand its simplicity. (Dennis Ritchie)

Linux posts

Troubleshooting posts

This post tagged:







Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode