Persistence Aggressor Script
May 04, 2016
While recently working with Cobalt Strike, I noticed there was no automation regarding persistence and beacons. Once a victim machine is rebooted, any running beacons are lost and all that hard earned access is gone with it. Raphael Mudge (@armitagehacker), Cobalt Strike’s creator, has mentioned some persistence techniques on his blog in the past, but has not built any automation for it. I got tired of running my basic persistence by hand and hadn’t gotten a chance to play with extending Cobalt Strike yet, so I decided to write a script to do some basic persistence techniques using Cobalt Strike’s scripting engine, Aggressor.
Research
Before jumping into writing the script, I did some research on different Windows persistence techniques. I wanted to make sure whatever I wrote was relevant and useful. Additionally, this was my first taste of persistence techniques, so I had lots of learning to do. I took a look at Metasploit, PowerSploit, a ShmooCon talk, and the Autoruns utility.
Metasploit
I first checked out what persistence mechanisms Meterpreter had to offer. Its basic persistence techniques are located in “exploit/windows/local/persistence” within the msfconsole. I found the source code for this module on GitHub, it was called persistence.rb. It generates a Meterpreter executable, uploads it to the victim, and then adds a Run registry key to one of the following locations, depending on its privileges:
|
1 2 |
HKLM\Software\Microsoft\Windows\CurrentVersion\Run\ HKCU\Software\Microsoft\Windows\CurrentVersion\Run\ |
On logon, Window’s will check these registry locations and run whatever executables are found there. Executables listed in the HKLM hive will be ran upon any user logon, while executables listed in the HKCU hive will only be ran for the specific user.
PowerSploit
Next I decided to look at what mechanisms PowerSploit had to offer.
PowerSploit’s persistence mechanisms can be found on GitHub in its Persistence.psm1 file. It uses three different persistence techniques:
- Registry Keys
- Scheduled Tasks
- WMI Subscriptions
The registry key technique is the same technique as Meterpreter. The scheduled task technique uses “schtasks”, a built-in Windows task scheduler, to automatically launch an executable based on a variety of different parameters that can be found in its documentation. The WMI Subscription technique fires an executable when a system event meets a defined WQL query. WQL can be used to query a variety of system events, but most importantly it can query for system start-up. For more information about WMI persistence, and other ways to abuse WMI, check out Matt Graeber’s talk from BlackHat 2015: Abusing Windows Management Instrumentation (WMI) to Build a Persistent, Asynchronous, and Fileless Backdoor.
Wipe the Drive
The next bit of research I did was from a ShmooCon 2013 talk, entitled Wipe the Drive. I also found an Internet Storm Center diary by Mark Baggett (one of the presenters). I found the diary to be the easiest way to digest the talk’s content. This talk focuses on a variety of advanced persistence techniques. A lot of them fall out of scope of my Aggressor automation due to their complexity. (I like to walk before I run! 🙂 ) However, the talk’s content was still extremely informative and interesting. You never know when you might need to bust out one of these fancy tricks!
My favorite was the Service Triggers based on Event Tracing for Windows (ETW). Mark Baggett mentions a technique where an attacker installs a malicious service and then creates an ETW event to launch their service when a particular SSID is seen. The attacker then can remotely trigger their persistence by broadcasting their SSID within range of their compromised hosts.
Unnecessary? Maybe.
Awesome? No doubt.
Autoruns
Last but not least, we have Autoruns for Windows. As defined by its documentation, “This utility, which has the most comprehensive knowledge of auto-starting locations of any startup monitor, shows you what programs are configured to run during system bootup or login.” This utility will detect a majority of the techniques mentioned above, specifically the techniques designed to run on startup or logon. However, the alternative-trigger based techniques might not show up here. I assume that this utility was created so that system administrators could get a better understanding of what is automatically ran on their systems. However, if you flip your evil bit on, you can use this utility as a means to enumerate all the little corners of stuff that Windows automatically runs on startup and/or logon. An attacker could use this information to find new places to drop executables and/or DLLs. Additionally, an attacker might even be able to “debug” the utility and figure out ways to not show up in a scan. I took these different methods into consideration.
The Script
Through my research I found a variety of different persistence techniques. Some of them are simple and easy to detect, while others being are sophisticated and stealthy. I decided that the best thing to do was match the status-quo of persistence automation by matching the capabilities of Meterpreter and PowerSploit.
My script automates 3 different techniques:
- Registry Keys
- Scheduled Tasks
- WMI Subscriptions
The script’s payload is based off of Cobalt Strikes’ PowerShell Web Drive-By. Each persistence technique or method is built to execute a .bat script that runs a PowerShell one-liner to stage and execute a beacon. This .bat script is dropped in one of the following locations, depending on the beacons privileges:
|
1 2 |
C:\Users\Public C:\Windows\System32 |
The script automatically generates this .bat payload by pulling the PowerShell Web Drive-By’s information out of Cobalt Strike’s data model and then uploads it to the victim. Lastly it configures the victim to execute this .bat script based upon the chosen persistence method.
I added functionality for custom naming, as seen by <payload / taskname>. This argument determines what the .bat script is named when dropped on the filesystem, as well as any specific naming needs in a given persistence technique. For example, if specified, it will determine the name of a schedule task or WMI filter respectively. This is important because it can aid in efforts to masquerade and hide from defenders.
The script can be found on my GitHub.
I’m very pleased with how my script turned out; it has saved me a lot of time. However, there is always room to grow. Here is a list of to-dos I hope to add if time allows:
- Provide in-registry persistence, rather than just .bat script.
- Have functionality to check / verify persistence installation.
- Add more advanced techniques.
This was my first dive into the world of persistence and it was lots of fun!
Thanks for reading!