search

itm4n / PrivescCheck

Privilege Escalation Enumeration Script for Windows
BSD 3-Clause "New" or "Revised" License
2.79k stars 416 forks source link

Cannot find process with ID for UDP Endpoints #39

Closed exploide closed 1 year ago

exploide commented 1 year ago

During the run of Invoke-UdpEndpointsCheck the following error occurs. The message is German but it means "Cannot find process with ID xyz".

+------+------------------------------------------------+------+
| TEST | NETWORK > UDP Endpoints                        | INFO |
+------+------------------------------------------------+------+
| DESC | List all UDP ports that are in a LISTEN state. For    |
|      | each one, the corresponding process is also returned. |
|      | DNS is filtered out to minimize the output.           |
+------+-------------------------------------------------------+
Get-Process : Es kann kein Prozess mit der Prozess-ID 55184 gefunden werden.
In Zeile:514 Zeichen:86
+ ... oteProperty" -Name "Name" -Value (Get-Process -PID $ProcessId).Proces ...
+                                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (55184:Int32) [Get-Process], ProcessCommandException
    + FullyQualifiedErrorId : NoProcessFoundForGivenId,Microsoft.PowerShell.Commands.GetProcessCommand

So I assume either we have no privileges looking up the process, or the processes are so short living that they are gone when the process info is retrieved. However, listing TCP services works and it is always reproducible on this particular machine, so I'm a bit confused. Maybe this exception can be handled and the process name can be left empty in this case?

itm4n commented 1 year ago

Hello,

Thank you for reporting this issue.

I doubt this is a matter of privileges as Get-Process can be invoked even on protected processes for instance. A race condition between the time the ports are enumerated and the time the process is queried is possible but unlikely, especially as you are able to reproduce the issue reliably.

The behavior you are observing could be caused by a forking mechanism. The process that created the socket no longer exists, I don't know.

Whatever the reason, you are right, the script is missing some error handling. I will see how I can fix this.

Thanks again! :)

itm4n commented 1 year ago

Problem fixed, I simply added -ErrorAction SilentlyContinue to ignore errors in case the process associated to the TCP/UDP endpoint no longer exists.

Get-Process -PID $ProcessId -ErrorAction SilentlyContinue