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

"David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in message
news: ...
> From: "Peter Foldes" <>
>
> | Crossposted from microsoft.public.windows.server.general
> |
> | "W" <> wrote in message
> | news: ...
>>> 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.

--
W

From: "W" <>

> "David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in message news: ...
>> From: "Peter Foldes" <>
>>
>>> Crossposted from microsoft.public.windows.server.general
>>>
>>> "W" <> wrote in message
>>> news: ...
>>>> 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.

--
Dave
Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk
http://www.pctipp.ch/downloads/dl/35905.asp

"David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in message
news:...
> From: "W" <>
> > "David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in message
news: ...
> >> From: "Peter Foldes" <>
> >>
> >>> Crossposted from microsoft.public.windows.server.general
> >>>
> >>> "W" <> wrote in message
> >>> news: ...
> >>>> 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.

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.

--
W

From: "W" <>


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

If a malware autonmously spreads then its a virus and not a trojan. Trojans
need asssistance and that why they rely heavily on the Vulnerability/Exploit
vector and Social Engineering. What they may have in common is payload or
intent. However all symptoms of this malody are indicative of a of a System
Fix tyme of rogue that is a trojan. The point was if this had been a virus
as as you indicated "the virus was only able to change files and add new
files inside the user's profile folder" then you would have found that it
would have spread throughout your LAN causing even more headaches. It is
important in this discussion because when you cross the line from trojan to
virus you now have to go outside the scope of one affected computer you now
have to look at the the enittire LAN as a system that is infected and the
susb-systems that are affected. If this had been an AutoRun worm you would
have to also be looking at Flash Drives, USB Hard disks and other Read/Write
external media used by all your users. This is why the distiction is
important.


| 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.

Malicious Actors know this and find all sorts of locations within this
user's Profile read/write the malware and associated file so they done don't
have to reside within the OS.


| 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.

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.


--
Dave
Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk
http://www.pctipp.ch/downloads/dl/35905.asp

"David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in
news::

> From: "W" <>
>
>> "David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in message
>> news: ...
>>> From: "Peter Foldes" <>
>>>
>>>> Crossposted from microsoft.public.windows.server.general
>>>>
>>>> "W" <> wrote in message
>>>> news: ...
>>>>> 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


--
Character is doing the right thing when nobody's looking. There are too
many people who think that the only thing that's right is to get by, and
the only thing that's wrong is to get caught. - J.C. Watts

"W" <> wrote in
news: :


> 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.

> 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.

> 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.

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

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




--
Character is doing the right thing when nobody's looking. There are too
many people who think that the only thing that's right is to get by, and
the only thing that's wrong is to get caught. - J.C. Watts

"Dustin" <> wrote in message
news:Xns9FE2953CDB293HHI2948AJD832@no...
> > 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.

--
W

"W" <> wrote in
news: :

> "Dustin" <> wrote in message
> news:Xns9FE2953CDB293HHI2948AJD832@no...
>> > 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.



--
Character is doing the right thing when nobody's looking. There are too
many people who think that the only thing that's right is to get by, and
the only thing that's wrong is to get caught. - J.C. Watts