anyone know what these lines are in my proxy logs?

[Richard Darling]

Is anyone familiar with these lines in my web proxy log. I only started to get them yesterday, and was wondering if I should be concerned.
Thanks...Richard

-, -, -, N, 9/18/01, 9:15:59, 1, -, -, -, -, -, -, -, -, -, -, -, /scripts/root.exe?/c+dir, -, -, 0, 0
-, -, -, N, 9/18/01, 9:16:02, 1, -, -, -, -, -, -, -, -, -, -, -, /scripts/root.exe?/c+dir, -, -, 0, 0
-, -, -, N, 9/18/01, 9:16:02, 1, -, -, -, -, -, -, -, -, -, -, -, /MSADC/root.exe?/c+dir, -, -, 0, 0
-, -, -, N, 9/18/01, 9:16:03, 1, -, -, -, -, -, -, -, -, -, -, -, /c/winnt/system32/cmd.exe?/c+dir, -, -, 0, 0
-, -, -, N, 9/18/01, 9:16:03, 1, -, -, -, -, -, -, -, -, -, -, -, /d/winnt/system32/cmd.exe?/c+dir, -, -, 0, 0
-, -, -, N, 9/18/01, 9:16:03, 1, -, -, -, -, -, -, -, -, -, -, -, /MSADC/root.exe?/c+dir, -, -, 0, 0
-, -, -, N, 9/18/01, 9:16:03, 1, -, -, -, -, -, -, -, -, -, -, -, /scripts/..%255c../winnt/system32/cmd.exe?/c+dir, -, -, 0, 0
-, -, -, N, 9/18/01, 9:16:03, 1, -, -, -, -, -, -, -, -, -, -, -, /_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir, -, -, 0, 0
-, -, -, N, 9/18/01, 9:16:04, 1, -, -, -, -, -, -, -, -, -, -, -, /_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir, -, -, 0, 0
-, -, -, N, 9/18/01, 9:16:04, 1, -, -, -, -, -, -, -, -, -, -, -, /msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/system32/cmd.exe?/c+dir, -, -, 0, 0
-, -, -, N, 9/18/01, 9:16:04, 1, -, -, -, -, -, -, -,

[Kurt Matthies]

These are attacks by someone or something that are trying to take advantage of quite a few known NT vulnerabilities.

This is a smorgasboard of attacks. The first few lines are attempting to invoke the Code Red II payload file, root.exe.

Then there is an attempt through default shares in IIS to get hold of the CMD program "DOS box" via HTTP, and access the C: directory on your server.

You should be concerned, and apply the patches in SP6a and the Post 6a Security patch available from microsoft.com

Your Proxy server is protecting you from most harm. Use the packet filtering in the WinsockProxy to further button up your network.

Good luck and contact me if you need further help at kwgm@mesainteractive.com

[Bradley S. DeForest]

I have similar lines in our logs as well. Like you we just started getting them sept 18. I had loaded the NT 6a patch awhile back, what else do I need to do and how can I tell if the attacker has damaged the system?

[Richard Darling]

Kurt,
Thanks for the info. I have the SP6a service pack applied, and also the "15 August 2001 Cumulative Patch for IIS".

What do you mean by "Post 6a"?
Also, what suggestions do you have for the packet filtering in the WinsockProxy?

Finally, as Brad stated, "what else do I need to do and how can I tell if the attacker has damaged the system.."

I have spoken to several other sites who are having this same problem.

Any suggestions and details on steps to take are appreciated with points.

Please note that I will be assigning max. of 7 points for awhile because if forum members see the rabbit in the hat they don't check the question.

Thanks...Richard Darling

[Richard Darling]

Kurt,
Oh, you meant the Post 6a "Security Rollup Package". Got it (duh)...
Richard

[Richard Darling]

how do I stop theses attempts...the are almost continuous...thanks.
Richard Darling

[Kurt Matthies · Accepted solution]

Gang,

This is a NIMDA attack.

As I said, this is a smorgasboard of attacks. NIMDA does just that. Looks for a variety of weaknesses in IIS.

This attack started on the afternoon of the 18th.

In one website log (I host maybe 2 dozen), there were 384 separate probes. Mostly they come from neighboring IPs, (ie, addresses on the same 2 first octets).

This is a nasty virus should you become infected.

It primarily comes via an email attachment named readme.exe. There is a patch on microsoft.com to fix IE 5.0 and 5.5 tendency to open these attachments even though the email is only read or previewed via Automatic Execution of Embedded MIME Types. Look this up in the KB (knowledge base) to get the patch.

There are other problems once the infection occurs on your website. Mucho cleanup!

And for whomever asked how to stop this.... make sure that every IIS server you control has the lasted patches from microsoft. The less infected servers, the less there are these nasty probes going around.

I would also recommend that you change the permissions on the %System% hierarchy so that only Adminstrators have access. This is always a good idea.

Good luck.

[Kurt Matthies]

OK, I just read Brad's message.

Brad, the SP6a is NOT enough to protect you.

I'm going to share a couple of Microsoft URls that will help you bring your system up to "code" as far as security patches.

First, you need to load the "Post SP6a Security Patch" which is KB article: Q299444. You can find this at: http://support.microsoft.com/support/kb/articles/Q299/4/44.ASP

Download this and apply it.

Next you want to keep checking your system agains the Hotfix Security Checker. This is an application created for Microsoft that checks an XML database on microsoft.com against the hotfixes you've loaded on your NT and 2000 servers. Microsoft will update this database when they create a new hotfix, and you will be alerted when you run the program. This can be found at: Q303215

Finally, here's the Official Microsoft link on what to do about Nimda:

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/topics/nimda.asp

Now Richard, I don't really understand what you said about points and that doesn't matter.

If all of our NT and 2000 systems were buttoned up, then worms like Code Red II and Nimda wouldn't be able to propagate.

That's why I share this info.

Unfortunately NT and 2000 servers are not secure "out of the box" but need skilled administrators and consultants to configure them. The sooner IT managers realize this, the sooner we can get a handle on this security crisis.

I'll get off my soapbox and back to the computer room.

[Richard Darling]

Kurt,
I have spent all day checking this out. At first I thought it might have been an internal machine doing this, but this afternoon I disconnected the external card and the attacks stopped...then I picked up a second router and set it up so that oue network is not visible to anyone outside. I went to the grc.com site and ran the tests and probes...all seems buttoned up.

All of our anti-virus programs, IE updates, and server patches were up-to-date.

I them started checking each machine for the files root.exe, admin.dll, readme.eml...found none. Late this afternoon printed out more info. and will get back to it tomorrow AM.

Kurt...the thing about the points...when you assign more than 7 points the "magic answer (rabbit in the hat)" shows next to the thread. I have noticed that fewer users of the forum check it out after that because they think that the problem has been solved...so if I feel that a thread isn't ready to wrap up I don't assign more than 7 points.

Thanks for your help and insight...

Richard

BTW...where has Jamie ben lately?

[Kurt Matthies]

Richard,

Thanks for the explanation on the points.

I can understand that you are still under attack, as we all are. As long as you have your patches up to date, you are safe from this one. (who knows about the next one).

Here's another IIS security tip that may help the next one....

The Default Web Site (site #1) defines the web shares to many of these places that attacks like nimda and Code Red target, ie,
/IISAdmin, /Scripts, /MSADC, etc.

Make this site and therefore these shares inaccessible to outsite access by controlling which IP addresses have access using:

Properties/Directory Security/IP Address and Domain Name Restrictions

In this dialog box, set to Deny All, except for 127.0.0.1 and your local network address to this list (eg, 10.0.0.1 and 255.255.255.0)

This will eliminate any outside access to these directories via IIS.

Here's the caveat. Make sure your existing web applications still work. Test Help in the IIS admin interface, the MMC. Test OWA. Test any other Web app that you may be using in your enterprise from this server.

I have not found an instance where I've broken something, but this is configuration dependent, I'm sure.

Get your bastion secure for the next attack.

regards.