Logon Triggered Persistence
Some actions performed by a user might also be bound to executing specific payloads for persistence.
Windows operating systems present several ways to link payloads with particular interactions.
Startup folder
Each user has a folder under
C:\Users\<your_username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startupwhere you can put executables to be run whenever the user logs in.If we want to force all users to run a payload while logging in, we can use the folder under
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUpin the same way.
We will then copy our payload into the victim machine. You can spawn an
http.serverwithPython3and usewgeton the victim machine to pull your file:
Now be sure to sign out of your session from the start menu (closing the RDP window is not enough as it leaves your session open):
Run / RunOnce
You can also force a user to execute a program on logon via the registry. Instead of delivering your payload into a specific directory, you can use the following registry entries to specify applications to run at logon:
The registry entries under
HKCUwill only apply to the current user, and those underHKLMwill apply to everyone. Any program specified under theRunkeys will run every time the user logs on. Programs specified under theRunOncekeys will only be executed a single time.
After transferring it to the victim machine, let's move it to C:\Windows:
Let's then create a REG_EXPAND_SZ registry entry under HKLM\Software\Microsoft\Windows\CurrentVersion\Run. The entry's name can be anything you like, and the value will be the command we want to execute.
After doing this, sign out of your current session and log in again, and you should receive a shell (it will probably take around 10-20 seconds).
Winlogon
Another alternative to automatically start programs on logon is abusing
Winlogon, the Windows component that loads your user profile right after authentication (amongst other things).Winlogonuses some registry keys underHKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\that could be interesting to gain persistence:Userinitpoints touserinit.exe, which is in charge of restoring your user profile preferences.shellpoints to the system's shell, which is usuallyexplorer.exe.
If we'd replace any of the executables with some reverse shell, we would break the logon sequence, which isn't desired.
Interestingly, you can append commands separated by a comma, and
Winlogonwill process them all.Let's start by creating a shell:
We'll transfer the shell to our victim machine as we did previously. We can then copy the shell to any directory we like. In this case, we will use
C:\Windows:
We then alter either
shellorUserinitinHKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\. In this case we will useUserinit, but the procedure withshellis the same.
After doing this, sign out of your current session and log in again, and you should receive a shell (it will probably take around 10 seconds).
Logon scripts
One of the things userinit.exe does while loading your user profile is to check for an environment variable called
UserInitMprLogonScript. We can use this environment variable to assign a logon script to a user that will get run when logging into the machine. The variable isn't set by default, so we can just create it and assign any script we like.Notice that each user has its own environment variables; therefore, you will need to backdoor each separately.
Let's first create a reverse shell to use for this technique:
We'll transfer the shell to our victim machine as we did previously. We can then copy the shell to any directory we like. In this case, we will use
C:\Windows:
To create an environment variable for a user, you can go to its HKCU\Environment in the registry. We will use the UserInitMprLogonScript entry to point to our payload so it gets loaded when the users logs in:
Shortcut Files
If we don't want to alter the executable, we can always tamper with the shortcut file itself. Instead of pointing directly to the expected executable, we can change it to point to a script that will run a backdoor and then execute the usual program normally.
For this task, let's check the shortcut to calc on the Administrator's desktop. If we right-click it and go to properties, we'll see where it is pointing:
Before hijacking the shortcut's target, let's create a simple Powershell script in
C:\Windows\System32or any other sneaky location. The script will execute a reverse shell and then run calc.exe from the original location on the shortcut's properties:
Finally, we'll change the shortcut to point to our script.
Notice that the shortcut's icon might be automatically adjusted while doing so. Be sure to point the icon back to the original executable so that no visible changes appear to the user.
We also want to run our script on a hidden window, for which we'll add the
-windowstyle hiddenoption to Powershell. The final target of the shortcut would be:
Let's start an nc listener to receive our reverse shell on our attacker's machine:
If you double-click the shortcut, you should get a connection back to your attacker's machine.
Meanwhile, the user will get a calculator just as expected by them. You will probably notice a command prompt flashing up and disappearing immediately on your screen.
Last updated
Was this helpful?
