-Get-VulnSchTask renamed to Get-ModifiableScheduledTaskFile
-Get-VulnAutoRun renamed Get-RegistryAutoRun
-Get-RegAutoLogon renamed Get-RegistryAutoLogon
-Find-DLLHijack renamed to Find-ProcessDLLHijack for clarification, code cleaned up, -Process parameter added, output object detail expanded, and help expanded
-Removed most of the code from Find-PathHijack, replacing it with Get-ModifiablePath
-Cleaned up logic for Write-HijackDll
-Expanded help for the registry enumeration cmdlets
-Added local user creation options to Write-HijackDll to match Write-ServiceBinary
-Increased pause between user creation commands
-Fixed parameter sets for Write-ServiceBinary and added -Credential and -Service params
-Simplified/corrected logic for Install-ServiceBinary
-Fixed parameter sets and simplified logic for Restore-ServiceBinary
-Added sanity check with Get-ModifiableFile for Install-ServiceBinary
-Cleaned up lingering spaces
-Renamed Get-ServiceFilePermission to Get-ModifiableServiceFile
-Renamed Get-ServicePermission Get-ModifiableService
-Integrated PSReflect codebase from @mattifestation
-Modified Get-ModifiableFile to enumerate the ACLs for passed file paths, returning the path/permission set/identityreference for each modifable file (instead of opening file for modification)
-Added Add-ServiceDacl from @mattifestation to add service Dacls to Get-Service objects
-Added Set-ServiceBinPath replace "sc.exe config SERVICE binPath= X" - now modifies using the ChangeServiceConfig Win32 API call
-Revamped Test-ServiceDaclPermission to take advantage of Add-ServiceDacl. Service permissions are now matched up against the current user's group memberships and specified permission sets to check for.
-Functions that checked for service restarting now use Test-ServiceDaclPermission
-Get-ModifiableService now uses Test-ServiceDaclPermission
-Invoke-ServiceAbuse completely rebuilt to use native PowerShell functions and Set-ServiceBinPath to reconfiguring service binary paths for abuse
-Parameter sets rewritten for several functions to accept -Credential objects were applicable and -Service objects from Get-Service on the pipeline
TODO: Tune up Write-ServiceBinary, Install-ServiceBinary, Restore-ServiceBinary, Find-DLLHijack, Find-PathHijack, Write-HijackDll, and all the registry checks
Paths containing environment variables can cause false-positives to occur, e.g. `%SystemRoot%\system32\WindowsPowerShell\v1.0\`. `Find-PathHijack` will believe this is a relative path and will report it as hijackable if the current directory is writeable.
The 'Install-ServiceBinary' function fails on an edge case where the
service's file permission does not include the 'Modify' permission but
does include the 'Write' permission
(https://technet.microsoft.com/en-au/library/dd349321(v=ws.10).aspx). In
this scenario, renaming the original service file for backup purposes
will result in 'Access Denied' message. Fixing this requires that the
file be copied to service.exe.bak instead of renamed to service.exe.bak.
Pester tests to the function 'Test-ServiceDaclPermission' were added in
order to increase confidence in its reliability. In general, my
intention was to replace the current functionality of the service
management functions such as Invoke-ServiceStart, to not use blindly
'sc.exe start' but rather consult with the DACL permissions and base the
decision on that. Unforunately, further investigation lead me to the
conclusion that retrieval of the service's DACL permissions requires
that an additional DACL permission (RC) be set. This may lead to an edge
case that could miss a potential privilege escalation condition and
thereby the original idea was discarded. Nonetheless,
'Test-ServiceDaclPermission' can be used for less critical tasks.
Therefore, a 'CanRestart' property was added to the output of the
service enumeration functions such as 'Get-ServiceUnquoted' as I think
that it will add value to redteamers/pentesters by helping them
prioritise which service should be abused for escalation of privileges.
Services that can be restarted by a low privileged user will probably be
prioritised first. Additionally, manual checking whether the vulnerable
service can be restarted would not be required in most cases.
Harmj0y