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 on the network card to be able to capture packets that are not send to your PC. 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.

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: 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?

It’s called a 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: 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. 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). 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 or other attacking techniques – which, you may have 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 – 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 (have you 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 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. 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 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:. 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. 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, so better run and hide), and then somehow grab their traffic at a location you should most likely not have access to. 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?

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 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. Stuff and is a deal breaker, too, so doing this 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.) — Debookee (@debookee) 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.

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 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. 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 – 7 out of 10 search queries leading to my blog end up at this exact post. 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.:-P 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. Finally I can find an article which explains the whole picture in a calm way, one by one written all points. 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?).

Wireshark Mac Address

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

Welcome to the unofficial Ubiquiti Subreddit! This is a place to discuss all of Ubiquiti's products, such as the EdgeRouter, Unifi, AirFiber, etc. Mods reserve the right to remove topics that are considered disruptive or inappropriate for this subreddit. Please do not.

Spam, promote your business, or job postings. List items for sale or conduct a virtual 'swap meet'. Write excessively rude or condescending posts (we are all entitled to our opinions, but order must be maintained). Give people incorrect information on purpose. We are all familiar with what the boxes look like. When in doubt, contact the mods and ask.

Some Helpful Links. Hey thanks for the reply, I'll definitely give this a go once I'm on my windows machine? Also you're referring to PuttyPlink tool right? I was hoping there'd be a way for me to have a syslog being automatically sent daily (like dd-wrt does with papertrailapp.com) without having a PC hooked up or is this not possible? I thought I read somewhere that a DD-WRT router in monitor mode, with tcpdump would push logs but the storage space on the router wasn't high enough. (haven't tried this yet).