Windows Privilege Escalation – Exploiting Autorun

Introduction

Windows allows users to set specific programs to automatically start whenever the system boots, the list of programs that have this functionality enabled is stored in the Windows Registry. Although this feature can be very handy if startup programs are setup with improper permissions it may allow attackers to escalate privileges, as these programs are executed in the context of the user who is logging in at that point in time.

Identifying Autorun Programs

The Autorun programs are usually stored in the Run or RunOnce registry keys, the following command can be used too query this key and identify any of them:

reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

The screenshot above shows how the “program.exe” application is stored in the Run registry, and therefore it will be executed when a user logs in, with the level of privilege of that user. A comprehensive list of the registry key that could store this information can be found here.

The next steps is to verify whether the current user has write access to the .exe file so that it can be replaced with a malicious one. Icacls or Accesschk can be used to identify the permissions of a specific folder or file:

icacls [directory/file]

Accesschk.exe -accepteula -wuqv [file]

Judging by the output from the commands above, it appears that everyone on the system has access to modify program.exe, so this confirms this Autorun program is indeed exploitable.

Automated enumeration scripts such as WinPEAS can also help identify weak Autorun programs. Additionally, the Sysinternals Autorunsc for Windows tool can also be used to do so:

Exploiting the Vulnerability

All that is left now is to replace the program.exe executable with a reverse shell, to gain administrative access to the machine and force the system to execute it.

The first step is to generate some shellcode using MSFvenom with the following flags:

• -p to specify the payload type, in this case, the Windows TCP reverse shell
• LHOST to specify the localhost IP address to connect to
• LPORT to specify the local port to connect to
• -f to specify the format for the shell, in this case, exe

Then moving to the folder where the program.exe file is stored and transferring shell.exe file to the Windows victim machine using the Python web server and the Windows Certutil utility, renaming it program.exe:

At this point, for the reverse shell to be executed the administrator user would have to login, or alternatively the system can be rebooted. Running the following command to find out whether the current user has permissions to do so:

whoami /priv

From the output of the command it looks like it does.

The next step is to set up a Netcat listener, which will catch the reverse shell when it is executed by the victim host, using the following flags:

• -l to listen for incoming connections
• -v for verbose output
• -n to skip the DNS lookup
• -p to specify the port to listen on

All that is left now is to issue the following command to reboot the system and wait for the reverse shell to be executed as soon as a user logs in:

Once the tcm administrator user has logged on, the malicious executable was executed, therefore granting a reverse shell as that user.

Conclusion

Although Autorun programs can be a great tool in Windows to help be more efficient, they should be configured carefully, only allowing administrator users to edit the actual executable or the registry key controlling the program’s path, as exploiting this misconfiguration could result in a full system compromise.