Metasploit Meterpreter alternatives

Bypassing AV and IPS can be done through meterpreter or any other RAT. Most of the time meterpreter is handy because first it is open source and second it is implemented as a reflective DLL which insert itself in the exploited process without touching the disk.

AV solutions can be bypassed easily through the Veil Evasion project while reverse_https meterpreter can bypass the IPS since the connection is encrypted. You have the option of Stage Encoding for encoding the second stage metsrv.dll as well which can bypass a lot of IPS solutions. Also, the stageless meterpreter over HTTPS is very handy in bypassing the host and network based detection solutions as well.

However, sometimes meterpreter being a synchronous payload where the user needs to interact with the session becomes difficult to manage e.g. when client side attacks or campaigns need to be executed over large periods of time. In such cases, you always have the option of using Throwback, Pupy, or the Cobalt Strike's Beacon payload. The advantage of these payloads is that they are asynchronous in nature and all of them are implemented as reflective DLLs which means they can be used with Metasploit through the payload/windows/dllinject/ payload type. And since these payloads are not used as often as the plain meterpreter in the Metasploit source tree, they can bypass many AV and IPS solutions out of the box.

Lately, the payloads implemented in pure Powershell can bypass AV as well as IDS/IPS. Powershell Empire is one such payload implemented in pure Powershell.

One thing that was missing from Meterpreter is to script the actions in the first stage without contacting the handler. Such a thing is now in the main source with Python meterpreter, and in the coming days, the functionality will be ported to other meterpreter payload types as well. Take a look at my answer at Techniques for Anti Virus evasion for a list of techniques for bypassing AV for further explanation on the topic.

PowerShellEmpire and Slingshot are the two primary considerations for implants going into 2016. However, you can get these implants easily caught by intrusion detection, advanced antivirus engines, and threat hunting practices if you don't understand the techniques.

Meterpreter and Cobalt Strike Beacon also have their place. An interesting backdoor I came across the other day called slarpd (from the zarp project) is a local-network-only remote shell because it works over ARP. Cobalt Strike has been suggesting additional low-and-slow, near-invisible network shells over SMB named pipes.

Meterpreter, Beacon, Slingshot, and Empire all suggest, if using an HTTPS covert channel, to first utilize Wininet instead of WinHTTP. Meterpreter also requires a lot of heavy configuration for network covert channels -- but the good news is that this wiki page called Paranoid Mode contains most of the information you'll need to configure it properly -- so as to avoid detection.

The concept of beaconing (which all of these implants do very loudly today -- this will likely change in 2016) is a huge issue to overcome, as is getting caught through hunting activities. Empire implements this best in its Listener setup and config. Empire has settings for DefaultDelay, DefaultLostLimit, KillDate, WorkingHours, and a unique anti-beaconing DefaultJitter setting (not that most of these settings aren't incredibly efficient and unique). Metepreter only has SessionCommunicationTimeout and SessionExpirationTimeout -- and only over HTTPS.

Empire will also prevent the operator(s) from making critical mistakes with a message, "Module is not opsec-safe, still run?". However, depending on how Empire is initially delivered, the agent may still get detected in a variety of ways. The best way to deliver Empire is through a browser (e.g., Win7/IE8/Java6 ms13_055_canchor) or Flash exploit (e.g., flash exploits such as found in the Operation Clandestine Wolf campaign repurposed as adobe_flash_nellymoser_bof -- or even the Hacking Team's UAF in the opaqueBackground property and another in ByteArray objects repurposed as adobe_flash_hacking_team_uaf). In method described by @void_in above (and in my comment), powershell.exe (or the Empire agent) is never started as a process, but merely injected into the same memoryspace as the browser (and then, via psinject, to whichever other processes you desire). Delivery via Microsoft Office (or Adobe Reader PDF) exploit or macro is the second-best alternative. Delivery via an executable, whether via a USB flash drive, SMBRelayX, Stuxnet-style WebDAV, shared folder, etc is one of the most-easily caught. If the target knows about PowerShell's offensive capabilities (e.g., is running CrowdStrike or similar), you can bet that any powershell.exe -- whether browser-delivered (e.g., hta_powershell in BeEF) -- or via command-line trickery such as any non-DLL stager from Empire, Cobalt Strike's PowerShell Web Delivery, metasploit-framework's DryRun of pexec_psh, and similar are not going to work in these modern, protected infrastructures. You'll get caught.

Often, it will be best to build a custom covert channel and/or C2 depending on the target network's characteristics. ARP or SMB named pipes seem great (even with their restrictions), but will they stand out too much at the wrong time? meterssh or cheetz/c2 are likely great candidates for heavy SSH and HTTP trafficked environments respectively, but they too may be caught. Low-and-slow techniques are proving to be less valid -- and if your exfiltration path (if that is the goal or implant requirement, i.e., to steal data) doesn't sufficiently match the logging rate of the defense, then you may have already lost. Perhaps IPv6 or other network obfuscations will help (e.g., SniffJoke) but perhaps also not. I'm personally attached to finding a beachhead that can send properly-configured TLS through Tor (to protect the exit node analysis) or even to a controlled Tor node, but I also enjoy the FASHIONCLEFT, Ncovert, and covert_tcp approaches. Perhaps a combination of all of the above?

What modules do you intend to run? Running any and every Meterpreter and Mimikatz routine, uploading files, timestomping, et al -- these are clear-and-present indicators of compromise. Surprisingly, clearing event logs isn't as much as you would think, but in my opinion, it's also best to leave them alone. In most environments, Meterpreter routines are very easily caught although it does have some wins I'll identify in the next paragraph. Empire has the bulk of them -- you can run situational_awareness/host/winenum and situational_awareness/host/paranoia followed by collection/netripper and very-targeted use of collection/ninjacopy. I might suggest that you avoid gaining privs with credentials/powerdump as this can be more noisy than you'd like -- even ninjacopy technically accesses the disk (but it does it differently). collection/inveigh (i.e., Responder.py implemented in PowerShell) is a great module -- staying persistent in networks for 2016 does not mean that you should actually run any persistent OS hooks (e.g., Autoruns, Services, Scheduled Tasks), but rather know as much about every machine and credential on the network. collection/minidump should also be used with care -- it's probably best to lab all of these up and apply all of the defensive technology (e.g., AV, network-based IPS, and HIPS) and hunting techniques (e.g., Powershell logging, Sysmon events) before going production with your implants.

There are a lot of fun techniques that can be delivered via Metepreter that cannot be done with Empire -- useful in CCDC's and similar events. For example, I don't know of a way to disable the mouse and keyboard with Empire, but in Metepreter it's a simple uictl disable keyboard|mouse. It is possible to replicate my favorite Meterpreter module, run lockout_keylogger, but Empire would need to moduleize or stage Lock-Workstation and PowerSploit's Get-Keystrokes into a one-shot. Metepreter has run windows_autologin for certain scenarios and PowerUp includes a Get-RegAutoLogon function. Empire does have situational_awareness/host/getcomputerdetails, which I believe definitely needs to be incorporated into a metasploit-framework post module. A lot of Metepreter actions will not work with modern Windows OSes, and changing the registry entries that would allow their use is likely to be monitored very heavily. For example, many SMB modules -- and the incognito modules in particular -- will not run if LocalAccountTokenFilterPolicy in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System exists and is set to 0. Setting it to 1 may throw off the alarm bells. If UseLogonCredential in HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest exists or is set to 1 then you'll have to load Mimikatz as a kernel driver (N.B, check out the last header section entitled "Passwords" in this blog post, towards the bottom of the post), but if you are targeting Win10 or Server 2012 then you may run into the dreaded RunAsPPL=1 in HKLM\SYSTEM\CurrentControlSet\Control\Lsa -- which will prevent a lot of credential dumping on these platforms (and older ones, even 8.1 -- but the others backport to Vista/7). Most Metasploit post modules do not stay only in-memory, and shelling out to commands will likely be logged and acted upon. Find the Metepreter modules that do stay in-memory only, and if you find the need or desire to run a standard Windows command, use, e.g., execute -H -m -d calc.exe -f c:\\Windows\\System32\\whoami.exe -a "/all" where the -m flag makes it run from the current process memory and -d makes it appear as a new process in the process list with a fake name (but also hidden with -H, see more here). sysinfo, getuid, use -l, ps, steal_token, getpid, transport, run win_privs, wifi_list, run enum_logged_on_users -c (N.B., running without -c touches disk!), window_enum -u, and clipboard_get_data are some of my favorite in-memory Meterpreter commands. I do like some that touch disk, such as run enum_shares, and run usb_history, but use them sparingly (primarily because these will lead to interesting pivot opportunities). You probably don't want to use run scraper, run winenum, run enum_cred_store, run enum_unattend, and especially not run checkvm, run getcountermeasure, run killav, run bypassuac_injection, getsystem, run hostsedit, or run persistence -- as I believe these hit the disk and AV catches them. Touching the domain from Meterpreter is also getting flagged a lot (N.B., almost all of the classic Meterpreter scripts you've relied on over the years are going away in favor of metasploit-framework post modules! Don't use most of these, favoring newer modules that replace them) -- certainly jumping to Empire's situational_awareness/network modules would be better (and they implement better techniques). It's good to have choices and I believe that both Empire and Meterpreter implants are solid to mix-and match as you see fit. In some situations it makes sense to run both!

Speaking of persistence, Empire also provides very interesting perspectives. These techniques are not in Metepreter. The persistence/misc/disable_machine_acct_change is nice, but the persistence/powerbreach modules are the true challengers. There were many fun Metasploit-style competition modules and techniques built over time, some replicated in Empire's trollsploit hierarchy. Preventing machines from allowing any access from its administrators is downright cruel in a competition, but confusing the blue teams (i.e., allow them both local and network logins but keep them busy troubleshooting why things don't otherwise work) during a cyber exercise or red team engagement can really press their patience, giving them a lot of lessons learned. I keep a variety of techniques under my belt, such as permanently deleting gpupdate and secedit with an immutable DisableGPO registry entry set to 1. If the target network supports it, the red team can continue to administer the network through the little-known DSC feature instead of GPO anyways. The Mimikatz kernel techniques (N.B., see this video starting at 44:23 until the end of the prezo, especially on slides 54 and 56) are also quite fun and should be repurposed to prevent defenders from targeting a single, powerful, offensive tool. Higher-layer targets such as Microsoft IIS and Azure (Get-Webconfig and Get-ApplicationHost come to mind), middle-tier components such as those found in Empire's recon/find_fruit module, and less-understood ones such as Mesos, Google Compute Engine, OpenStack, OpenShift, Cloud Foundry, LXC, Xen, Docker, CoreOS, and EC2/AWS make great future, long-term targets.

In summary, Meterpreter might be detected by AV/HIPS (such as the one mentioned by the questioner), so I suggest avoiding canned techniques found in the metasploit-framework (e.g., stageless and/or encoders) and even in the Veil-Evasion framework. Stick with the only known-good technique mentioned by @void_in above. It involves an exploit that relies on memory corruption. For these types of exploits (browser, Flash, MS Office, Adobe Reader, potential remote Service, etc), @void_in's technique (which involves using a metasploit-framework exploit and Veil-Evasion framework staged Meterpreter listener-less payload -- probably preferred to be a reverse_https payload with all of the Paranoid Mode configurations set -- also requiring an Empire listener and the Empire launcher.dll stager), which relies on ReflectiveDLLInjection is great not only for that reason, but also because it leverages the techniques from UnmanagedPowerShell to use a .NET runspace instance to build a stream of pipeline objects that are PowerShell, but do not require a separate powershell.exe instance to be run (and therefore are not logged or instrumented by standard PowerShell-detecting behaviors -- PowerShell does not even have to be installed, although .NET does). It's a big mixed ball of a metasploit-framework job (the exploit module), the dropped PowerShellEmpire launcher.dll stager, the combined Veil-Evasion payload and Empire stager using Meterpreter Paranoid Mode configuration for reverse_https shells, and the Empire listener.

You could also use this technique in a dropper (i.e., standalone executable) but AV/HIPS would get a chance to scan it first -- looking for any anomalies -- some of which might even be those ReflectiveDLLInjection or .NET runspace techniques. Instead, for droppers, my current favorite is TheShellterProject Stealth Mode -- especially because infecting a known-good PE file with one or more (Empire plus Metepreter, anyone?) payloads is exactly what I'm looking for. When using a macro from MS Office, I suggest using this sort of dropper (as it will be scanned by AV/HIPS). I also suggest reading The AntiVirus Hacker's Handbook for tons of detail on specific AV/HIPS targets, as well as many long-term techniques. The author appears to like custom C/C++ unpacked, unobfuscated payloads (PE -- or, better, DLL -- or funnier, an installer) built with the most-recent version of Visual Studio using Microsoft-friendly programming style -- the classic hide-in-plain sight angle. If you are comfortable with Meterpreter over Empire, I still suggest that you try PowerShellEmpire, as well as Slingshot (same people from SilentBreakSec also did Throwback) and Cobalt Strike Beacon.

I'm scared to chime in on this thread given that the existing answers are already so good! But I'm going to give it a go anyway, and come from a slightly different angle, and that is adapting and modifying Meterpreter itself to get around the problems. I'll begin by pulling your question apart a little.

Now I can bypass Anti-Virus and Firewalls easily, but Symantec Sonar and IPS always detect Meterpreter payloads and block the attacker IP.

I happily use a Meterpreter session over HTTPS on targets that make use of SEP's SONAR (among others). These kinds of protections are part of a game of "cat and mouse", just like you are. It takes a small amount of research to discover paths that SONAR doesn't catch. In some cases, bypassing the likes of SONAR can be as simple as using reverse_https and making sure that your Metasploit listener has a valid SSL certificate. I usually have a cloud-based attack server which has port 443 open with Nginx listening on it configured to use a valid SSL certificate. I proxy requests from Nginx through to MSF where appropriate. From there, most of my SEP-related issues seem to disappear. Give it a go! I'd be keen to hear how that pans out. Also, don't be scared to put a bit of time into finding out exactly what it is that's getting caught. This leads me to ...

Is there any better payload than Meterpreter that can bypass IPS?

We should probably be clear on what "payload" actually means here. If you're running an MSF-generated staged Meterpreter executable, then the executable contains nothing but a PE stub and a stager. This will get caught by lots of AV/etc. As already mentioned, encoding these can get you past the basics. A bit part of the problem here, though, is that when the binary is run, the first thing that happens is that a connection is made to an external entity, and a DLL (called metsrv) is sent down the wire. If reverse_tcp, bind_tcp or reverse_http are used here, the file is sent in the clear, and hence it is very easy to fingerprint on the wire. This will result in the likes of SEP picking up on the session. There are ways to bypass this, including using stageless payloads, which cause the generated binary to contain metsrv and any other extensions that you feel are required. Using stageless means that the first step of downloading metsrv doesn't have to happen. Another thing to bear in mind is that the default .exe templates used by MSF are well-known, so you could specify your own via the -x parameter in msfvenom.

With the popularity of Powershell, you also have the option of creating Powershell payloads with msfvenom by specifying -f psh, and those payloads can still inject Meterpreter into memory in the usual manner. AV/IPS is yet to do a great job of picking up on such payloads, and so they tend to be a good option if you have the ability to get people to run batch files. I find using the PSH approach with the likes of psexec does very well when trying to avoid AV/IPS.

The communication mechanism that Meterpreter uses is also quiet well known, and hence is another thing that can be picked up on by defensive tools. There might be something coming to MSF that may help with this soon (watch this space).

Migration is also a problem, by the way, in that the "approach" to migrating is easy to spot. However, some AV products allow this to happen after a period of time, so if you find yourself getting caught it might be because migration is happening too early.

Is there any payload writing tutorial on the net that matches my needs?

Not that I know of, but the nature of a hacker is one that makes them get out there and find out themselves! Don't be scared to modify the source of Meterpreter itself. It's all open source and easy to build.

Note: I am not saying it's always going to be possible to bypass all defensive systems in this way, I'm just offering some ideas that might help you get past some.

+1 for the great question, and for the other answers that are both great. Awesome discussion.