I ran some tests and I found this:
I went digging in the Windows Security log for this event, and the description includes this:
New Process ID: 0x110c
New Process Name: C:\Windows\System32\dllhost.exe
Token Elevation Type: TokenElevationTypeDefault (1)
Creator Process ID: 0x350
Token Elevation Type indicates the type of token that was assigned to the new process in accordance with User Account Control policy.
Type 1 is a full token with no privileges removed or groups disabled. A full token is only used if User Account Control is disabled or if the user is the built-in Administrator account or a service account.
Type 2 is an elevated token with no privileges removed or groups disabled. An elevated token is used when User Account Control is enabled and the user chooses to start the program using Run as administrator. An elevated token is also used when an application is configured to always require administrative privilege or to always require maximum privilege, and the user is a member of the Administrators group.
Type 3 is a limited token with administrative privileges removed and administrative groups disabled. The limited token is used when User Account Control is enabled, the application does not require administrative privilege, and the user does not choose to start the program using Run as administrator.
It doesn't appear this is a domain level event, though, so I'm not sure this would be logged anywhere but the local system.
Thanks for the response, curtisi. That would be a great way to capture the events if we had agents on our workstations, which unfortunately, we don't.
At some point, the process of elevating privileges through the Run As Administrator feature would have to authenticate to the domain controllers, no? I must be missing something because I cannot find a logged event of this authentication anywhere on our DCs. We're running 2008 AD environment and are using Advanced Audit Policy settings as follows:
Logon-Logoff IPsec Extended Mode No Auditing Logon-Logoff Network Policy Server No Auditing Logon-Logoff IPsec Main Mode No Auditing Logon-Logoff Logoff Success Logon-Logoff Other Logon/Logoff Events No Auditing Logon-Logoff Special Logon Success Logon-Logoff Logon Success and Failure Logon-Logoff Account Lockout No Auditing Logon-Logoff IPsec Quick Mode No Auditing Account Logon Kerberos Service Ticket Operations No Auditing Account Logon Other Account Logon Events No Auditing Account Logon Credential Validation Success and Failure Account Logon Kerberos Authentication Service No Auditing
We tried setting Logon-Logoff > Special Logon to Success & Failure but that didn't help. Anyone else have any experience with capturing these events? Any suggestions? Thanks a lot!
1 of 1 people found this helpful
IIRC, it won't auth against the domain controllers, because the privilege escalation is attempted locally. When a 'run as administrator' request is generated, windows checks to see if the user is in the local administrator group, or a group which is by default granted administrator rights (such as Domain Admins). This doesn't have to go out to a domain controller, since the escalation would be done locally.
I guess I should have specified that in our case, the Run As Administrator attempts are being initiated with different credentials (same domain) than the currently logged on user. So this answer makes sense in some cases, but when specifying different user credentials, the current authentication token wouldn't be valid so the process would have to go back to the DC to validate the new credentials, right?
I'm afraid my environment isn't setup to let me make that work. Maybe you can do some "Run As..." tasks and then go into the console and run an nDepth search for AnyAlert from DetectionIP from your machine for the last 10 minutes, and also against your DCs for 10 minutes and see if you can identify the event that we could correlate off of?