How to Prevent Virus from Changing Read-Only and Hidden Attributes on Files Folders?

[W]

We have our Windows 2003 servers fairly locked down by NTFS, and when a user
browses the Internet they are logged in as an ordinary user with minimal
access to the file system. So imagine my horror to see that a virus was
able to change every single file and folder on the file system to be
read-only and hidden, apparently using the attributes for files that are
affected by the ATTRIB commandline command.

Is the ability to use ATTRIB controlled by NTFS permissions? Or is this
the Write Attributes permission in NTFS? Unfortunately we probably did
enable that because it was generating too many false positive audit
messages.

The command

attrib -h -r *.* /s /d

apparently does NOT affect all folders under the current folder. Is there
a command that can be used that would change every file and folder from the
current location and down all subtrees?

Is there any utility that would restore any critical system files and
folders to their original attributes?

[Char Jackson]

Post by W
We have our Windows 2003 servers fairly locked down by NTFS, and when a user
browses the Internet they are logged in as an ordinary user with minimal
access to the file system. So imagine my horror to see that a virus was
able to change every single file and folder on the file system to be
read-only and hidden, apparently using the attributes for files that are
affected by the ATTRIB commandline command.
Is there any utility that would restore any critical system files and
folders to their original attributes?

It sounds like you might need a tool called unhide.exe.
<http://www.bleepingcomputer.com/forums/topic405109.html>

[Peter Foldes]

Crossposted from microsoft.public.windows.server.general

Post by W
We have our Windows 2003 servers fairly locked down by NTFS, and when a user
browses the Internet they are logged in as an ordinary user with minimal access to
the file system. So imagine my horror to see that a virus was able to change
every single file and folder on the file system to be read-only and hidden,
apparently using the attributes for files that are affected by the ATTRIB
commandline command.
Is the ability to use ATTRIB controlled by NTFS permissions? Or is this the
Write Attributes permission in NTFS? Unfortunately we probably did enable that
because it was generating too many false positive audit messages.
The command
attrib -h -r *.* /s /d
apparently does NOT affect all folders under the current folder. Is there a
command that can be used that would change every file and folder from the current
location and down all subtrees?
Is there any utility that would restore any critical system files and folders to
their original attributes?
--
W

[David H. Lipman]

From: "Peter Foldes" <***@hotmail.com>

| Crossposted from microsoft.public.windows.server.general
|

Post by W
We have our Windows 2003 servers fairly locked down by NTFS, and when a
user browses the Internet they are logged in as an ordinary user with
minimal access to the file system. So imagine my horror to see that a
virus was able to change every single file and folder on the file system
to be read-only and hidden, apparently using the attributes for files
that are affected by the ATTRIB commandline command.
Is the ability to use ATTRIB controlled by NTFS permissions? Or is this
the Write Attributes permission in NTFS? Unfortunately we probably did
enable that because it was generating too many false positive audit
messages.
The command
attrib -h -r *.* /s /d
apparently does NOT affect all folders under the current folder. Is
there a command that can be used that would change every file and folder
from the current location and down all subtrees?
Is there any utility that would restore any critical system files and
folders to their original attributes?

A virus didn't hide files and folders, a System Fix trojan or other rogue
malware did.

If I understand this post, a user was ALLOWED to browse the Internet from
the POC of the Win2003 Server. If that was the case that was the mistake.
Nobody, users or administrators should be browsing on a server platform.
This is disrepecting the role of the server. A System Fix type trojan is
bad enough but that kind of behavioour (which should never be alloewd on a
server) coold have had more disaterous effects.

The first think to do is find and eliminate the System Fix type trojan and
then use Lawrence Abrams' (aka; Grinler) Unhide utility.
http://download.bleepingcomputer.com/grinler/unhide.exe

The Server may have to be booted in Safe Mode such that the trojan isn't
loaded. Note also do NOT dump TEMP folders prior to running Unhide. Unhide
may also be executed in Safe Mode.

[Dave Warren]

Post by David H. Lipman
If I understand this post, a user was ALLOWED to browse the Internet from
the POC of the Win2003 Server. If that was the case that was the mistake.
Nobody, users or administrators should be browsing on a server platform.
This is disrepecting the role of the server.

It really depends on the role of this particular server. If it's a
terminal server, then this could be well within it's designed usage
scope.

[David H. Lipman]

From: "Dave Warren" <dave-***@djwcomputers.com>

| In message <***@giganews.com> someone
| claiming to be "David H. Lipman" <DLipman~nospam~@Verizon.Net> typed:
|

Post by David H. Lipman
If I understand this post, a user was ALLOWED to browse the Internet from
the POC of the Win2003 Server. If that was the case that was the mistake.
Nobody, users or administrators should be browsing on a server platform.
This is disrepecting the role of the server.

|
| It really depends on the role of this particular server. If it's a
| terminal server, then this could be well within it's designed usage
| scope.

Browsing the Internet should not be within an accepted scope of the use of a
Terminal Server session.

[Dave Warren]

Post by David H. Lipman
|

Post by David H. Lipman
If I understand this post, a user was ALLOWED to browse the Internet from
the POC of the Win2003 Server. If that was the case that was the mistake.
Nobody, users or administrators should be browsing on a server platform.
This is disrepecting the role of the server.

|
| It really depends on the role of this particular server. If it's a
| terminal server, then this could be well within it's designed usage
| scope.
Browsing the Internet should not be within an accepted scope of the use of a
Terminal Server session.

Why not?

[David H. Lipman]

From: "Dave Warren" <dave-***@djwcomputers.com>

| In message <***@giganews.com> someone
| claiming to be "David H. Lipman" <DLipman~nospam~@Verizon.Net> typed:
|

|>

Post by David H. Lipman

Post by David H. Lipman
If I understand this post, a user was ALLOWED to browse the Internet from
the POC of the Win2003 Server. If that was the case that was the mistake.
Nobody, users or administrators should be browsing on a server platform.
This is disrepecting the role of the server.

|>
|> It really depends on the role of this particular server. If it's a
|> terminal server, then this could be well within it's designed usage
|> scope.

Post by David H. Lipman
Browsing the Internet should not be within an accepted scope of the use of a
Terminal Server session.

|
| Why not?

Browsing should be done on the client machine (workstation) and *never* done
on a Server because the chances of malware infections (infestation for you
Kurt) are increased significantly and this would be isolated to a
workstation (client). An infection on a Server affects all users and their
ability to use the services that Server provides. Thus a violation of the
role of the Server. One can simply state it reduces its IA status.

[Dustin]

Post by David H. Lipman
|

|>

Post by David H. Lipman

Post by David H. Lipman
If I understand this post, a user was ALLOWED to browse the Internet from
the POC of the Win2003 Server. If that was the case that was the mistake.
Nobody, users or administrators should be browsing on a server platform.
This is disrepecting the role of the server.

|>
|> It really depends on the role of this particular server. If it's a
|> terminal server, then this could be well within it's designed
|> usage scope.

Post by David H. Lipman
Browsing the Internet should not be within an accepted scope of the use of a
Terminal Server session.

|
| Why not?
Browsing should be done on the client machine (workstation) and
*never* done on a Server because the chances of malware infections
(infestation for you Kurt) are increased significantly and this would
be isolated to a workstation (client). An infection on a Server
affects all users and their ability to use the services that Server
provides. Thus a violation of the role of the Server. One can
simply state it reduces its IA status.

A virus would prefer the users allow it access to the server. Makes it's
life alot easier from an infection POV. [g]

[W]

Post by David H. Lipman
| Crossposted from microsoft.public.windows.server.general
|

Post by W
We have our Windows 2003 servers fairly locked down by NTFS, and when a
user browses the Internet they are logged in as an ordinary user with
minimal access to the file system. So imagine my horror to see that a
virus was able to change every single file and folder on the file system
to be read-only and hidden, apparently using the attributes for files
that are affected by the ATTRIB commandline command.
Is the ability to use ATTRIB controlled by NTFS permissions? Or is
this the Write Attributes permission in NTFS? Unfortunately we
probably did enable that because it was generating too many false
positive audit messages.
The command
attrib -h -r *.* /s /d
apparently does NOT affect all folders under the current folder. Is
there a command that can be used that would change every file and folder
from the current location and down all subtrees?
Is there any utility that would restore any critical system files and
folders to their original attributes?

A virus didn't hide files and folders, a System Fix trojan or other rogue
malware did.
If I understand this post, a user was ALLOWED to browse the Internet from
the POC of the Win2003 Server. If that was the case that was the mistake.
Nobody, users or administrators should be browsing on a server platform.
This is disrepecting the role of the server. A System Fix type trojan is
bad enough but that kind of behavioour (which should never be alloewd on a
server) coold have had more disaterous effects.

The Windows 2003 server in question is actually an individual's personal
workstation. He prefers to use Server for many reasons as his workstation,
and one of those reasons is the ability to come in by Terminal Services
without disrupting the console session.

To be honest, this malware would have done minimal damage had we just not
allowed the Users group to have Write Attributes permissions on such a wide
file system scope. We had allowed that because so many applications give
security error log messages after attempting to change an attribute that it
rendered logging very cumbersome. We clearly didn't understand the
implication of that setting and now we do. So no user should have global
Write Attributes. Check. :)

Other than that, the virus was only able to change files and add new files
inside the user's profile folder. We simply deleted that folder and had
the user login fresh to create a new profile folder. That at least
contained the initial active part of the infection, and we'll have to
continue with other utilities later.

Post by David H. Lipman
The first think to do is find and eliminate the System Fix type trojan and
then use Lawrence Abrams' (aka; Grinler) Unhide utility.
http://download.bleepingcomputer.com/grinler/unhide.exe
The Server may have to be booted in Safe Mode such that the trojan isn't
loaded. Note also do NOT dump TEMP folders prior to running Unhide.
Unhide may also be executed in Safe Mode.

All of those utilities look useful thanks.

I could not get the MS Standalone Sweeper to create a standalone CD. It
gives an error when trying to write the CD that has no error code and simply
indicates it cannot continue. Amazing that it took MS 10 years to
finally understand that to beat a virus effectively you should boot from a
dedicated uninfected OS, without invoking the OS of system under test.
Better late than never, assuming I can ever get it to work.

[David H. Lipman]

Post by Peter Foldes
Crossposted from microsoft.public.windows.server.general

We have our Windows 2003 servers fairly locked down by NTFS, and when a user browses
the Internet they are logged in as an ordinary user with minimal access to the file
system. So imagine my horror to see that a virus was able to change every single
file and folder on the file system to be read-only and hidden, apparently using the
attributes for files that are affected by the ATTRIB commandline command.
Is the ability to use ATTRIB controlled by NTFS permissions? Or is this the Write
Attributes permission in NTFS? Unfortunately we probably did enable that because it
was generating too many false positive audit messages.
The command
attrib -h -r *.* /s /d
apparently does NOT affect all folders under the current folder. Is there a command
that can be used that would change every file and folder from the current location
and down all subtrees?
Is there any utility that would restore any critical system files and folders to
their original attributes?

A virus didn't hide files and folders, a System Fix trojan or other rogue malware did.
If I understand this post, a user was ALLOWED to browse the Internet from the POC of
the Win2003 Server. If that was the case that was the mistake. Nobody, users or
administrators should be browsing on a server platform. This is disrepecting the role
of the server. A System Fix type trojan is bad enough but that kind of behavioour
(which should never be alloewd on a server) coold have had more disaterous effects.

The Windows 2003 server in question is actually an individual's personal workstation.
He prefers to use Server for many reasons as his workstation, and one of those reasons
is the ability to come in by Terminal Services without disrupting the console session.
To be honest, this malware would have done minimal damage had we just not allowed the
Users group to have Write Attributes permissions on such a wide file system scope. We
had allowed that because so many applications give security error log messages after
attempting to change an attribute that it rendered logging very cumbersome. We
clearly didn't understand the implication of that setting and now we do. So no user
should have global Write Attributes. Check. :)
Other than that, the virus was only able to change files and add new files inside the
user's profile folder. We simply deleted that folder and had the user login fresh to
create a new profile folder. That at least contained the initial active part of the
infection, and we'll have to continue with other utilities later.

The first think to do is find and eliminate the System Fix type trojan and then use
Lawrence Abrams' (aka; Grinler) Unhide utility.
http://download.bleepingcomputer.com/grinler/unhide.exe
The Server may have to be booted in Safe Mode such that the trojan isn't loaded. Note
also do NOT dump TEMP folders prior to running Unhide. Unhide may also be executed in
Safe Mode.

All of those utilities look useful thanks.
I could not get the MS Standalone Sweeper to create a standalone CD. It gives an error
when trying to write the CD that has no error code and simply indicates it cannot
continue. Amazing that it took MS 10 years to finally understand that to beat a
virus effectively you should boot from a dedicated uninfected OS, without invoking the
OS of system under test. Better late than never, assuming I can ever get it to work.

This was not a case of a virus and if you are the administartor of some system of systems
which included this Windows 2003 server then that explains the poor security and this
trojan getting installed.

If this was a virus you and your comapny would have been up shits creek becaus ethe virus
would have infected other files and spread beyond the borders of this one Windows 2003
server to other systems on your network.

[W]

Post by David H. Lipman

Post by Peter Foldes
Crossposted from microsoft.public.windows.server.general

We have our Windows 2003 servers fairly locked down by NTFS, and when a user browses
the Internet they are logged in as an ordinary user with minimal access to the file
system. So imagine my horror to see that a virus was able to change every single
file and folder on the file system to be read-only and hidden, apparently using the
attributes for files that are affected by the ATTRIB commandline command.
Is the ability to use ATTRIB controlled by NTFS permissions? Or is this the Write
Attributes permission in NTFS? Unfortunately we probably did enable that because it
was generating too many false positive audit messages.
The command
attrib -h -r *.* /s /d
apparently does NOT affect all folders under the current folder. Is there a command
that can be used that would change every file and folder from the current location
and down all subtrees?
Is there any utility that would restore any critical system files and folders to
their original attributes?

A virus didn't hide files and folders, a System Fix trojan or other rogue malware did.
If I understand this post, a user was ALLOWED to browse the Internet from the POC of
the Win2003 Server. If that was the case that was the mistake. Nobody, users or
administrators should be browsing on a server platform. This is disrepecting the role
of the server. A System Fix type trojan is bad enough but that kind of behavioour
(which should never be alloewd on a server) coold have had more disaterous effects.

The Windows 2003 server in question is actually an individual's personal workstation.
He prefers to use Server for many reasons as his workstation, and one of those reasons
is the ability to come in by Terminal Services without disrupting the console session.
To be honest, this malware would have done minimal damage had we just not allowed the
Users group to have Write Attributes permissions on such a wide file system scope. We
had allowed that because so many applications give security error log messages after
attempting to change an attribute that it rendered logging very cumbersome. We
clearly didn't understand the implication of that setting and now we do.

So no user

Post by David H. Lipman

should have global Write Attributes. Check. :)
Other than that, the virus was only able to change files and add new files inside the
user's profile folder. We simply deleted that folder and had the user login fresh to
create a new profile folder. That at least contained the initial active part of the
infection, and we'll have to continue with other utilities later.

The first think to do is find and eliminate the System Fix type trojan and then use
Lawrence Abrams' (aka; Grinler) Unhide utility.
http://download.bleepingcomputer.com/grinler/unhide.exe
The Server may have to be booted in Safe Mode such that the trojan isn't loaded. Note
also do NOT dump TEMP folders prior to running Unhide. Unhide may also be executed in
Safe Mode.

All of those utilities look useful thanks.
I could not get the MS Standalone Sweeper to create a standalone CD.

It gives an error

Post by David H. Lipman

when trying to write the CD that has no error code and simply indicates it cannot
continue. Amazing that it took MS 10 years to finally understand that to beat a
virus effectively you should boot from a dedicated uninfected OS, without invoking the
OS of system under test. Better late than never, assuming I can ever get it to work.

This was not a case of a virus and if you are the administartor of some system of systems
which included this Windows 2003 server then that explains the poor security and this
trojan getting installed.
If this was a virus you and your comapny would have been up shits creek becaus ethe virus
would have infected other files and spread beyond the borders of this one Windows 2003
server to other systems on your network.

First, some Trojans also act like viruses and attempt to spread. Some do
not. Why is it important to this discussion?

Second, no virus would have done the damage you describe because we browse
the Internet from ordinary Users accounts (unlike 90% of all other user
organizations where being "Administrator" all the time seems to be a common
practice) and because we further went to extraordinary lengths to render
Users unable to write to the vast majority of the file system. For
example, on all of our computers, we prevent an ordinary user from being
able to create a new file in the Windows, System32, or Windows Temp folders.
Shared file access across user accounts on the same machine are through a
carefully controlled folder. Access to the SAM files and their backups is
explicitly denied, rendering brute force attacks on passwords impossible.

Third, there was nothing in the original post or its follow on that would
give you any basis for determining what the adequacy of our security
measures was or is. You shouldn't make stuff up just for bravado.

I appreciate the utilities that were posted as those are enormously useful.

[David H. Lipman]

This post might be inappropriate. Click to display it.

[W]

Post by David H. Lipman
The fact that you have an infected computer means you *must* re-examine your
security model, run IA scans and mitigate vulknerabilities that may have
been used in this malware incident. The fact that this was a 2003 Server
and not a workstation OS also m,eans that the application and its usage
needs re-evaluation. Today it was this malware. You don't want it to be a
really nasty malware infection one that may have rteal finacial and/or other
costs like data exfiltration.
Some note...
1. Rethink your security model
2. Perform an IA scan on the systems and subsystems and mitigate all
vulnerabilities
3. Rethink your server application model for the affected user. (Ex. Switch
use to Citrix)
4. Scan the computer with anti virus/anti malware software and computers
used in its electronic vicinity. My Multi-AV Scanning Tool mnay be of
assistance.

When you say IA Scans, are you meaning to verify the presence of data files?
What tools would do this?

In terms of security model, how do you like to use Citrix or Terminal
Server? I had toyed with the idea of having the individual's local
computer be used just for local data access and have all browsing be
consolidated to a remote computer that was locked down by itself on its own
network segment behind a firewall. On the bright side, if that machine
was infected then it could do no harm to any real data. On the downside,
once a single user gets infected the chances of that spreading to other
users of the same remote computer would be higher.

[David H. Lipman]

Post by David H. Lipman
The fact that you have an infected computer means you *must* re-examine

| your

Post by David H. Lipman
security model, run IA scans and mitigate vulknerabilities that may have
been used in this malware incident. The fact that this was a 2003 Server
and not a workstation OS also m,eans that the application and its usage
needs re-evaluation. Today it was this malware. You don't want it to be

| a

Post by David H. Lipman
really nasty malware infection one that may have rteal finacial and/or

| other

Post by David H. Lipman
costs like data exfiltration.
Some note...
1. Rethink your security model
2. Perform an IA scan on the systems and subsystems and mitigate all
vulnerabilities
3. Rethink your server application model for the affected user. (Ex.

| Switch

Post by David H. Lipman
use to Citrix)
4. Scan the computer with anti virus/anti malware software and computers
used in its electronic vicinity. My Multi-AV Scanning Tool mnay be of
assistance.

|
| When you say IA Scans, are you meaning to verify the presence of data
files?
| What tools would do this?

IA - Information Assurance
http://en.wikipedia.org/wiki/Information_assurance

|
|
| In terms of security model, how do you like to use Citrix or Terminal
| Server? I had toyed with the idea of having the individual's local
| computer be used just for local data access and have all browsing be
| consolidated to a remote computer that was locked down by itself on its
| own network segment behind a firewall. On the bright side, if that
| machine was infected then it could do no harm to any real data. On the
| downside, once a single user gets infected the chances of that spreading
| to other users of the same remote computer would be higher.
|

Citrix. While I haven't done it, my office mate (we shared an office with a
cipher lock) setup these type of services using virtual machines.

[Dustin]

Post by W
First, some Trojans also act like viruses and attempt to spread.
Some do not. Why is it important to this discussion?

It's only important from proper anaylsis, recovery and future
prevention. In your case tho, nothing. :)

Post by W
Second, no virus would have done the damage you describe because we
browse the Internet from ordinary Users accounts (unlike 90% of all
other user organizations where being "Administrator" all the time
seems to be a common practice) and because we further went to
extraordinary lengths to render Users unable to write to the vast
majority of the file system. For example, on all of our computers,
we prevent an ordinary user from being able to create a new file in
the Windows, System32, or Windows Temp folders. Shared file access
across user accounts on the same machine are through a carefully
controlled folder. Access to the SAM files and their backups is
explicitly denied, rendering brute force attacks on passwords
impossible.

You underestimate the ability for a virus to acquire sufficient rights
on a poorly secured system. Don't assume IP policy is perfect if the OS
has other problems, I have little doubt they do at this point.

Post by W
Third, there was nothing in the original post or its follow on that
would give you any basis for determining what the adequacy of our
security measures was or is. You shouldn't make stuff up just for
bravado.

When you mentioned using a server OS for a workstation, that was very
helpful in determining your competency as an administrator. Adding that
you allowed surfing on the server was only icing on the cake.

Post by W
I appreciate the utilities that were posted as those are enormously useful.

They're well known amongst many security/pc techie circles.

[W]

Post by Dustin

Post by W
Third, there was nothing in the original post or its follow on that
would give you any basis for determining what the adequacy of our
security measures was or is. You shouldn't make stuff up just for
bravado.

When you mentioned using a server OS for a workstation, that was very
helpful in determining your competency as an administrator. Adding that
you allowed surfing on the server was only icing on the cake.

An OS is an OS, and you do or do not secure it. Whether a given OS is
used as a personal workstation or not is a function of its assigned use, and
it is not a function of the other possible uses of the OS. The fact that
a Windows Server *could* be used as a server does not mean it *must* be used
as a server. If in fact only one user uses the server, functionally it
stops being a server and in terms of its role it performs like a
workstation.

Any argument starts from the Premise "Computer A is a Windows Server" and
ends with the conclusion "Therefore Computer A must be shared by a group of
people and perform in the role of a Server" is an invalid argument.

[Dustin]

Post by W

Post by Dustin

Post by W
Third, there was nothing in the original post or its follow on
that would give you any basis for determining what the adequacy of
our security measures was or is. You shouldn't make stuff up
just for bravado.

When you mentioned using a server OS for a workstation, that was
very helpful in determining your competency as an administrator.
Adding that you allowed surfing on the server was only icing on the
cake.

An OS is an OS, and you do or do not secure it. Whether a given OS
is used as a personal workstation or not is a function of its
assigned use, and it is not a function of the other possible uses of
the OS. The fact that a Windows Server *could* be used as a server
does not mean it *must* be used as a server. If in fact only one
user uses the server, functionally it stops being a server and in
terms of its role it performs like a workstation.

If that suits you, fine by me. :)

[Dustin]

Post by David H. Lipman

Post by W

Post by Peter Foldes
Crossposted from microsoft.public.windows.server.general

Post by W
We have our Windows 2003 servers fairly locked down by NTFS, and
when a user browses the Internet they are logged in as an
ordinary user with minimal access to the file system. So
imagine my horror to see that a virus was able to change every
single file and folder on the file system to be read-only and
hidden, apparently using the attributes for files that are
affected by the ATTRIB commandline command.
Is the ability to use ATTRIB controlled by NTFS permissions? Or
is this the Write Attributes permission in NTFS? Unfortunately
we probably did enable that because it was generating too many
false positive audit messages.
The command
attrib -h -r *.* /s /d
apparently does NOT affect all folders under the current folder.
Is there a command that can be used that would change every file
and folder from the current location and down all subtrees?
Is there any utility that would restore any critical system files
and folders to their original attributes?

A virus didn't hide files and folders, a System Fix trojan or other rogue malware did.
If I understand this post, a user was ALLOWED to browse the
Internet from the POC of the Win2003 Server. If that was the case
that was the mistake. Nobody, users or administrators should be
browsing on a server platform. This is disrepecting the role of the
server. A System Fix type trojan is bad enough but that kind of
behavioour (which should never be alloewd on a server) coold have
had more disaterous effects.

The Windows 2003 server in question is actually an individual's
personal workstation. He prefers to use Server for many reasons as
his workstation, and one of those reasons is the ability to come in
by Terminal Services without disrupting the console session.
To be honest, this malware would have done minimal damage had we
just not allowed the Users group to have Write Attributes
permissions on such a wide file system scope. We had allowed that
because so many applications give security error log messages after
attempting to change an attribute that it rendered logging very
cumbersome. We clearly didn't understand the implication of that
setting and now we do. So no user should have global Write
Attributes. Check. :)
Other than that, the virus was only able to change files and add new
files inside the user's profile folder. We simply deleted that
folder and had the user login fresh to create a new profile folder.
That at least contained the initial active part of the infection,
and we'll have to continue with other utilities later.

The first think to do is find and eliminate the System Fix type
trojan and then use Lawrence Abrams' (aka; Grinler) Unhide utility.
http://download.bleepingcomputer.com/grinler/unhide.exe
The Server may have to be booted in Safe Mode such that the trojan
isn't loaded. Note also do NOT dump TEMP folders prior to running
Unhide. Unhide may also be executed in Safe Mode.

All of those utilities look useful thanks.
I could not get the MS Standalone Sweeper to create a standalone CD.
It gives an error when trying to write the CD that has no error
code and simply indicates it cannot continue. Amazing that it
took MS 10 years to finally understand that to beat a virus
effectively you should boot from a dedicated uninfected OS, without
invoking the OS of system under test. Better late than never,
assuming I can ever get it to work.

This was not a case of a virus and if you are the administartor of
some system of systems which included this Windows 2003 server then
that explains the poor security and this trojan getting installed.
If this was a virus you and your comapny would have been up shits
creek becaus ethe virus would have infected other files and spread
beyond the borders of this one Windows 2003 server to other systems
on your network.

+1

[Ant]

Post by Peter Foldes
Crossposted from microsoft.public.windows.server.general

Post by W
The command
attrib -h -r *.* /s /d
apparently does NOT affect all folders under the current folder.

Yes it does.

Post by Peter Foldes

Post by W
Is there a command that can be used that would change every file and
folder from the current location and down all subtrees?

Yes, attrib, just as you show above works fine. Maybe it doesn't work
on your system because of the permissions you set (which the malware
bypassed or temporarily reset) or because the malware is still active
and preventing any change.

And as has been said, WTF are you doing browsing the internets from a
server?