Wireshark is a great tool to capture network packets, and we all know that people use the network to login to websites like Facebook, Twitter or Amazon. So there must be passwords or other authorization data being transported in those packets, and here’s how to get them.

Capturing interesting network packets

The first thing you need to do is to capture the network packets that contain the passwords (or other credential types, but let’s say we’re focusing on passwords for now). Capturing network packets in general is easy – you can do it on almost any PC where you’ve got administrative rights. “Normal” user rights aren’t enough in most cases, because you need to enable Promiscuous Mode on the network card to be able to capture packets that are not meant to be received by your PC. This may sound complicated, but it basically works like this:

1. All the packets on the network that actually arrive at your PCs (or Mac) will be inspected to check if they have a destination that matches the network card
2. if the destination address is a match, the packets are destined for your PC and will be passed up to the CPU and processed
3. if the destination address in the packet does not match the address of the network card the packets will simply be ignored and discarded

Take a good look at number 3 – this means that if your network card sees packets that are sent from other PCs to other servers (without your PC being involved at all), your card will not even really look at them except to find out that it doesn’t care. So if you want to grab stuff that others are sending to each other, you’ve got a problem.

Now, if you want to tell your network card “hey, accept everything! Forget the destination thing filtering, I want it all!” you need to enable a special mode on the network card. That mode is called “Promiscuous Mode”, and Wireshark does it automatically by default:

Promiscuous Mode Setting for Network Interfaces

By the way, if you’re capturing on a wireless card, you’ll also need something called “Monitor Mode” enabled as well, or you’ll not see packets with their radio information. This is something you can’t do on Windows with Wireshark except if using AirPCAP adapters. Update: this is possible now (more or less) on Windows when you use npcap instead of WinPCAP. I wrote a blog post about that here. Monitor Mode is basically turning your WiFi card into a “receive only” listening device for radio waves (which also means you cannot use it to communicate with the network while it’s in that mode), and is required to see packets from and to other devices.

Now, if you’re successfully running Wireshark in promiscuous mode on an Ethernet card, you might wonder why you’re still not seeing packets of other PCs talking to the internet. The reason for this is that PCs are connected to network devices called “switches”. And all switches do one thing that makes it almost impossible to have packets on the cable to your network card that do not have a reason to be there: they forward packets only to the port where the switch knows the receiver is connected to, and the capture will never see any of it. Which looks like this:

So, again, you can’t capture what you wanted, even with promiscuous mode enabled on your card. Simply because the packets do not even make it onto the cable to your “accept all” network card at all. So how can you get the packets? Is there a “promiscuous mode” you can enable on the switch? Sort of. It’s called a SPAN port (“Switch Port ANalyzer”) using “Mirror” and “Monitor” ports, which was initially designed to debug the switch itself. Those special ports can be used to grab network packets you want. What they do is to tell the switch make copy of packets you want from one port (“Mirror”), and send them to the port (“Monitor”) where your Wireshark/Sniffer is running:

To tell the switch you want a SPAN session with mirror and monitor ports, you need to configure it, e.g. like this on some Cisco devices:

Switch(config)#monitor session 1 source interface gigabitEthernet 1/3 both
Switch(config)#monitor session 1 destination interface gigabitEthernet 1/24

This tells the switch to send everything coming in and out of port 3 (the “source interface”) to port 24 (“destination interface”). Now, to be able to configure a switch to do this for you, you need

1. a switch that can be configured (meaning, “dumb” cheap switches without a console or web interface are no good; this includes almost all embedded switches you find in DSL or cable routers that have more than one network port)
2. administrator/root access privileges to the switch

It comes down to this: if you don’t have both of these requirements in place, you can’t capture packets of others. Just your own. The only exception is using ARP spoofing or other attacking techniques. ARP spoofing intentionally misdirects packets so that a “Man-in-the-Middle” can capture them for inspection before passing them on.This, you may have guessed it, is most likely illegal unless you’re authorized to perform this on a test network.

The real big question

Now, the real big question is often something like this: “how can I capture packets to and from someone on another network than my own?”. So let’s say you’re at home, running Wireshark on your computer, and you want to capture packets of a friend sitting in his own home, at his own computer. This is like trying to read a postcard she or he is sending via snail mail – you need to be at the right spot at the right time to see it pass you by, or you can’t read it (this should be obvious). It’s the same with network packets on a remote network – you need to get physical access to the path of the packets, or you can’t capture any of them. So if you want to capture packets with someone’s Facebook password in it, you need to either be

• physically connected to the network they’re using, e.g. when it’s also your own home or work network and you’re spying on your family or on coworkers
• physically connected to the Facebook network (which, unless you’re working for Facebook, is not going to happen. And if you are, you don’t need to capture packets for this kind of thing I guess – just steal the credentials from database or whatever they use)
• physically connected to any network in between those two, e.g. your friends Internet Service Provider (ISP). Well, have you ever tried to get into a data center where nobody knows you? Yeah, that won’t happen.
• capture plain text wireless packets while sitting close to someone you want to steal credentials from, e.g. in an unencrypted WiFi of a coffee shop (this is actually the best chance you get I guess).

So basically, it’s highly unlikely you will get access to the packets you want if your victims are not connected to your own network, or using unencrypted wireless networks close to you. And even if they are on the right network, you need administrative access to the switches. Which (sadly) is not completely impossible because many of them still run with default credentials, so they’re easily hijacked (which, again, is illegal).

Finding the passwords

Let’s say we somehow managed to get the packets we wanted, and they do contain the passwords we want. Which means that one of three things is the case:

1. the network protocol transporting the packets is unencrypted
2. the network protocol is encrypted, and we do not have the encryption keys
3. the network protocol is encrypted, but we have the encryption keys

Unencrypted protocols

In the first case, things are simple – load the captured packets into Wireshark and look through all packets to find passwords, e.g. by using “Follow TCP stream” from the popup menu on a FTP connection:

Follow TCP Stream Menu Option

Which will show a new window like this, with the password easily readable, because that function extracts all readable characters as a text output:

Follow TCP stream output

Encrypted protocols

Okay, now if you’re looking at the traffic generated when logging into a web site you’ll most likely end up staring at a HTTPS connection, meaning that it was encrypted using SSL or TLS. If that is the case, your options are either giving up (because let’s face it, you’re not going to break that encryption without the keys, at least not anytime soon), or you get access to the encryption keys. Sure, there are some attacks against SSL and TLS, but let’s face it – if you’d know how to do those you’d not be reading this blog post.

So again, there are two options here:

1. Decrypt traffic with the “Session Keys log” file
2. Decrypt traffic with the private key of the web server

Option 1: Session Keys Log file

You can decrypt HTTPS traffic in a quite simple way by using the Session Keys log file written by Firefox or other browsers. For that, the browser needs to be configured to dump those encryption keys to a log file, and you need to get that log file. And, to clarify: I’m talking about the web browser of the person you want to steal the password from. Now, if you’re talking about decrypting your own HTTPS traffic, that strategy will work, e.g. following this tutorial.

If you’re trying to decrypt HTTPS traffic of other users without valid access to their computers, it won’t work. You’d have to steal their session key file from their hard drive (which is illegal, by the way) after reconfiguring their web browser to store the encryption keys to disk in the first place (unless they did that themselves, which is highly unlikely, and if they are, they’re probably better at network captures than you are), and then somehow grab their traffic at a location you should most likely not have access to.

TL;DR: if you try to decrypt HTTPS sessions of other users, the session key log file method won’t work for you.

Option 2: Private Key of the Web Server

The other option requires you to have access to the private key of the web server, which allows you to decrypt all connections to that server. Most security professionals reading the last sentence will now mutter something under their breath along the lines of “yeah, like THAT’S going to happen…” or “good luck with that…”.

Just to give you an idea how likely it is for you to get a hold on the private SSL/TLS encryption keys to the Facebook servers let me ask you one thing: can you get a copy of the original recipe for Coca Cola? No? Why not? Right – for the same reason why you won’t get the private crypto keys from Facebook. They just don’t want anyone to be able to decrypt ALL the traffic except for the parties involved, just like Coca Cola doesn’t want you to have their most valuable secret.

In one case I literally had to have a written order from the company’s CEO before the server admins of that company would hand over the private keys, and only handed over personally via encrypted USB stick, never via email. And this was for a network forensics job where I was authorized to decrypt the packets for investigative reasons.

And now for the real bad news – thanks to Tom for pointing it out to me, as I was too lazy to go into this at the time I wrote the initial post: Wireshark can only decrypt the packets if the key exchange used the RSA method, not Diffie-Hellmann, since DH key exchanges uses a randomly created public/private key pair to encrypt the session key in the ClientKeyExchange handshake message. Newer techniques like Elliptic curve cryptography and Perfect Forward Secrecy are another deal breaker, too, so stealing secrets gets harder every day, because thanks to the Snowden leaks everyone is beefing up their encryption:

We stress that point in our Wireshark trainings: >75% srv/clients now prefer PFS (DHE & ECDHE key exch.) pic.twitter.com/8YmfOOp45s

— Debookee (@debookee) August 4, 2016

TL;DR: You’re not going to decrypt HTTPS to Facebook, Amazon, Twitter, or anyone else using strong crypto correctly when you can’t use the first method, which requires access to the computer of your victim.

Final words

If you’re disappointed by now I can totally understand. You can’t get easy access to packets of other users, and you can’t decrypt the sessions that hold the things you want to see most. If at all, you can only look at unencrypted stuff, and only on networks you have administrative access to. Which, let me remind you, is a good thing – it makes sure that it’s hard for others to read your private stuff, too. Or steal your logins. So if you have a valid reason to get those packets, you still can – capture at the right location, get the encryption keys, and go ahead reading the clear text in Wireshark.

It’s funny how often the password “reading” question is asked in forums like the Wireshark Q&A site or on Twitter, mostly by people who have never really used Wireshark (or any other Sniffer / packet analysis tool) before. And there are many articles out there that pretend to tell you how to do it, mostly being simple click-bait. They never really tell you what you’re up against, and I don’t like to see that kind of thing – it’s like pretending to teach something and then not keeping the promise. So this blog post was written like click-bait in the beginning on purpose – get attention, but then keep the promise, even if it tells you “most likely, you can’t, and why” 😉

By the way, some final statistics: you’re not the only one interested in stealing passwords – more than 7 out of 10 search queries leading to my blog end up at this exact post.