Find-PathDLLHijack returned false positive results

[whiskyfrenzy]

[*] Checking %PATH% for potentially hijackable DLL locations...

ModifiablePath : C:\Users\user1\AppData\Local\Microsoft\WindowsApps IdentityReference : domain1\user1 Permissions : {WriteOwner, Delete, WriteAttributes, Synchronize...} %PATH% : C:\Users\user1\AppData\Local\Microsoft\WindowsApps AbuseFunction : Write-HijackDll -DllPath 'C:\Users\user1\AppData\Local\Microsoft\WindowsApps\wlbsctrl.dll'

Above results came back from running the Invoke-AllChecks function but the modifiable path was only the user that was logged in as. Not really hijackable if the user can only hijack his own DLL file.

Proposing additional checks like the following: 1) Attempt to create a new file under directories from the %PATH% system environment variable 2) Check if the directory is for the current user

[scaery]

Stumbled up on this too but being afraid to report this as an issue.

It really seems to be a false positive which leads to wrong conclusions. Can anyone validate this to be threatend as a real security issue? Especially no service with system rights will ever use this path variable. Honestly, this folder exists on every Windows 10 Build. Simply echo %PATH%.

Will this be really hijackable on a users context to privilege to NT/System/Admin? This would only work if a user could trick an admin to install a service that uses the users own modifiable "\AppData\Local\Microsoft\WindowsApps" path, right? Therefore this will never be true in the Enterprise, or? Not even if you will find missing system DLLs with Procmon, because applications will never run as admin on a users context in this PATH environment. Am I right with this?

[yotabytes]

Find-PathHijackDLL uses Get-Item Env:Path. Env:Path returns the current path, which includes both the SYSTEM path and the USER path entries, as seen in the GUI. Updating PowerUp to use [System.Environment]::GetEnvironmentVariable('PATH','Machine') instead of Env:Path would select only the SYSTEM path and remove these false positives.

Locations on the user path are eventually traversed by the operating system when attempting to locate a missing DLL, so they are potential candidates for hijacking. However, user environment variables for the current user will never be set in the environment of SYSTEM, Administrator, or any other user for that matter. Thus, when a path in the user path is writable, this could only be exploited by services that use the... current user privileges, which is moot.

[floyd-fuh]

+1