Set-ExecutionPolicy Bypass -Scope CurrentUser

When using an unquoted service path, Windows will attempt to start every name of a file before a space as SYSTEM user. As an example, C:\\Program Files\A Subfolder\Service.exe is vulnerable to C:\\Program.exe, then C:\\Program Files\A.exe, then will actually run the intended service. A reverse shell created with SYSTEM permissions using this vulnerability is extremely dangerous. This vulnerability can be mitigated using a PowerShell script (like this one) to put quotes around all unquoted service paths.

Sources: Windows Privilege Escalation — Part 1 (Unquoted Service Path)

For some reason, Windows has two registry values in HKCU\Software\Policies\Microsoft\Windows\Installer and HKLM\[same path as before] called AlwaysInstallElevated that when set to 1, cause any Windows Installer package to install with SYSTEM privileges. This can be abused by installing a Windows Installer package that adds a privileged account or reverse shell. It can be remediated by turning the setting off in both registry keys, either manually or with a script.

Sources: What is AlwaysInstallElevated?, AlwaysInstallElevated

Weak service permissions allow a user account to easily modify the configuration of a service. A service with weak permissions could have its binary path changed to a malicious one, which would mean that binary would likely run with SYSTEM privileges. This can be prevented with proper configuration of service permissions.

Sources: Weak Service Permissions

Any service created has a registry key specifically for it that Windows uses as the backend for service information. If that key has weak permissions like a user with Full Control over the key, the user account will be able to modify the service and, for example, replace its binary. The binary can be replaced with whatever the threat actor would like to run with SYSTEM privileges, including adding a privileged account or a reverse shell. This can be mitigated by ensuring services have the proper permissions for users.

Sources: Weak Registry Permissions

Windows will look to load the DLLs for an executable in a standard order, starting with the directory that the executable exists in. Therefore, if an executable requires a DLL in C:\\Windows, and a malicious DLL with the same name is in the same directory as the executable, the malicious DLL will be loaded instead. This malicious DLL can spawn whatever the threat actor would like, including a reverse shell at the permission level of the executable that was started. This vulnerability can be checked for by ensuring proper permissions on the folders executable pull DLLs from.

Sources: DLL Hijacking Techniques

A service with a missing binary can have a malicious binary injected into its binary path. The binary can instead be whatever the threat actor would like to run with SYSTEM privileges, including adding a privileged account or a reverse shell. This can be mitigated by ensuring services always have the correct binary path, and users don't have write access to the binary folder.

Sources: Weak Service Binary Permissions

Windows will look for executables in the command prompt and PowerShell according to the PATH environment variable order. If a malicious and writable path is early in the PATH order, Windows will check that location for executables before others. This allows threat actors to place malicious executables in the writable path, that will be run before real ones (IE a fake ping.exe will be run before the actual ping). This can be mitigated by ensuring only needed paths are in the PATH variable, and that write access to those paths is heavily restricted.

Sources: Windows - Privilege Escalation

When a user logs into Windows, it will automatically start any programs in C:\Users\%USERNAME%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup and C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup as the user who just logged in. If those folders are writable, then a malicious executable can be injected into those folders, which will run on the machine's next login. This vulnerability can be mitigated by restricting write access to startup folders, and by monitoring them for malicious shortcuts, executables, and batch scripts.

Sources: Startup Applications – Windows Privilege Escalation

unattend.xml is used in mass Windows deployments to create accounts, join a domain, add a product key, and more. Sometimes these files are not deleted, and contain plaintext or base64-encoded credentials. If a high-permission account (like an Administrator) is left with plaintext credentials exposed, that privileged account may be able to be accessed by a threat actor.

Sources: Unattended Install Files

Scheduled tasks are vulnerable to the same unquoted path vulnerability as services (where spaces between characters will cause files to be unintentionally executed). Therefore, they can be exploited the same way: by placing a malicious and maliciously named executable in the path of the scheduled task. However, their remediation and mitigation is different. This vulnerability can be mitigated by checking for unquoted paths in scheduled tasks, and adding quotes around them to make sure they target the correct binary.

Sources: Unquoted paths. They’re not just for services anymore.

Video Link