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 meant to be received by your PC. This may sound complicated, but it basically works like this:
- 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
- if the destination address is a match, the packets are destined for your PC and will be passed up to the CPU and processed
- 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
- 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)
- 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:
- the network protocol transporting the packets is unencrypted
- the network protocol is encrypted, and we do not have the encryption keys
- 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:
- Decrypt traffic with the “Session Keys log” file
- 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.
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!
Right, that can happen as well, good hint. Thanks, Valdimir!
Hi Jasper,
another idea could be to capture a basic-auth packet and display the password immediately 🙂
yup, that should be easy enough 😉
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 😉
Thanks, Christian – most people will be disappointed though when they read it I guess 🙂
Yeah I will guess it, too 🙂
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?
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!”) 😉
@Kary LOL. How many users? Reminiscent of D2F, Theta D, and MJ Time! 🙂
One of the funniest moments in TV history.
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.
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 😉
MITM, utilize SSL strip.
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).
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?)
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
haha those discouraging words are heart touching!!
you speak like security guys, those always shouting everything is in control and everyone is secured but we see even presidents accounts are taken down every now and then!
Yep, they are – but not by using Wireshark 😉
Also, people are people and security is annoying, so every once in a while being lazy about security backfires. That’s the way it is.
thanx Jasper for your article, it is a pleasure to read
i have another question or issue
i want to analysis the traffic i already have a packet of all traffic i want to know the most website visited by employee and download
how to analysis this pakets to know
all i got is the ip of client go to public ip ( need this public io to resolve to name )
most client is useing chroom and all the traffic is https
do u have any idea how to do it free
thanx again
You could check the DNS traffic for domain names that the user calls, and then check how much traffic follows to the IP address for that domain. Or the HTTPS server certificates could give you a clue what HTTPS resources the user accesses.
Hahahaha meinst du das ernst?
Spricht etwas dagegen? 🙂
i have four wifi adapters of Alfa with alike specifications. but they they dont capture alike packets
I’m not at all a WiFi specialist – but radio capture is much more complex than wired capture because of frequencies, interference, channel selection etc. So in the end the problem is this: capturing the credential stuff is hard enough on a wired connection. Wireless can be worse (as long as HTTPS is in place, of course).
Great article and thank you so very much! This has been a long unsolved question in my head and all the articles thus far have been exactly how you explained, click bait /hopeless and a waste of time.
THANK YOU
THANK YOU
THANK YOU x like 10 years ! Your a true teacher, have a great day.
You’re welcome! Glad I could help (I really hate those click bait articles 🙂 )
Nice article.
One query. How do we observe a 2 tier thick client traffic.
Database server and client both are in different location.
Following tcp packet stream will help?
Follow TCP stream only works if you already have the packets in your capture – so the main question for you is how to get the packets. For that you need to be able to capture the traffic on the links where they pass through. If you can’t get access to those links you can’t do anything, including following TCP streams.
Congrats for this articole, first of all! I kinda knew it was almost imposibile to hack a facebook password but the curiosity made me search about it on google. I am glad i came into this article.
Thank you Jasper, I am finding your site a very interesting read as my employer is starting to think about network monitoring and realising that much of what they see on the wire will be hard to IDS due to DHE not RSA being used to encrypt the session key.
I did want to point out that wireshark does contain another method for decrypting TLS connections which is to have the session keys. See the (pre)-master-secret log file option in the SSL protocol config.
I see this was presented in SharkFest 2017 Europe as SSL/TLS Decryption. https://sharkfesteurope.wireshark.org/assets/presentations17eu/15.pdf
Of course if you can set the SSLKEYLOGFILE environment variable on the host machine you probably already own it, in either the legal or hacker sense of the word.
Hi Mark, thanks! I think what you refer to with the pre-master-secret log method is what I already described as “Option 1” in the “Encrypted Protocols” paragraph 😉
Dear Jasper:
Great article. Thanks.
So, I got to the point where I have a password in hash form, I think. Now what can I do with it?
Regards, -A.
It depends. If it is hashed with a salt (a unique part added to the password) it may not be possible to find the associated password. Otherwise you could try to google the hash and maybe find a cleartext password for it. There are also rainbow tables for common passwords that you might use. Or, if you know how, you could try to brute force it. The last two options require some technical know how though.
I am not trying to steal a password. I searched for “network protocol analyzer https password” because I want to retrieve a forgotten password if possible. So I want to do that in my own system. It is not clear to me if any of this will help with that. I get the impression that if the password is sent encrypted then none of this helps.
No need to apologize, Sam, don’t worry. Most readers are in fact trying to do something ethically questionable (like spying on partners, friends, etc.), so the text is a bit harsh in that way. While it’s possible that “none of this helps” it should have helped understanding the odds and the obstacles. If there’s no way to grab that password you need (because of the encryption or other reasons) at least you know now why.
When it comes to HTTPS passwords you might check if your browser allows you to see the stored passwords. Maybe you can get to it that way instead of sniffing packets.
can this be use for wifi.pardon me if this is astupid question as i am a beginner.
Don’t worry, it is not stupid, and especially not if you’re a beginner 🙂
WiFi is probably easier to capture because you only need a WiFi card that can capture in monitor mode, which should be relatively easy on Linux or Mac OS. Windows is a bit more complicated because you might need special hardware, but with the npcap driver you can often capture on “normal” wireless hardware as well. If you’re using Windows you might want to check out this blog post: https://blog.packet-foo.com/2019/04/wireless-capture-on-windows/
When you managed to capture the packets the same problems occur like on wired networks, with the additional challenge of the WiFi usually being encrypted on top of everything. So in the end this may be even less useful than a wired capture.