Trying to trace down user account that SVCHOST.exe is using

Question

I'm having an issue in my environment where nearly all of my windows 7 systems (vast majority of the infrastructure) are attempting to log in to an old disabled account. I know this is from a previous sysadmin that used this account for some service I just cant figure out where It's being set.

I know that the process is running under SVCHOST.exe, I'm reasonably certain that it's the process that is running the following other tasks.

AeLookpSvc
BITS
Browser
CertPropSvc
IKEEXT
iphlpsvc
LanmanServer
ProfSvc
Schedule
SENS
SessionEnv
ShellHWDetection
Themes
Winmgmt
wuauserv

I think it may be remnants of the old WUSS server but that server was retired and decommissioned so I can't look there. I don't know what sub-process/service under SVCHOST is attempting those credentials, the sec log is very vague. I've done a full search of the registry on affected machines as well as going through an rsop on the machine looking for any reference to that account but I can't find anything.

An account failed to log on.

Subject:
    Security ID:        SYSTEM
    Account Name:       [ComputerName]$
    Account Domain:     [Domain]
    Logon ID:       0x3e7

Logon Type:         2

Account For Which Logon Failed:
    Security ID:        NULL SID
    Account Name:       [UserAccount]
    Account Domain:     [Domain]

Failure Information:
    Failure Reason:     Account currently disabled.
    Status:         0xc000006e
    Sub Status:     0xc0000072

Process Information:
    Caller Process ID:  0x304
    Caller Process Name:    C:\Windows\System32\svchost.exe

Network Information:
    Workstation Name:   [ComputerName]
    Source Network Address: -
    Source Port:        -

Detailed Authentication Information:
    Logon Process:      Advapi  
    Authentication Package: Negotiate
    Transited Services: -
    Package Name (NTLM only):   -
    Key Length:     0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.
    - Transited services indicate which intermediate services have participated in this logon request.
    - Package name indicates which sub-protocol was used among the NTLM protocols.
    - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

Solution

None of those services would need to use explicit credentials. The "Schedule" service is the Task Scheduler. You can use the following command to check the scheduled tasks.

schtasks /query /XML > File.txt  

Then search File.txt for the account/principal.

Comments

[Travis Lange]

That's what I thought, that's why I'm having trouble hunting this down. I looked at the scheduled tasks before but just for the sake of being thorough I ran that command and searched again. it's not there. I added the security audit event that i'm seeing on almost all my clients to the original post

[Greg Askew]

Probably some other type of management application. Type 2 is interactive.

[Travis Lange]

Finally found it, you were right about it being a scheduled task. The reason I couldn't find it on the computer was because the logon failure was happening when group policy was trying to apply a scheduled task policy to the computer. Since the logon was invalid the policy was never applied thus nothing for me to find locally. I finally was able to correlate some logs between computers that showed me that a policy was failing at the exact time as the login failure. digging into that policy (one of our bigger single polices) I finally found the offending task and removed it. fingers crossed.