"The simple presence of .eml/.nws files, or copies of readme.exe, does not
in and of itself indicate an infected machine. If the files are put there
because of an infected client through a file share, they may not have been
run on the server yet."
100% of the clients I have seen, 25+, that have .eml files are infected and
many without the .eml files are also infected.
Just what I have seen,
Mike
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: "NT System Admin Issues" <[EMAIL PROTECTED]>
Sent: Thursday, September 20, 2001 9:11 AM
Subject: RE: HELP VIRUS ON NT MACHINE?
> The following is from Russ Cooper off NTBugtraq - sent last night.
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Its been an exhaustive couple of days, for you all I'm sure.
>
> The Problem
> - -----------
> I've just gotten off the phone with numerous experts from the major
> companies (including AV experts and CARO members) in an effort to
> answer the question; "Is it possible to trust a cleansed server?"
>
> See, due to the things Nimda does, it may well leave your machine
> open to easy access. Even if the virus/worm components have been
> removed/cleansed, if another attack occurs that exploits the open
> shares (for example) who knows what the attack might do or leave
> behind. The effects of such an attack are not going to be obvious to
> an AV product.
>
> Basically, cleansers available now do not address some of the more
> insidious components of Nimda;
>
> - - Guest account being enabled. In the case of an infected Domain
> Controller, this means the account is enabled in the Domain.
>
> - - Guest account being added to the Administrators group. Again, on
> DCs the Guest user is added to the Domain Admins group.
>
> - - Modification to registry keys. Some reports say that values under
> LanManServer\Parameters are deleted, in an effort to remove any
> AutoShareServer value that might prevent the availability of C$,
> etc...), while other reports talk only of the creation of new shares
> (C$, D$, etc...) under that key.
>
> - - Numerous critical system files are modified, including files in the
> dllcache directory, and its questionable whether or not these can be
> restored to good health by an untested cleanser (the suggestion that
> SSL functionality might not work after cleansing.)
>
> Then there is the question as to whether or not all of the effects of
> Nimda have actually been determined. With its buggy operation, its
> possible it might do other things inconsistently, in a way that might
> leave cleansers lacking.
>
> Testing we performed today suggested that cleansers that were
> available all did a reasonable job of disinfecting an infected file,
> but the testing was limited to that since cleansing infected systems
> would require an extremely wide variety of installations.
>
> Additional Threats
> - ------------------
>
> With the open shares available, it would be possible for an attacker
> to gain entry to your system and retrieve or deposit other tools or
> data (like copying your SAM). These effects will be undetectable as
> part of AV Nimda cleansing, and could only be uncovered as a result
> of an extensive forensic effort.
>
> You should seriously consider the possibility that this has already
> happened to machines which might hold sensitive information if you
> have left them connected, or reconnect prior to a comprehensive
> cleansing and inspection.
>
> Decision Time
> - -------------
>
> The bottom line folks is that as of the time of writing, you have to
> make a decision;
>
> a) I need the system up and running now!
>
> Fine, disconnect it from infection vectors, restore it from tape or
> reformat and install fresh, patch it. Restore the data (even if its
> infected), run the currently available cleanser, and scan it again
> with your AV product. If it passes, reconnect it to the 'net and
> carry on.
>
> b) I can leave the machine turned off until Friday.
>
> Better, wait for a comprehensive cleanser from your AV Vendor
> (assuming they make one.) McAfee may already have one available and
> Symantec will have one shortly. Other AV Vendors may/will probably
> also produce one. The complexity of this thing has been such that
> multiple versions of cleansers have been required in order to do it
> "right". The same may be true of these additional cleansers.
>
> The Problem with Rebooting
> - --------------------------
>
> We noticed in our testing one cleanser that only worked if the
> machine was rebooted. Problem is that with a fully infected system, a
> reboot is not likely to bring up a live system. Depending on which
> files have been infected, a system might fail a reboot completely,
> partially, or succeed completely. Its probably safe to assume that
> rebooting an infected server is going to lead to a complete system
> failure and cause to re-install the OS.
>
> Without rebooting it may not be possible to cleanse all of the files
> that might cause re-infection. McAfee's recommendation is to stop IIS
> and all running applications and install patches, many of those
> patches require a reboot to install.
>
> So you see the Catch-22.
>
> Definitions
> - -----------
>
> For the purposes here, an infected system is one where Admin.dll or
> readme.exe has actually run locally. In the case of servers, this is
> most likely an IIS box infected from the network via one of the IIS
> vulnerabilities. It may, unfortunately, be the result of surfing the
> web or reading email from a server (really dumb things to do). I've
> had reports of Exchange Servers, Outlook Web Access Servers, IIS
> Servers, SQL Servers, Proxy Servers, SMS Servers, Domain Controllers,
> and File and Print Servers all being infected.
>
> If the box is actively TFTP'ing (inbound or outbound), issuing
> numerous HTTP requests (when you're not surfing), or if your AV
> product says you're infected, then you are. If the box has Admin.dll
> in the /scripts or root directory, has an enabled Guest account, or
> has Guest in the Administrators group (or Domain Admins group), then
> you're infected.
>
> The simple presence of .eml/.nws files, or copies of readme.exe, does
> not in and of itself indicate an infected machine. If the files are
> put there because of an infected client through a file share, they
> may not have been run on the server yet.
>
> Summary
> - -------
>
> More than a few people have offered perl scripts and other small
> programs designed to clean out the javascript from altered web pages.
> While this might seem like a good idea, the fact is that an infected
> web server can/will quickly re-add the code back to those pages if
> its still infected. Because of the virus behavior of Nimda, if you
> don't remove it completely there's not much you can do to prevent
> such re-infections. Obviously its not just a matter of removing
> files.
>
> I apologize for the delay in getting more information to those
> hundreds of you who have been pleading for help in cleansing your
> systems. I had hoped that the AV cleansers made available today would
> have solved the problems, but as the day wore on it became clearer
> that this wasn't going to happen as quickly as we all want.
>
> Cheers,
> Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Its been an exhaustive couple of days, for you all I'm sure.
>
> The Problem
> - -----------
> I've just gotten off the phone with numerous experts from the major
> companies (including AV experts and CARO members) in an effort to
> answer the question; "Is it possible to trust a cleansed server?"
>
> See, due to the things Nimda does, it may well leave your machine
> open to easy access. Even if the virus/worm components have been
> removed/cleansed, if another attack occurs that exploits the open
> shares (for example) who knows what the attack might do or leave
> behind. The effects of such an attack are not going to be obvious to
> an AV product.
>
> Basically, cleansers available now do not address some of the more
> insidious components of Nimda;
>
> - - Guest account being enabled. In the case of an infected Domain
> Controller, this means the account is enabled in the Domain.
>
> - - Guest account being added to the Administrators group. Again, on
> DCs the Guest user is added to the Domain Admins group.
>
> - - Modification to registry keys. Some reports say that values under
> LanManServer\Parameters are deleted, in an effort to remove any
> AutoShareServer value that might prevent the availability of C$,
> etc...), while other reports talk only of the creation of new shares
> (C$, D$, etc...) under that key.
>
> - - Numerous critical system files are modified, including files in the
> dllcache directory, and its questionable whether or not these can be
> restored to good health by an untested cleanser (the suggestion that
> SSL functionality might not work after cleansing.)
>
> Then there is the question as to whether or not all of the effects of
> Nimda have actually been determined. With its buggy operation, its
> possible it might do other things inconsistently, in a way that might
> leave cleansers lacking.
>
> Testing we performed today suggested that cleansers that were
> available all did a reasonable job of disinfecting an infected file,
> but the testing was limited to that since cleansing infected systems
> would require an extremely wide variety of installations.
>
> Additional Threats
> - ------------------
>
> With the open shares available, it would be possible for an attacker
> to gain entry to your system and retrieve or deposit other tools or
> data (like copying your SAM). These effects will be undetectable as
> part of AV Nimda cleansing, and could only be uncovered as a result
> of an extensive forensic effort.
>
> You should seriously consider the possibility that this has already
> happened to machines which might hold sensitive information if you
> have left them connected, or reconnect prior to a comprehensive
> cleansing and inspection.
>
> Decision Time
> - -------------
>
> The bottom line folks is that as of the time of writing, you have to
> make a decision;
>
> a) I need the system up and running now!
>
> Fine, disconnect it from infection vectors, restore it from tape or
> reformat and install fresh, patch it. Restore the data (even if its
> infected), run the currently available cleanser, and scan it again
> with your AV product. If it passes, reconnect it to the 'net and
> carry on.
>
> b) I can leave the machine turned off until Friday.
>
> Better, wait for a comprehensive cleanser from your AV Vendor
> (assuming they make one.) McAfee may already have one available and
> Symantec will have one shortly. Other AV Vendors may/will probably
> also produce one. The complexity of this thing has been such that
> multiple versions of cleansers have been required in order to do it
> "right". The same may be true of these additional cleansers.
>
> The Problem with Rebooting
> - --------------------------
>
> We noticed in our testing one cleanser that only worked if the
> machine was rebooted. Problem is that with a fully infected system, a
> reboot is not likely to bring up a live system. Depending on which
> files have been infected, a system might fail a reboot completely,
> partially, or succeed completely. Its probably safe to assume that
> rebooting an infected server is going to lead to a complete system
> failure and cause to re-install the OS.
>
> Without rebooting it may not be possible to cleanse all of the files
> that might cause re-infection. McAfee's recommendation is to stop IIS
> and all running applications and install patches, many of those
> patches require a reboot to install.
>
> So you see the Catch-22.
>
> Definitions
> - -----------
>
> For the purposes here, an infected system is one where Admin.dll or
> readme.exe has actually run locally. In the case of servers, this is
> most likely an IIS box infected from the network via one of the IIS
> vulnerabilities. It may, unfortunately, be the result of surfing the
> web or reading email from a server (really dumb things to do). I've
> had reports of Exchange Servers, Outlook Web Access Servers, IIS
> Servers, SQL Servers, Proxy Servers, SMS Servers, Domain Controllers,
> and File and Print Servers all being infected.
>
> If the box is actively TFTP'ing (inbound or outbound), issuing
> numerous HTTP requests (when you're not surfing), or if your AV
> product says you're infected, then you are. If the box has Admin.dll
> in the /scripts or root directory, has an enabled Guest account, or
> has Guest in the Administrators group (or Domain Admins group), then
> you're infected.
>
> The simple presence of .eml/.nws files, or copies of readme.exe, does
> not in and of itself indicate an infected machine. If the files are
> put there because of an infected client through a file share, they
> may not have been run on the server yet.
>
> Summary
> - -------
>
> More than a few people have offered perl scripts and other small
> programs designed to clean out the javascript from altered web pages.
> While this might seem like a good idea, the fact is that an infected
> web server can/will quickly re-add the code back to those pages if
> its still infected. Because of the virus behavior of Nimda, if you
> don't remove it completely there's not much you can do to prevent
> such re-infections. Obviously its not just a matter of removing
> files.
>
> I apologize for the delay in getting more information to those
> hundreds of you who have been pleading for help in cleansing your
> systems. I had hoped that the AV cleansers made available today would
> have solved the problems, but as the day wore on it became clearer
> that this wasn't going to happen as quickly as we all want.
>
> Cheers,
> Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Personal Privacy 6.5.2
>
> iQCVAwUBO6lXDRBh2Kw/l7p5AQHrPQQAxbgWKP8rGiVfHFJVTokzJMzGi851/hOt
> At1JKz8e+cTB1iLdfNb7KspV9VpbByBaI+dwZkoZe63pq4OGs1tuBB4PG9h8D4uw
> A/iH7Y/OkamrPM9mm4603xougdBs7n4cxwbMvE67kmK39849LWi7SkRGZq9obfKN
> dEB3tg6kYws=
> =9OVI
> -----END PGP SIGNATURE-----
>
> -----Original Message-----
> From: Miley, Dan [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, September 20, 2001 8:45 AM
> To: NT System Admin Issues
> Subject: RE: HELP VIRUS ON NT MACHINE?
>
>
> the word is that hackers have uploaded other tools to compromised servers.
> nmap, backorafice, etc. The next step is to use these machines for DDOS
> attacks.
>
> since guest is admin, that makes it easy.
>
> want to find a machine to make a zombie? their knocking on your firewall.
>
> If a machine has been compromised, and you didn't unplug the network cable
> when it started, the only way to be sure is to reload from backup or
fresh
> media.
>
> unless you're sure you can find ALL possible hacks that might have been
> uploaded to the machine.
>
> IMO.
> Dan
>
> -----Original Message-----
> From: Tiffany Belcher [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 19, 2001 11:36 PM
> To: NT System Admin Issues
> Subject: Re: HELP VIRUS ON NT MACHINE?
>
>
> Okay so I got the patch and cleaned up the server. It left about 7000
files
> on it. I searched un 9/19/2001 and found them and deleted them all. so the
> question is DO I WIPE IT AND REINSTALL? It works. THe websites work fine.
> THe only problem so far is when I try to update to explore 6 it says that
a
> previous update didnt finish. THere is so much on this server that it
would
> be a pain to reinstall it again. Advice?
>
> http://www.sunbelt-software.com/ntsysadmin_list_charter.htm
> This e-mail may be privileged and/or confidential, and the sender does not
> waive any related rights and obligations. Any distribution, use or copying
> of this e-mail or the information it contains by other than an intended
> recipient is unauthorized. If you received this e-mail in error, please
> advise me (by return e-mail or otherwise) immediately.
>
> http://www.sunbelt-software.com/ntsysadmin_list_charter.htm
>
> http://www.sunbelt-software.com/ntsysadmin_list_charter.htm
>
http://www.sunbelt-software.com/ntsysadmin_list_charter.htm
