Justin Warner provides an argument on his blog that is important to summarize before continuing a discussion about persistence:
Is Reboot Persistence a Requirement
I would argue that a backdoor does not have to be reboot persistent.
In its very nature, a backdoor is simply a method of gaining access to
some targeted resource. Backdoors often have a persistent component
but I would say that is a decision best left to the context and
scenario of what you are trying to accomplish. In very simple network
scenarios or penetration tests that have little focus from network
defenders, run-of-the-mill persistence might be applicable and useful.
Things like run keys, service executables, or App Init DLLs come in
quite handy for this situation.
In more sophisticated or tough network environments, I often try to
operate 95% memory only and only resort to reboot persistence in areas
that seem to be key-terrain. This might be more paranoid than
necessary but by doing this, I help to avoid issues with host based
IDS and prevent leaving artifacts on the hosts. In the places I choose
to do reboot persistence, I prefer methods that do not utilize a file
on disk such as registry storage of payloads.
Let's take real-world attacks such as the Kovter malware as an example of the tradecraft possible in 2016 -- https://blog.malwarebytes.com/threat-analysis/2016/07/untangling-kovter/
Thanks to the techniques employed by Kovter, no executable needs to be
dropped on the disk – that’s why is known as “fileless” [...]
scattered into several layers, but also obfuscated at every stage and
containing tricks that slow down the analysis process
Kovter uses a combination of persistent registry entries and PowerShell (others often use or suggest remote registry, PS Remoting, and/or WMI event consumers) to perform this fileless persistence. Some blogs have talked at length about autostart persistence locations based on these, services, autoruns, et al.
In meterpreter, one can access fileless techniques (as described by Justin Warner's blog post at the top of this answer) via PowerShell's PowerPick and ReflectivePick techniques, which don't require execution (or visible process listing) of any powershell.exe. Darkoperator covers the powershell extension and ability to use the powershell_import
command to pull in a PowerShell pipeline. One can then use the PowerSploit persistence capabilities, but these may not always be clearly-defined. Of course, instead of meterpreter, one could use PowerShellEmpire agents to deliver the persistence/elevated/wmi module. What I'm suggesting, and which will likely solve your problem directly, is to just source Persistence.psm1 to perform the WMI permanent event subscription via powershell_import
while inside meterpreter. This will provide the AV, IPS, and firewall/UTM bypasses you'll need -- but it may be easy to cleanup if the responders search for multiple instances of this one technique.
Which brings me to the next conversation piece that Justin Warner alludes to. Each machine you want to persist against in a network should have a different persistence technique (some perhaps no strategy at all -- e.g., servers with high uptime can have memory-resident backdoors for months, maybe years at a time). Often, you can use the system-administration infrastructure against the target -- leveraging it for evil instead of good, so to speak. There are ways to take control of COM handlers, WSUS, AD GPO, BITSadmin, DSC, SCCM, and many other packages and features to maintain persistence.
Also -- system persistence may be completely different than reliable transports. I highly suggest that you check out the Meterpreter documentation:
- https://github.com/rapid7/metasploit-framework/wiki/Meterpreter-Reliable-Network-Communication
- https://github.com/rapid7/metasploit-framework/wiki/Meterpreter-Transport-Control
You must understand the transport
architecture in order to maintain reliable network connectivity. One of the best ways to ensure network reliability that the above does not cover, however, is to combine transport
with Metasploit AutoRunScript -- such as covered in the this other answer in order to get AutoRunScript working in the context of meterpreter. mubix covers transports more in detail in this metasploit minute from Hak5.