Re: Virus? - Disable .EXE, .COM, .LNK and group policy.

From: cquirke (MVP Windows shell/user) (cquirkenews_at_nospam.mvps.org)
Date: 05/27/05 

Date: Fri, 27 May 2005 10:27:49 +0200

On Wed, 25 May 2005 11:12:01 -0700, Malke wrote:
>Brian Hoyt wrote:

>> We are a private school with all students 7-12 having laptops/tablets
>> about 450. The students own the machines so I can't lock them
>> down as much as one would like.

>> There is no need to punish the students as they aren't in most cases
>> purposely causing the problems.

>See, we disagree here. Maybe your students are more responsible, being
>older. Our students *are* at fault because they will download all kinds
>of cr*p if allowed.

You can blame them for breaking policy, but not for getting malware'd,
as the relationship between these is Venn. Good system setup and
choosing apps that suck less will make it less Venn, but it will only
approach inclusion, i.e. where all malware infections are within the
set of those who break policy.

If you want to be a model of good cause and consequence, as is usually
an objective of educational institutions, then your objectives are:
  - monitoring and enforcing policy
  - penalties for policy breaches
  - reducing malware infection
  - reduced impact of cleanup

Malware works by exploiting the difference between what the user
wanted to do, and what actually happens. The more the system acts
ahead of user intent, the more malware infections will occur for which
the user cannot be blamed at all.

Only if a system displays full risk info in a form the user can
understand, and never acts beyond the displayed risk, can you talk
meaningfully about user responsibility. Then you can equate malware
infection with bad user behavior and proceed with punitive cleanup.

Current system design as it is, the latter scenario can only be
approached, not attained. So I still see punitive clean-up has
unfair; then again, much of real life is unfair, too.

>What I meant by isolating is that we have three networks, all of which
>are kept isolated from each other - one for the school office, one for
>the computer lab, and one for the classrooms/laptop program.

If you can enclose a network, you can cure it. If you cannot close a
network, you're only doing palliative de-bulking operations.

I'd hope that your staff and backbone networks are closed, which means
you need to air-gap these from the students, as well as the Internet.

A LAN that includes WiFi is not a fully enclosed network, unless you
bring a great deal of resources and expertise to bear on the problem,
and maintain the same level of hands-on management going forward.

>> I was trying to figure exactly what this one was, since it is far more
>> damaging than any other we have had. It is affecting a very small
>> group of students some repeatedly though. I was hoping if I could
>>narrow the cause I could help the students to know what not to do.

There are various scenarios here:
  - persistance of infection (never was cleaned)
  - self-re-infection (hidden malware stores; SR, email etc.)
  - peer re-infection (e.g. from other infected PCs on LAN)
  - external re-infection via a persistent entrance opening
  - external re-infection via a persistent entrance wound
  - actively re-asserted infection from an outside "watcher"
  - deliberate re-infection from a malicious inside user

Assume your mugshot scanners cannot find the malware, either because
it's new, or it's an under-exposed custom hacking tool, or it's
legitware that is being maliciously deployed. What then?
  - non-editorialized enumeration / scrutiny (HJT, ShellExView, etc.)
  - check perimeter; settings, patches, fences you thought were up
  - move things around to break assumptions held off-system
  - reduce the size of the eye of the needle
  - watch traffic

If you have F&PS bound to TCP/IP and admin shares exposing all HD
volumes from the root up, then there's scope to "reduce the size of
the eye of the needle" through which malware can pass :-)

On "entrance wounds", bear in mind that the evil malware may do, may
live on after it's died. Malware cleaners either ignore settings
changes made by the malware, or restore these to duhfaults. Both can
leave you with gaping entrance wounds.

For example, a client of mine had RBot.J (SDBot.J). Most write-ups
mention infection via hidden admin shares, "wweak passwords" etc. My
take: If all that stands between you and the Internet is a password,
and you have no intention of ever facilitating the kind of access the
password "protects" against, the system setup fundamentally sucks.

One write-up of SDBot family mentions it disables these admin shares,
even though it uses them to enter the system. So there's a risk that
a cleaner will re-enable these shares, to undo the malware-initiated
change. Sure enough, my usual protective killing of these admin
shares was missing on the client's PC, and that may explain why the
infection kept recurring on ISDN dial-up.

Hence "check settings, patches, fences you thought were up".

>Without seeing the machines and what is running, there just isn't any
>way to tell what is going on. There was a big outbreak of an AIM virus
>recently, but it really was a nasty one and you'd certainly have
>noticed it. What might work to help you track down the cause is to get
>one of the infected machines and run HijackThis on it. Then post your
>HJT log at one of the forums below (not here, please). I particularly
>like the AumHa forum, but all of the fora linked below are populated by
>great experts who will be able to pinpoint things for you right away.
>So here are the HJT links:

>http://www.aumha.org/a/hjttutor.htm - HijackThis tutorial by Jim
>Eshelman
>http://www.bleepingcomputer.com/forums/index.php?showtutorial=42 -
>another tutorial
>http://aumha.net - forums
>http://spywarewarrior.com/viewforum.php?f=5 - Spyware Warrior HijackThis
>forum
>http://www.wilderssecurity.com/
>http://forums.tomcoyote.org/
>http://www.spywareinfo.com/forums/

I have to ask: How inclusive is HJT, and how root-kittable is it?

I think we know the answer to the latter, but I'm wondering about the
former. I don't see anything like the detail that ShellExView
displays, so I consider that as an essential adjunct to HJT.

>---------- ----- ---- --- -- - - - -
   Gone to bloggery: http://cquirke.blogspot.com
>---------- ----- ---- --- -- - - - -

Relevant Pages

  • Re: Infected with something - need some hekp please
    ... is/was/are my malware shields. ... Download and execute HiJack This! ... The previous rebuild was initiated by significant system upgrade - more memory, more disk (two now, two more in the ... not due to infection. ...
    (microsoft.public.security.virus)
  • Re: Infected with something - need some hekp please
    ... is/was/are my malware shields. ... Download and execute HiJack This! ... The previous rebuild was initiated by significant system upgrade - more memory, more disk (two now, two more in the ... not due to infection. ...
    (microsoft.public.security.virus)
  • Re: IE Malware / Spyware Control Methods
    ... > infection and/or removel of an infection by ... Having dealt with a great many spyware infections, ... > tough part of this is that such malware has multiple ... > and renames system files like msconfig to resist ...
    (Incidents)
  • Re: Calling on a Guru to explain if Im mistaken!
    ... installing SP2 off the disc is part of the ... However I have tried antivirus software in the past and it was ... malware would also be copied back resulting in net gain of zero. ... will increase the risks of infection. ...
    (microsoft.public.security.virus)
  • Re: Admin Shares blocked on XP Pro
    ... deliberately kill admin shares. ... Windows Registry Editor Version 5.00 ... there's at least one malware that enters through admin shares ... pushing out a setting to kill admin shares, ...
    (microsoft.public.windowsxp.configuration_manage)