Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to www.eventid.net. The EventId.Net for Splunk Add-on assumes that Splunk is collecting information from Windows servers and workstation via the Splunk Universal Forwarder.
|Type: Success Audit|
Privileged Service Called:
Server: NT Local Security Authority / Authentication Service
Primary User Name: <computer name>$
Primary Domain: <domain or workgroup name>
Primary Logon ID: (0x0,0x3E7)
Client User Name: <computer name>$
Client Domain: <domain or workgroup name>
Client Logon ID: (0x0,0x3E7)
Privileges: <privilege string>
|English: This information is only available to subscribers. An example of English, please!|
|Concepts to understand:|
What is the LSA?
What is an authentication protocol?
|Our approach: This information is only available to subscribers. An example of Our approach|
T784501 provides a description of the "audit privilege use" concept.
According to ME831905, this problem may occur when all the following conditions are true:
- A program that is installed on your Windows XP-based computer makes a call to the SetProcessWorkingSetSize function to release the working set.
- Auditing of the Audit privilege use category is turned on.
- Your user account does not have the SeIncreaseBasePriorityPrivilege user right, also known as "Increase Scheduling Priority."
If these conditions are true, a program call to the SetProcessWorkingSetSize function to release the working set triggers audit event 577. The program call also triggers a second call to a function that requires the SeIncreaseBasePriorityPrivilege user right. This second call is unnecessary. When the SetProcessWorkingSetSize function triggers the second call, a false audit event 577 is logged to the security event log.
If this is recorded when McAfee Agent 4.5 is installed, see EV100292 (Event ID 577 displayed on client after installing McAfee Agent 4.5). The event may be ignored.
This event record indicates that an attempt has been made to use a privilege to perform a privileged system service.
If the operation is successful, this event is recorded as "Success Audit" if not it is recorded as "Failure Audit". Depending on you Audit Policy these type of events may or may not show up. If you receive quite a few of "Success Audit" 577 events than most probably you have "Audit privilege use" enable for both cases. There are many normal processes that use their privileges so naturally the events gets recorded.
This event can also be logged when you used Winmsd and save a report (see ME811196).
As per ME238185, when you are using a Remote Procedure Call-based (RPC-based) client/server program, this error may be recorded (in this case, it does not indicate a security breach; you can safely ignore it).
Privileges: See ME101366 for a list of privileges strings and what they mean. common ones:
- SeIncreaseBasePriorityPrivilege = Increase Scheduling Priority = The user can boost the scheduling priority of a process.
- SeTcbPrivilege = To Act as Part of the Operating System = The user can act as a trusted part of the operating system. Some subsystems have this privilege granted to them.
This can happen if an application tries to increase it's scheduling priority on the CPU. Most users do not have the permission to do this, so the application will fail it's attempt and log this in the security log. We got this to go away by giving the users the "Increase Scheduling Priority" right in the local security policy. So far, no ill affects and the event log has gone away.
|Private comment: Subscribers only. See example of private comment|
|Links: Online Analysis of Security Event Log|
|Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (0) - More links...|
Send comments or solutions
- Notify me when updated