audiodg process ownership

[satyricon11 0]

So I am poking around with a VM of Windows 7 and Metasploit. After listing all running processes in meterpreter (as NT AUTHORITY/SYSTEM) I noticed that there was no owner for the audiodg.exe process. However, under the windows task manager on the local machine, I see that the processes is listed as a local service.

 

My questions are:

1) Who owns this process and what privileges does it have?

2) Why doesn't the owner show up when I list all running processes in meterpreter or any custom python script

3) Would this process have ring0 access since I can't kill it or migrate to it as NT AUTHORITY/SYSTEM

 

Based off of the reading I've done, my assumption is that since this .exe deals with drivers / driver signing there is a good possibility of ring0 access if I could migrate/exploit this process.

 

https://answers.microsoft.com/en-us/windows/forum/windows8_1-hardware/windows-audio-device-graph-isolation-audiodgexe/35337ea9-4fd2-4902-b05c-7aedbf78fe9f

Edited March 5, 2018 by satyricon11

[Jeruselem 661]

I think it's part of the sound driver system hence why it's a Windows service.

[Rybags 1,024]

A properly written driver (or any distributed program for that matter) would only have the level of access it requires to do it's work.

Driver signing is simply there for overall system security and integrity and the fact a driver is signed doesn't necessarily mean it gets superuser attributes.

 

Ownership... probably some system component. What runtime attributes would a sound driver/service component has? It might need to do cross-address space access, and need to hit the hardware directly.

 

Exploits? Well, the moment you change a single bit inside a signed module it turns it invalidates the signature.

[Jeruselem 661]

If you're hell bent on disabling driver signatures on Windows, you can even with Win10. But's not exactly a simple procedure.

[Master_Scythe 531]

Prcicely what Rybags said, to my knowledge it's a hook with no ownership.

It's shown as a 'friendly name' only for the kernels audio device driver.

 

If you did try to 'sploit it in any way, you will either hit driver signing alerts, or you'll need to unload the kernel to re initialise the changes.

[satyricon11 0]

Okay thanks guys. Yeah I went in and used msfvenom to add a backdoor to the .exe and to no surprise it didn't work. Would I experience the same outcome if I tampered with any of the .dll files that it uses?

[Master_Scythe 531]

Okay thanks guys. Yeah I went in and used msfvenom to add a backdoor to the .exe and to no surprise it didn't work. Would I experience the same outcome if I tampered with any of the .dll files that it uses?

 

That's quite likely. Mainly because DLL's are normally considered part of the driver package and are also signed.

HOWEVER, if you have a specific driver that CALLS a DLL under certain conditions (for example, the recent 'accidental' keylogger in the HP audio driver) then it might be considered an external program, not a driver and trigger.

 

I salute your quest for knowledge, but there's a reason you never hear about Driver Injection\exploits.

 

Loading an entirely false driver? Sure.

Compromised package? Yep, certainly.

 

Actually 'sploiting a driver or one of its subsystems?..... I actually can't think of an example of that happening since Windows98.

This is one of those rare things you'd probably have better luck with IOT\*Nix devices, because they DONT have to pay for expensive 'signing' by a parent company.

[Jeruselem 661]

Modern windows versions have self protection systems. Specific files get replaced with good copies in case they are corrupted.

[Master_Scythe 531]

Modern windows versions have self protection systems. Specific files get replaced with good copies in case they are corrupted.

 

Yeah but its pretty easy to get a list of whats monitored by SFC.

[satyricon11 0]

Good to know. Thanks guys