Downgrade HTTPS connections to HTTP using Ettercap filters

Ettercap is a great tool for MITM poisoning and sniffing. Everyone on Infosec should have played with it (or Cain) at least once.


MITM attacks are pretty easy to perform on a local network but the tools tend to crash a LOT. Cain (Windows) is a little more stable than Ettercap but I prefer it over Cain because it doesn’t spoof SSL that I consider too loud depending on the attack. NOTE: Ettercap runs better on text mode.


Well, another nice feature of Ettercap are its filters. You can do lot of stuff while playing with them. The nicest toy I’ve found to play around so far is content rewriting (but I think custom packet injection can be even funnier). Irongeek has played with Ettercap Filters in the past to rewrite img tags.

Sniffing while MITM

Sniffing plaintext passwords are just easy. Either Cain and Ettercap are built to detect common strings containing passwords but SSL has made this kind of sniffing impossible and many sites are using it at least for the login processes.

So while we wait for the super-quantum-computers to break 256-bit AES encryption, we may consider avoiding SSL for the period we’re sniffing so I’ve thought that filters could be perfect for that.

What would define where the login form data will be sent? The form‘s action field. So if I can interfere in the HTTP response I can send the login data ANYWHERE.

I’ve decided to just downgrade the SSL because I always tend to make the least noise I can (because we don’t want to get caught by the forensics, do we?). I could redirect the request to a specially crafted site or so but it would be much more noticeable.

What if SSL is required on server-side

No problem, SSL on server-side can be a requirement but by the time the server complains, data was already sent over in plain-text. :)

Getting things done

You can get my filter on my github page.

Just run the attack with the filter (assuming router is and victim is

You should see the following output:

And your victim will no longer receive (nor send) any https string anymore.

Quick note about request / response filtering

Sometimes you may have to comment one leg (request / response) out of the filtering or you will get redirection loops (like while tampering Facebook connections). Also, if the request is already under https, you won’t be able to filter it. The beauty of this attack is disallowing your victim to escape your domain to a secure zone.


Mitigating the risk on an ARP poison attack

ARP poisoning is a technique quite simple to be applied and allows traffic to be sniffer over a switched network. It can be used to sniff the connection on-the-fly and capture plain-text password or hashes. ARP poison also allows combination with other attacks such as DNS spoof and packet filters in order to deploy client side exploits transparently.

This attack can only be performed from the local network because ARP packets aren’t routed so you can’t hop between LANs but it can be performed from any machine on the same network so it is a serious concern when dealing with unhappy employees, interns and industrial espionage. It is even a greater concern if you have public (or WEP encrypted) WIFI access in the same network (terrible mistake).


ARP can’t really be blocked because they resolve IP addresses to MAC addresses. ARP packets must flow thru the network (unless you have ALL your MAC addresses statically configured) so machine can talk to each other. ARP doesn’t verify the requests and responses so any machine is able to respond to an ARP request in behalf of another machine making all traffic pass thru him. This is the ARP poison attack and is one of the most popular MITM techninques.


A well designed network is effective against several attacks, including and ARP poison attack. Since ARP packets can’t be routed the attack is retained at the local network so you may consider break your network into smaller subnets (VLANs). Note that attack still can be escalated if a machine that communicates to other lans is compromised.


Encrypted traffic can be sniffed but can’t be understood. IPSec is feasible too but you can secure your services under SSL so you don’t need to encrypt all your network traffic that could slow down your network.

Static ARPs

You may write your ARP tables statically so it doesn’t need to be updated via requests and responses. This can be tough to manage so you might consider issuing this to login scripts or other configuration management software. Its like maintaining an hosts file.

Inline IDSs and ARP watchers

Using an inline IDS within your routers may early detect ARP storms and isolate the attacker. Some software may be put to watch ARP tables for changes. One ARP watch solution under UNIX systems is arpalert.

Preventing your servers from downgrade attacks

One of the coolest attacks is forcing a downgrade between the client and server, making the server believe that client has support only for older and insecure versions of your protocol. This works with Windows’ NTLM authentication and with SSL, mostly.

How does ‘downgrade attack’ work?

Downgrade attacks are born from a misconfiguration and takes place within MITM attacks. Privilege is escalated by trapping the connection request and thus forcing the use of an older protocol version with known security issues by faking the client-side accepted protocol versions. Then the weak protocol is attacked and access is escalated.