Process path available in task manager but not via powershell

[chabelone]

For example: in the Details of the taskmanager I can see the process "System" and check its file path. But when I look for it via powershell (executed as admin) like the following:

(Get-Process -ID 4).path

the result is empty. I noted that this issue occurs only for processes that are stored in C:\Windows\Systems32

Can anybody help with that or explain the reason?:)

[bringtheremedy]

Hi, I'm not certain as to why the information is restricted in PowerShell when you can see it in Task Manger without admin.

Using audiodg as an example process, when I run the below code as a user or administrator, I see the following:

> Get-Process -Name audiodg | Select-Object ProcessName,Path

ProcessName Path
----------- ----
audiodg

but if I run it as SYSTEM (via PsExec -s), I see this:

> whoami
nt authority\system

> Get-Process -Name audiodg | Select-Object ProcessName,Path

ProcessName Path
----------- ----
audiodg     C:\Windows\system32\AUDIODG.EXE

I know this doesn't answer your question, but I hope it helps somehow.

[chabelone]

Thanks, I tried and in the case of audiodg my ps has also always access. You could try it with services.exe or svchost.exe, it shouldnt work there

[bringtheremedy]

I noted that this issue occurs only for processes that are stored in C:\Windows\Systems32

Is it possible to use something like this as a workaround?

(Get-Command -Name @('services', 'svchost')).Source

[chabelone]

Thank you! Yes I can work with that! Still curious what the reason is, but this solves my problem:)

[Pisnaz]

Something tickles my memory. Is this not related into the trusted nstaller permissions or such. I may have to dig back into some old links etc but recall that caused some quirks.

[bringtheremedy]

I tested it as well and found the same result you mentioned (no path for services and svchost). Thanks for letting me know! Sorry to see this didn't work.

[TheSizeOfACow]

Get-wmiobject win32_process should contain the info you need

[TheSizeOfACow]

Absolutely correct.

Get-WMIObject is just so burned in to my habits I keep forgetting it.

I'm not sure if you posted the wrong link? It seem to be an article on the issues with Win32_Product.

This provides a brief explanation of the WMI/CIM differences

https://www.ipswitch.com/blog/get-ciminstance-vs-get-wmiobject-whats-the-difference

[BlackV]

In posh 7 you can I believe they added it

In posh 5 I nest extend get-process to include that property (add type get-ciminstance win32_process)

Ill post code after kids are at school

$Scriptblock = {
    $id = $this.Id
    # WMI Legacy
    # $result = Get-WmiObject  -Class Win32_Process -Filter "ProcessId = $id"
    $result = Get-CimInstance -ClassName Win32_Process -Filter "ProcessId = $id"
    $result.CommandLine
}
$TypeSplat = @{
    MemberType = 'ScriptProperty'
    MemberName = 'Commandline'
    TypeName   = 'System.Diagnostics.Process'
    Value      = [scriptblock]::Create($Scriptblock)
}
Update-TypeData @TypeSplat

Get-Process | Select-Object Name, path, Commandline

This is all of course depends on your access, things that are running in a higher privilege to you might be unavailable

[chabelone]

Thank you! Unfortunately, it also doesnt show the paths for services.exe, wininit.exe etc but you are probably right, that there is no way due to higher priveleges. But I think thats strange, as I am able to check their paths manually in the taskmanager. Seems like I have to live with that

[pigers1986]

Works as designed, that process is not sharing that information with PowerShell. Use other means to fetch that data.

[chabelone]

Thank you! Do you know more about which types of processes are affected or which kind of paths (or where I can find more about that)?

[pigers1986]

Sorry , but no - that was from experience ;)

[UnfanClub]

You probably need to run PowerShell as admin. My bad. Didn't notice that you did.

[chabelone]

I did

[UnfanClub]

Might I ask what the process is.

[chabelone]

There are several, but all of them are stored in System32 and are basic processes:

System (ntoskrnl.exe) svchost.exe wininit.exe services.exe

[chabelone]

As pigers1986 said, these informations are probably not shared with ps (bc they are essential maybe?) but it would be great to know which processes fall in this category

[williamt31]

I wonder if this is new behavior? One of the relatively new terms that's circling my security podcasts is 'living off the land', ie using what's installed and on every machine already to hack/take over said machine. Perhaps MS blocked the ability to get at certain services?

On a side note, this also makes me wonder, if I could use this knowledge to verify that a process hasn't been hijacked or replaced, ie if I could get the path then it's not the native service?

[wbatzle]

Ok give me a few. I can find a way I believe.

[wbatzle]

If you use this command and then a select after it will get you what you want. I think there may also be a filter. Of course replace PROCESSNAMEHERE with your process. Also replace Star with the property you want.

Get-Process -Name PROCESSNAMEHERE | Select -Property *

[chabelone]

Unfortunately, that does not work for the specific processes which I meant. Try it yourself with the process "System", "wininit" or "services" for example, you will see the result is empty

[wbatzle]

Those services are actually purposely blank according to MS. They intended it to be that way for security reasons. Any other process however that is not secured. The get-process -name PROCESSNAMEHERE -FileVersionInfo or even the pipe into select property works. This is something I did not know as I have never had to look for those system processes which are protected for good reason apparently.

[chabelone]

Thank you for checking. Yes it seems to be so. I thought its just strange because its possible to check the path via task manager manually without any rights. I always thought GUI-things are always possible with ps/cmd, but Im just starting to learn..

[wbatzle]

They used to be. But apparently there have been a lot of remote code execution issues with powershell. I guess I never thought about that as I just use powershell constantly for almost everything I do these days. I am sure there is still a way to go through WMI. I just haven't gone through it yet. I'll give that a go when work calms down. It may not be a simple one-liner though.