Recently I was playing around with a service which was running under a full virtual service account rather than LOCAL SERVICE or NETWORK SERVICE, but it had SeImpersonatePrivilege removed. Looking for a solution I recalled that Andrea Pierini had posted a blog about using virtual service accounts, so I thought I'd look there for inspiration. One thing which was interesting is that he mentioned that a technique abusing the task scheduler found by Clément Labro, which worked for LS or NS, didn't work when using virtual service accounts. I thought I should investigate it further, out of curiosity, and in the process I found an sneaky technique you can use for other purposes.
I've already blogged about the task scheduler's use of service accounts. Specifically in a previous blog post I discussed how you could get the TrustedInstaller group by running a scheduled task using the service SID. As the service SID is the same name as used when you are using a virtual service account it's clear that the problem lies in the way in this functionality is implemented and that it's likely distinct from how LS or NS token's are created.
The core process creation code for the task scheduler in Windows 10 is actually in the Unified Background Process Manager (UBPM) DLL, rather than in the task scheduler itself. A quick look at that DLL we find the following code:
HANDLE UbpmpTokenGetNonInteractiveToken(PSID PrincipalSid) {
// ...
if (UbpmUtilsIsServiceSid(PrinicpalSid)) {
return UbpmpTokenGetServiceAccountToken(PrinicpalSid);
}
if (EqualSid(PrinicpalSid, kNetworkService)) {
Domain = L"NT AUTHORITY";
User = L"NetworkService";
} else if (EqualSid(PrinicpalSid, kLocalService)) {
Domain = L"NT AUTHORITY";
User = L"LocalService";
}
HANDLE Token;
if (LogonUserExExW(User, Domain, Password,
LOGON32_LOGON_SERVICE,
LOGON32_PROVIDER_DEFAULT, &Token)) {
return Token;
}
// ...
}
This UbpmpTokenGetNonInteractiveToken function is taking the principal SID from the task registration or passed to RunEx and determining what it represents to get back the token. It checks if the SID is a service SID, by which is means the NT SERVICE\NAME SID we used in the previous blog post. If it is it calls a separate function, UbpmpTokenGetServiceAccountToken to get the service token.
Otherwise if the SID is NS or LS then it specifies the well know names for those SIDs and called LogonUserExEx with the LOGON32_LOGON_SERVICE type. The UbpmpTokenGetServiceAccountToken function does the following:
TOKEN UbpmpTokenGetServiceAccountToken(PSID PrincipalSid) {
LPCWSTR Name = UbpmUtilsGetAccountNamesFromSid(PrincipalSid);
SC_HANDLE scm = OpenSCManager(NULL, NULL, SC_MANAGER_CONNECT);
SC_HANDLE service = OpenService(scm, Name, SERVICE_ALL_ACCESS);
HANDLE Token;
GetServiceProcessToken(g_ScheduleServiceHandle, service, &Token);
return Token;
}
This function gets the name from the service SID, which is the name of the service itself and opens it for all access rights (SERVICE_ALL_ACCESS). If that succeeds then it passes the service handle to an undocumented SCM API, GetServiceProcessToken, which returns the token for the service. Looking at the implementation in SCM this basically uses the exact same code as it would use for creating the token for starting the service.
This is why there's a distinction between LS/NS and a virtual service account using Clément's technique. If you use LS/NS the task scheduler gets a fresh token from the LSA with no regards to how the service is configured. Therefore the new token has SeImpersonatePrivilege (or what ever else is allowed). However for a virtual service account the service asks the SCM for the service's token, as the SCM knows about what restrictions are in place it honours things like privileges or the SID type. Therefore the returned token will be stripped of SeImpersonatePrivilege again even though it'll technically be a different token to the currently running service.
Why does the task scheduler need some undocumented function to get the service token? As I mentioned in a previous blog post about virtual accounts only the SCM (well technically the first process to claim it's the SCM) is allowed to authenticate a token with a virtual service account. This seems kind of pointless if you ask me as you already need SeTcbPrivilege to create the service token, but it is what it is.
Okay, so now we know why Clément's technique doesn't get you back any privileges. You might now be asking, so what? Well one interesting behavior came from looking at how the task scheduler determines if you're allowed to specify a service SID as a principal. In my blog post of creating a task running as TrustedInstaller I implied it needed administrator access, which is sort of true and sort of not. Let's see the function the task scheduler uses to determine if the caller's allowed to run a task as a specified principal.
BOOL IsPrincipalAllowed(User& principal) {
RpcAutoImpersonate::RpcAutoImpersonate();
User caller;
User::FromImpersonationToken(&caller);
RpcRevertToSelf();
if (tsched::IsUserAdmin(caller) ||
caller.IsLocalSystem(caller)) {
return TRUE;
}
if (principal == caller) {
return TRUE;
}
if (principal.IsServiceSid()) {
LPCWSTR Name = principal.GetAccount();
RpcAutoImpersonate::RpcAutoImpersonate();
SC_HANDLE scm = OpenSCManager(NULL, NULL, SC_MANAGER_CONNECT);
SC_HANDLE service = OpenService(scm, Name, SERVICE_ALL_ACCESS);
RpcRevertToSelf();
if (service) {
return TRUE;
}
}
return FALSE;
}
The IsPrincipalAllowed function first checks if the caller is an administrator or SYSTEM. If it is then any principal is allowed (again not completely true, but good enough). Next it checks if the principal's user SID matches the one we're setting. This is what would allow NS/LS or a virtual service account to specify a task running as their own user account.
Finally, if the principal is a service SID, then it tries to open the service for full access while impersonating the caller. If that succeeds it allows the service SID to be used as a principal. This behaviour is interesting as it allows for a sneaky way to abuse badly configured services.
It's a well known check for privilege escalation that you enumerate all local services and see if any of them grant a normal user privileged access rights, mainly SERVICE_CHANGE_CONFIG. This is enough to hijack the service and get arbitrary code running as the service account. A common trick is to change the executable path and restart the service, but this isn't great for a few different reasons.
- Changing the executable path could easily be noticed.
- You probably want to fix the path back again afterwards, which is just a pain.
- If the service is currently running you'll need stop the service, then restart the modified service to get the code execution.
