How to Use Wireshark to Steal Passwords

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 send to 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 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

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 by default:

Promiscuous Mode Setting for Network Interfaces

Promiscuous Mode Setting for Network Interfaces

By the way, if you’re capturing on a wireless card, you’ll need “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. 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 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 switches do one thing that makes it almost impossible to have packets on the cable to your network card that do not need to be there: they forward packets only to the port where the receiver is, and the capture will never see any of it. Which looks like this:

Switching without SPAN

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 to your 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, but can be used to grab network packets you want. What it does is to have 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:

Switch with SPAN

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 to port 24. Now, to be able to configure a switch like this, 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 port)
  2. administrator/root access to the switch

It comes down to this: if you don’t have both requirements in place, you can’t capture packets of others, just your own. The only exception is using ARP spoofing or other attacking techniques (which, you guessed it, are most likely illegal unless you’re authorized to use them on a test network).

The real big question

Now, the real big question is often something like this: “how can I capture packets 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 obviously. It’s the same with network packets on a remote network – you need to get physical access to it, or you can’t capture any of it’s packets. So if you want to capture packets with someone’s Facebook password in it, you need to either be

  • physically connected to their network (e.g. when it’s also your network, spying on your family, or on coworkers)
  • physically connected to the Facebook network (unless you’re working for Facebook, that’s not going to happen, and if you are, you don’t need to packets I guess)
  • physically connected to any network in between those two (ever tried to get into a data center where nobody knows you? Yeah, that won’t happen).

So basically, it’s highly unlikely you will get access to their packets if they’re not on your network. And if they are, you need administrative access to the switches.

Finding the passwords

Let’s say we somehow managed to get the packets we wanted, and they contain passwords. 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

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:

FTP Stream Decoded

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. Again, there are two options here:

  1. 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. 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, so better run), 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.
  2. 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 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 this post): Wireshark can only decrypt the packets if the key exchange used the RSA method, not DH, since DH key exchanges uses a randomly created public/private key pair to encrypt the session key in the ClientKeyExchange handshake message (Elliptic curve stuff and Perfect Forward Secrecy is a deal breaker, too, so doing this gets harder every day, because thanks to the Snowden leaks everyone is beefing up their encryption):
    https://twitter.com/debookee/status/761103664366747648TL;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.

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. 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” 😉

Discussions — 16 Responses

  • Vladimir July 29, 2016 on 11:18 am

    What a disappointing 🙂

    There might be some ‘hybrid case’ too – the protocol itself isn’t encrypted, but clear-text passwords never appear in the trace.
    For instance, HTTP with DigestAuth or CHAP – you’ll see only hashes flying by you. No luck!

    Reply
    • Jasper Bongertz Vladimir July 29, 2016 on 12:13 pm

      Right, that can happen as well, good hint. Thanks, Valdimir!

      Reply
  • CiscoBob July 29, 2016 on 5:07 pm

    Hi Jasper,
    another idea could be to capture a basic-auth packet and display the password immediately 🙂

    Reply
    • Jasper Bongertz CiscoBob July 29, 2016 on 5:19 pm

      yup, that should be easy enough 😉

      Reply
  • Christian Reusch July 29, 2016 on 6:17 pm

    Nice article and like always it is a pleasure to read. This should help to answer a lot of questions at the Wireshark Q&A site 😉

    Reply
    • Jasper Bongertz Christian Reusch July 29, 2016 on 6:19 pm

      Thanks, Christian – most people will be disappointed though when they read it I guess 🙂

      Reply
  • Christian Reusch July 29, 2016 on 6:30 pm

    Yeah I will guess it, too 🙂

    Reply
  • Kary August 3, 2016 on 12:31 am

    I called Facebook and they wouldn’t give me their private keys. I asked very nicely too. Jerks.

    Next I’m going to call every Facebook user and ask them. How many users do they have again?

    Reply
    • Jasper Bongertz Kary August 3, 2016 on 12:37 am

      lol… let me know how far you get – I guess many users will give you their passwords if you social engineer them just a little (“I need your information to make the internet go faster – I know packets, I can help!”) 😉

      Reply
  • Hansang Bae August 4, 2016 on 12:51 am

    @Kary LOL. How many users? Reminiscent of D2F, Theta D, and MJ Time! 🙂

    One of the funniest moments in TV history.

    Reply
  • Will November 27, 2016 on 9:08 pm

    One item worth mentioning in this is that now there are many devices in the enterprise that are doing man in the middle decrypting using local PKI and putting a CA on the Firewall/Load Balencer/Web Gateway (a proxy by any other name). Some of these will do a quasi analyzer port for the decrypted traffic. Of course the normal user has no problems checking their certs in a TLS connection. 😛

    That is another way to turn the encrypted into the plain text. This does not change the fact that you can’t get the info without the keys, but it at least lets you know that there are some out there in the flow that might be getting the info along the way unless the client is looking really close.

    Reply
    • Jasper Will November 27, 2016 on 11:12 pm

      Absolutely correct, Will, that technique is usually called “deep packet inspection” or “lawful intercept” – mostly used in companies to be able to check HTTPS content for malicious traffic. I don’t think this is relevant to many home users, except of course in countries where the government or an ISP thinks it’s okay to do this 😉

      Reply
  • Dan May 17, 2017 on 2:36 am

    MITM, utilize SSL strip.

    Reply
    • Jasper Dan May 17, 2017 on 9:51 am

      True, but for that you need to achieve a Man-in-the-Middle status (which is most likely illegal, once again), and more and more sites run HSTS, which prevents SSLstrip. Since many readers of this post are looking for Facebook passwords specifically: Facebook uses HSTS, so no SSLstrip without some additional fowl play (e.g. tricking victims into going through a non-english subdomain that isn’t HSTS enabled).

      Reply
  • John Murphy August 16, 2017 on 2:56 pm

    Finally I can find an article which explains the whole picture in a calm way , one by one written all points. Thanks.

    About this subject, there is always one question in my mind which I cannot find the answer and I’m curious about the it. I would appreciate if you can make any explanation here to me and other readers who may think about the same point. I will try to ask it as below;

    As you said between server and user’s computer (client), there is a strong encryption and we cannot easily find it out from both ends.

    But when this encryption is happening between these both sides (server and client)?
    Finally at the beginning, they don’t know anything about each others’ (keys), and in one way they must transmit this information from one side to other side.
    I am talking about “Handshaking”…There must be an handshaking between them at first….am I right?

    So what I am curious about is;

    How this handshaking happens between server and client? (In other words, How can they both know the same key, while preventing other 3rd observers see or catch this key?)

    Reply
    • Jasper John Murphy August 20, 2017 on 10:40 pm

      Thanks, John!

      Yes, there is a “Handshake”, which is using asymmetric keys so that no party needs to expose the encryption key used for the connection. You can think of it like this: one side sends its “public” key to the other side, which uses it to encrypt a session secret, and sends that encrypted secret back. To decrypt the session secret a “private” key is required, which is never transmitted over then network. Instead, the receiver of the encrypted secret (which is identical to the sender of the public key, as a reminder) uses it to decrypt the secret, and now both sides have an identical secret they can use for (the much faster) symmetric encryption.

      See also https://en.wikipedia.org/wiki/Public-key_cryptography

      Reply

*