cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
737
Views
4
Helpful
9
Replies

CSA 5.2 and svchost.exe attempting to modify leventmgr.exe

cschear
Level 1
Level 1

I have approxmiately 160 CSA agents on (mainly) laptop clients. I receive a large number of email notifications stating the following each day:

---------------

Severity: Alert

The process 'C:\WINDOWS\system32\svchost.exe' (as user NT AUTHORITY\SYSTEM) attempted to modify a Cisco Security Agent resource Cisco process C:\Program Files\Cisco operation was denied.

---------------

I've no doubt it's benign activity because it is detected on freshly ghosted/patched machines shortly after CSA is installed and the laptop is given to a user. However, I haven't been able to get any good feedback from my users which might indicate what they were/their systems were doing at about the time these events were logged.

Does anyone have any insight into what Windows XP-based activity would result in so many of these svchost.exe events? I would appreciate any feedback.

Thanks.

9 Replies 9

chickman
Level 1
Level 1

This is benign activity indeed. The SVCHOST.exe isn't anything you should deny though. Possibly creating an exception to allow it to do its job would be ok. The following KB from microsoft can explain it far better than I can, but I'll try anyway. http://support.microsoft.com/kb/314056

The process is just grouping services that load @ startup and is used to manage them. The ONLY time I could be overly concerned with this is if the alert is coming from somewhere other than the system folder. Obviously, if the .exe was compromised and overwritten in the system folder you have other worries, like AV updates.

Anyway, your deny alert can exclude this by creating a application class with the variable such as this: @system\svchost.exe and placing it in the 'But not in any of the following selected classes:.'

Hope this helps.

I was going to create an exception to for the svchost.exe application class but the 5.2 r203 Agent UI Module with the applicable "Agent Service Control" rule complains, stating that when "The default application class selection (included:all, excluded:none) must be in place when 'disable the agent security' box is checked."

I can't create a rule JUST for svchost.exe, it requires I have and "" in the exclusions.

I know some cringe at the thought of editing the actual rule that fired, but I believe its an effective way of doing business.

My suggestion would be to edit that rule you have firing, and place the application class created in the 'do not' field.

Either that, or you use the wizard to create an exception. Take it for a spin and test both methods out. Just remember that pretty much everything is reversible.

> My suggestion would be to edit that rule you have firing, and place the application class created in the 'do not' field

I can't. With the "attempt to disable the agent security" checkbox feature checked, the "Agent Service Control" rule requires the rule be set for "All Applications" and "". Any other setting results in a failure that reads:

Error:

The default application class selection (included:all, excluded:none) must be in place when 'disable the agent security' box is checked.

I'm not going to UNCHECK the "attempt to disable agent security" just so I can add svchost.exe to the rule as a "not in the following class".

Hmm With the Agent UI rule set, you've only got so few selections. I've not seen this fire in relation to a NT AUTHORITY/SYSTEM before. Hopefully someone else will chime in with experience with this.

With regard to the svchost.exe, I've NEVER seen it try to stop the process, which is what you're saying its doing.

Also, I agree with not allowing the disabling of CSA. You wouldn't want to allow users or system services to disable the agent. Anyway

Another thing you could try is to set that actual UI module to a 'User State' YOURDOMAIN/* so that anyone logged in as well as */ADMINISTRATOR or whatever the local admin account you created is. That will basically say that anyone fitting those user states will have that rule applied to them. I'm only suggesting this because I've never seen the system normally try and stop CSA, I'll play around with trying to get the system to replicate what you're saying. I'm sure I'll only come up with the modify portion though. Let me know what you think.

r.bollman
Level 1
Level 1

Also...keep in mind, this does not necessarily mean svchost is trying to "shut" the process down. It simply states that is is attempting to access a resource used by the CSA process. This can happen if the user has an appliction that "Scans" the directory, such as backups.

Do you have any additional information in the 'details' screen?

Information contained in one of the 'details' is included below.

Description Deny disabling agent security or modifying local configuraiton

Action

Deny Deny

Module Agent UI Module [W, V5.2 r203]

? Event details:

Event Text The process 'C:\WINDOWS\system32\svchost.exe' (as user NT AUTHORITY\SYSTEM) attempted to modify a Cisco Security Agent resource Cisco process C:\Program Files\Cisco Systems\CSAgent\bin\leventmgr.exe. The operation was denied.

Event Time 5/20/2007 2:07:20 PM

Code ASVC_CONF_DENY

PInt 1733

PString C:\WINDOWS\system32\svchost.exe

PString2 Cisco process C:\Program Files\Cisco Systems\CSAgent\bin\leventmgr.exe

time 121.9 (seconds since boot)

type APICALL

ProcessId 1564

ApiOperation OpenProcess

Credentials os=win32,T=NT AUTHORITY\SYSTEM,t=010100000000000512000000,G=NT AUTHORITY\SYSTEM,g=010100000000000512000000

CallStack

(with symbol resolution) RPCRT4!I_RpcBCacheFree+0xd71

RPCRT4!I_RpcBCacheFree+0xc52

RPCRT4!I_RpcBindingCopy+0x67

RPCRT4!I_RpcBindingCopy+0x12c

RPCRT4!I_RpcTransGetThreadEvent+0xde7

RPCRT4!I_RpcTransGetThreadEvent+0xedc

RPCRT4!I_RpcTransGetThreadEvent+0xf58

RPCRT4!I_RpcTransGetThreadEvent+0x102b

RPCRT4!NdrGetTypeFlags+0x5a

RPCRT4!NdrGetTypeFlags+0x12e

RPCRT4!NdrGetTypeFlags+0x1c9

RPCRT4!NdrServerCall2+0x19

RPCRT4!NdrStubCall2+0x215

RPCRT4!CheckVerificationTrailer+0x75

rasmans!_RasmanEngine+0x15a

rasmans!ServiceRequest+0x114

rasmans!ServiceRequest+0x53fd

rasmans+0xbcab

rasmans+0xbc18

csauser+0x5a60

kernel32!OpenProcess+0x49

ntdll!NtOpenProcess+0xc

ntdll!KiFastSystemCall+0x9

ApiPInt1 1344

ApiPInt2 1

ApiPInt3 983104

FlattenedForm (t-1179688040 n-281250000 z--18000 sm-285 sc-13 dm-1 dc-7 cd-653 p*(i-1733 w-C:\WINDOWS\system32\svchost.exe w-Cisco%20process%20C:\Program%20Files\Cisco%20Systems\CSAgent\bin\leventmgr.exe r*(type-17 time-1219 pnd-83889275 rid-83889105 rapi*(pid-1564 op-22 p*(i-1344 i-1 i-983104 ) cr-Owin32%00TNT%20AUTHORITY\SYSTEM%00t010100000000000512000000%00GNT%20AUTHORITY\ SYSTEM%00g010100000000000512000000%00 cs-RPCRT4=41107f22,2,snfrtjNwK6BODODqJQRHZk6armLaaaaaYb3yYrhnUahzIba\rasmans=449a53e8, 2,snfrtzv-E63g5jyqVwGOIc9X9VzaaaaaYf2CTfMBZ5cCKjga\csauser=460ae11d,2,snfrtXXCSQPYqhwtyIESKtgEqVqfaaaaJnxy1nxzY5cCKjga\ kernel32=44ab7fd3,2,snfrtXfEOZlTxvKqMMwIRPwg5sLaaaaaRvMCUvgBZiJlWrMyaa\ntdll=41107f17, 2,snfrtv7xrzZqqtErrAVC67ck4bSaaaaaUrhzSXMlWrMyaa\\RPCRT4!I_RpcBCacheFree+0xd71\RPCRT4! I_RpcBCacheFree+0xc52\RPCRT4!I_RpcBindingCopy+0x67\RPCRT4!I_RpcBindingCopy+0x12c\ RPCRT4!I_RpcTransGetThreadEvent+0xde7\RPCRT4!I_RpcTransGetThreadEvent+0xedc\RPCRT4! I_RpcTransGetThreadEvent+0xf58\RPCRT4!I_RpcTransGetThreadEvent+0x102b\RPCRT4!NdrGetTypeFlags+ 0x5a\RPCRT4!NdrGetTypeFlags+0x12e\RPCRT4!NdrGetTypeFlags+0x1c9\RPCRT4!NdrServerCall2+ 0x19\RPCRT4!NdrStubCall2+0x215\RPCRT4!CheckVerificationTrailer+0x75\rasmans!_RasmanEngine+ 0x15a\rasmans!ServiceRequest+0x114\rasmans!ServiceRequest+0x53fd\rasmans+0xbcab\rasmans+ 0xbc18\csauser+0x5a60\kernel32!OpenProcess+0x49\ntdll!NtOpenProcess+0xc\ntdll!KiFastSystemCall+ 0x9 ) ) ) )

I have a TAC case open on this one. I've been told it is bug id: CSCsi58539. Waiting for hot-fix for this one.

I got these same messages whenever I disabled my wireless adapter while it was connected to the network.

Just a guess but I think if CSA loses it's ability to talk to the network it does some sort of system check to make sure the processes are still running.

I added SVCHOST and UHPclean to the exceptions list of the service control rule that allows virus scanners and installation applications to modify agent configuration and that stopped it.

I've only seen wireless laptops do it.

Tom

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: