read winlogon.exe

[tomoz]

Why does sb want to read winlogon.exe and does it matter if this request is denied?

[tashi]

Hello.

Why does sb want to read winlogon.exe


Spybot-S&D scans for the Winlogon Hijacker, not the legitimate Windows Logon (winlogon.exe) process.

http://www.safer-networking.org/en/updatehistory/2004-09-30.html

2004-09-30
Hijacker
+ CleverIEHooker.Jeired + Winlogon ++ Winhlp


Did a scan show an infection?

[tomoz]

Tashi, this happens when I open SB not during the scan.

The scan does not show up any malware at all.:D

[tashi]

The scan does not show up any malware at all.:D
Good. :)

Why does sb want to read winlogon.exe

Could you explain in more detail please?

Thanks.

[tomoz]

Could you explain in more detail please?

I am using Process Guard to prevent from services being started on my pc without my knowledge or permission. The default setting for winlogon.exe is to prevent any program to read winlogon.exe. The reason being:
If winlogon.exe is protected from READ access then most methods used to disable Windows File Protection (WFP) will not work anymore. If WFP is disabled then system files can be replaced on your system, which could lead to the system being severly compromised.

It appears to me that Spybot attempts to read winlogon.exe each time I start it. When I deny the "read", the scan still works fine but I am unsure if some other "behind the scene" function of Sb may be negatively affected possibly causing later problems?

[LonnyRJones]

If you know what's cousing the alert, ie SpyBot why do you deny it ?
Guess i will have to intall Process Guard when time permits.

[tomoz]

If you know what's cousing the alert, ie SpyBot why do you deny it ?

In this case working from a new clean pc, I am not particularly worried. However in general many programs ask for all kinds of permissions that they do not necessarily need. From a security point of view, given blanket permissions even to "good" programs increases the risk as some nasty intruder may manage to infiltrate "good" progs.

As an analogy, you may give the keys to your house to a friend but he does not really need the combination to your safe:D

[md usa spybot fan]

tomoz:

Can you show us the message/dialog that you are getting?

I can find no indication that SpybotSD.exe is attempting to read winlogon.exe when it loads.

[tomoz]

Please see attached :confused:
Hope you can read it.

[bitman]

As I guessed, this is simply a case of SpybotSD.exe reading the Winlogin.exe file at startup, likely to determine whether it might have been replaced by malware in an attempt to compromise the system. In any case, a simple read of the file can't cause a problem and blocking it simply removes Spybot's ability to verify that the file is safe.

To echo Lonny's question, why would you deny Spybot? Your answer implies that any access by any program could allow malware to take root. However, what is really required is that the malware be given access itself, which in theory would display in ProcessGuard as a direct attempt by a malware executable to modify or delete a file.

A quick look at the ProcessGuard FAQ (http://www.diamondcs.com.au/processguard/index.php?page=faq) reinforces these same sentiments:


Why isn't Read access blocked by default?
Reading-based attacks are extremely rare so protection isn't often needed, but ProcessGuard provides the ability to protect against reading simply for completeness of it's feature set. Only advanced users who understand what they're doing should block Read access.


ProcessGuard is giving me alerts, is my system infected?
Not all alerts ProcessGuard shows are related to infections or malicious software. Some valid programs need certain privileges that ProcessGuard can restrict. It is up to you the user to know whether you trust a certain application. If you are unsure about the application then it would be best to leave ProcessGuard as it is, protecting you from whatever the application is doing. Otherwise if you know and trust the application then give it the privileges it desires.

In general, the best course of action is to allow all trusted applications whatever access they require, since you really have no criteria upon which to base the blocking of a trusted app. If, on the other hand, an unknown and unrequested application starts to execute, say when you are browsing a new web site, it might be appropriate to block the attempt at least until you are made aware of its purpose.

[tomoz]

Bitman,

I freely admit that I am not enough techy to understand the inner workings of PG or the registry. I am quite happy to leave things on default in general though I try to follow the advice to learn more.
The point you misunderstood though is that winlogon.exe is by default protected from reading. Your quote re read access must refer to other programs, but if you look at http://www.diamondcs.com.au/pgdb/index.php?whatis=winlogon.exe you will see that it does not normally refer to this file.

[bitman]

Let me make this simple; Don't block anything that an application you trust is attempting to do. If you do it is only likely to create a problem for you.

The key sections of the two ProcessGuard FAQ entries I posted are:

Only advanced users who understand what they're doing should block Read access.
Otherwise if you know and trust the application then give it the privileges it desires.
The most fundamental statement I can make is that using a security application you don't understand is as dangerous as not having one at all.