Illustrated portrait of Wi-Fi security researcher Mathy Vanhoef of KU Leuven
KRACKWi-Fi security
The Interview
Wireless & Network

‘Always Have a Layered Defense’: KRACK Attack Researcher Keeps Finding New Wi-Fi Hacks

Cybersecurity researcher Mathy Vanhoef knows hackers don’t often break cryptography. Instead, they find ways to sneak around it.
MV
Mathy Vanhoef Β· KU Leuven
August 31, 2026
Β· 16 min read

In 2017, KU Leuven computer science professor Mathy Vanhoef broke a protocol the cybersecurity industry had trusted for fourteen years. He was part of the team that conducted the KRACK attack, exposing vulnerabilities in the WPA2 protocol that protects modern Wi-Fi networks. Since then, he’s been investigating weaknesses in other protocols to find new ways hackers can exploit Wi-Fi vulnerabilities to steal data from unwitting victims.

Tunneling attacks and SSID confusion have been the focus of Vanhoef’s work over the past few years. These attacks, as well as KRACK, all target different weaknesses, but reveal a common thread in Wi-Fi vulnerabilities: hackers don’t often break encryption. They walk around it by exploiting little-known back doors.

In this condensed Q&A, he explains what people still get wrong about KRACK, why twenty-year-old protocols keep yielding new attacks, and which layered approaches help teams keep networks safe.

Especially now, you don’t want to rely on a single defense, because there is always a chance it will get broken.

Mathy Vanhoef, KU Leuven
Let’s talk about the KRACK attack. Can you explain how it works, like I’m a five-year-old?

Maybe one thing to immediately clarify about this attack is that it doesn’t try to crack or guess the password. So you will not, after this attack, learn the password of the Wi-Fi network. But this attack will enable you to read some of the data that is sent over the network. And it will also allow you to inject your own packets into the network so you can also try to attack other clients in the network.

 

It was really a problem in the design of Wi-Fi Protected Access 2 (WPA2). So it wasn’t just like a programming mistake that maybe one or two companies made. It was really a fundamental issue in how WPA2 was designed. And specifically, the mistake was in the security protocol that is run when you connect to a network.

 

So basically, when you connect to a network, you have to negotiate some secrets using all kinds of mathematical algorithms to generate secret keys that you can then use to scramble the data. The problem was in that handshake, in the way those formulas worked. And without going into too much detail, we could basically trick a client into using the same secrets multiple times, and that caused an issue.

 

It’s like if you use a certain code word a lot of times, then people can try to figure out the meaning of your secret word or your secret language.

KRACK changed how a lot of people thought about WPA2 security. Nearly a decade later, what do people still misunderstand about it?

There are two parts: What was surprising at the time, and what people might still sometimes not fully appreciate yet about it.

 

The first thing that was surprising at the time when we discovered it is that WPA2 was really considered very secure. There was even a formal mathematical proof that it provided the necessary security. It existed for more than a decade. So for more than 14 years, no one found a fundamental flaw in WPA2. The biggest flaw researchers could find is that if you use a weak password, people can recover that. But despite this formal mathematical proof, and this decade-long security, we found an issue in the protocol itself. And that was very surprising, because that was quite unexpected.

 

So that is one reason that this really drew a lot of attention. And on top of that, this finding also made people more aware of how important security still is in Wi-Fi networks. Because at the time, people thought, β€œOkay, we have WPA2. We’re good. Everything is secure.” But then people started realizing that, β€œOh, we haven’t really improved the security of Wi-Fi for more than 10 years. We just came up with a standard and then haven’t done any major upgrades.” So this finding did not just impact the core protocol. I would say it also influenced the ecosystem around it, and encouraged people to take Wi-Fi security more seriously. So a few years later, WPA3 was released. In the meantime, we also helped standardize and design some other security features of Wi-Fi.

 

And one thing people might still misunderstand is that in principle, even a WPA3 network might be vulnerable to the KRACK attack. So simply using WPA3 by itself does not guarantee 100% that you cannot perform that attack. But now, the Wi-Fi Alliance will test all newly released WPA3 and also WPA2 devices to ensure they are never vulnerable. The reason why WPA3 can also be vulnerable is because it uses the same handshake to negotiate some of the same mathematical formulas and constructs as WPA2. WPA3 is still better because every new device is tested for vulnerabilities before release and because it prevents brute-force guessing attacks of the password. And on top of that, it also contains some other improvements as well.

Your recent research on open tunnelling hosts revealed over four million hosts that accepted unauthenticated tunnelling traffic. How did you discover this, and why is it a problem?

I first read an article by cybersecurity researcher Yannay Livneh. He posted a short one-page article, where he discovered the IP-in-IP tunneling protocol. That acted as this open tunnelling host that was vulnerable. And he also scanned the internet, and he found around 100 to 150,000 vulnerable servers.

 

And when I was reading that, I thought to myself, β€œOh, this is actually very cool research. It can have a big impact.” And I immediately also thought, β€œAh, but maybe there’s other network protocols that can also be vulnerable.” And then I proposed this as a master’s thesis topic, and one of my students, Angelos Beitis, picked that master thesis topic. During his thesis, Angelos tested a few other protocols, and did a partial scan of the internet. And then we found out that there are indeed more tunneling protocols that are vulnerable.

 

Together, we looked at more protocols that might be vulnerable in the same way. We also looked at whether IPv6 can be vulnerable as well. We then also checked how it could be abused. We scanned the internet in various different ways, and found more than four million vulnerable hosts.

 

So in our very first paper, we basically showed that these hosts can be abused to perform denial of service attacks. And that basically means that you can use these as zombies, to then send out a lot of traffic to other servers or websites on the internet. So you can abuse these open tunnelling hosts to take down websites, to take down servers, and so on.

 

Now, in a very recent paper that actually got presented a week or two ago at USENIX, we found out that these open tunnelling hosts can also be abused, in some cases, to gain access to a person’s private network. So if you are a company or even a home user, and you have a device that is vulnerable to one of these open tunnelling hosts, then there are some tricks to actually gain access to the private network of your company or your home network.

 

The impact can include denial of service attacks and taking services down. And on a subset of those vulnerable servers, you can also access their private network or gain access to an internal company as well.

If an attacker successfully abuses one of these tunnelling hosts, what network controls would be most effective at limiting the damage?

There I would go for a layered defense. Of course, the best thing is to fix the root cause of the problem, to try to prevent having these open tunnelling hosts in the first place. Network administrators can configure your equipment to only accept these tunnelling packets from specific source addresses. So only allow specific IPv4 or IPv6 source addresses. The ideal solution is to use a technology like IPsec so that you only accept authenticated traffic. In other words, you need to have the right password or the right cryptographic keys to authenticate and encrypt your traffic, and only then will the tunnelling host accept it.

 

Now, in practice, it may be difficult for people to update their devices. So in that case, you can try to limit the damage by using a firewall or intrusion detection software to detect strange or malicious packets. Specifically, if you see nested tunnelling packets, that is a red flag that should be detected. So if you see the same packet repeated inside each other, similar to those Russian nesting dolls that you can put inside each other, that’s probably a malicious packet, and then the warnings should go off.

 

Another defense is this general principle of adopting Zero Trust networking. Even if you have access to your network, you still want devices to use authentication. So if you try to remotely log into another computer, or if you try to access a file share inside your company, you don’t just blindly want to trust any device in your network. You still want these devices to provide a proper password or authentication, so that if someone gets inside your network, they cannot just suddenly connect to everything.

One theme across your research is that attackers often exploit obscure protocol behavior rather than breaking modern cryptography. Why do these forgotten networking features continue to be such fertile ground?

It reminds me of a popular quote, β€œCryptography is often bypassed instead of broken.” And that is true for the KRACK attack. There was this formal proof that showed that WPA2 was secure because an adversary cannot recover the password. And in a way, that is actually true, because we indeed cannot recover the password. But we just attack the protocol in a different way to still allow us to decrypt data.

 

These protocols were designed more than 20 years ago. And meanwhile, all the technology around them has drastically changed. So some things that at the time were not really a major concern now become more concerning. It’s often by combining some features of this old protocol together with other modern behavior of a network that you can perform interesting attacks.

 

One example of this is the open tunnelling hosts. Initially, these open tunnels were often used by core internet routers. But then they also got adopted more by companies and even home routers. And this is what then also allows you to use these open tunnelling hosts to access a co-located private network. At first, not many people were using these open tunnelling hosts while also having a co-located private network. But because this old technology is still used in different places, you suddenly have these new opportunities to abuse these attacks.

 

I think sometimes people also do not fully appreciate how often some of these older protocols are still used. I would say it’s very easy to get carried on with the next hype, say AI, cryptocurrency, and look at that. Some of the older protocols are forgotten, and then people don’t study them anymore. But if you do take the time to look at them, you will realize that actually, there are still things wrong with them.

For enterprise network teams, what is the biggest thing they should take away?

I think one of the most important things to remember is the common security principle of always having a layered defense.

 

We saw with the KRACK attack, it was an old protocol, but still there was an issue in it. With the open tunnelling host, it was also a more well-known protocol, but still we discovered an issue in it. And it shows that no matter how well-tested or how old a technology is, there is always a possibility that someone finds a security issue.

 

So I would say you always want to rely on multiple defenses. For example, you want to rely on Wi-Fi security to prevent people from getting into your network in the first place. But then you can also use an internal virtual private network (VPN), or Zero Trust networking principles, to further defend your network even if someone accesses it. Then also, if you have the resources, combine this with some type of intrusion detection. If a single technology is broken, it shouldn’t be that your whole company or your whole network suddenly falls apart. You should be able to contain the damage.

 

And in a way, that’s also something I notice now with some of the AI models finding vulnerabilities, where people now get worried that it’s becoming too easy to hack software or networks. I would say even there, you have the same principle: make sure you have a layered defense and that you can detect when something is going wrong. Especially now, you don’t want to rely on a single defense, because there is always a chance it will get broken.

Can you explain how the SSID confusion attack works, and how it differs from an adversary-in-the-middle attack?

The SSID confusion attack is a more specialized attack, only possible in quite specific scenarios.

 

It can happen if you have two Wi-Fi networks that use the same way to authenticate someone, where you can log in using the same username and password. When you connect to a Wi-Fi network, the Wi-Fi network will verify that you are in possession of the correct password or the correct credentials. But your device, your laptop or smartphone, will not verify whether you are really connecting to the right network name.

 

I think the most interesting way to illustrate this is by the type of Wi-Fi network that we used to have at KU Leuven in Belgium. It used to be that we as university employees could log into public hotspots of a certain Belgian internet service provider all throughout the country. And we could access those hotspots using our university login.

 

Let’s say that I am an employee that only wants to connect to our university network, because I only trust that network. What is possible using the SSID confusion attack is that I could pretend to that employee as if one of those hotspots was the network of the university. I could actually trick that employee into connecting to the hotspot of the ISP. And those hotspots were broadcast by ordinary home routers of users, and ordinary people control their home router, so an ordinary person would then be able to intercept the traffic of this university employee.

 

So to maybe simplify it and have a one line summary, the SSID confusion attack is a specific variant of a man-in-the-middle attack. And that man in the middle allows an outsider to, under the right circumstances, intercept the traffic of the victim. It’s more specific than the KRACK attack and the open tunnelling hosts, but it was also a surprising finding because to discover that attack, we had to think very creatively about what an attacker can do, what an attacker has at his or her hands. So part of the breakthrough was realizing, okay, how can an attacker try to approach this? What are the security properties? And in this case, we cannot just break any network with this attack, but under the right circumstances, we can then suddenly intercept all their traffic.

Your research showed that a client can successfully authenticate to a protected Wi-Fi network and still end up on the wrong SSID. What does that tell us about what Wi-Fi authentication is and isn’t actually proving to the client?

So Wi-Fi authentication was designed on the principle that if you are both using the same credentials, then it just assumes that you are connecting to the right network. But actually, it turns out you need to do more than that. You need to verify that you are using the same credentials, and also that you are connecting to the same network that you expected. Because sometimes networks can have different names and also different security properties, but they do end up accepting the same passwords or the same credentials. So there’s a difference between verifying the credentials and verifying the actual network you intended to connect to.

A lot of organizations view certificate-based 802.1X authentication as the gold standard for enterprise Wi-Fi security. What does SSID confusion tell us about what EAP-TLS solves and doesn’t solve?

I would say that certificate-based authentication is still the gold standard. But at the same time, it does not solve all problems. For example, the SSID confusion attack can still apply to enterprise networks that use certificate-based authentication. In fact, the attack was possible at my university with these local hotspots of our local ISP even though as a university employee I was using certificate-based authentication.

 

Certificate-based authentication is very good at preventing a user from using the same password in multiple locations, because that is often an issue. It also keeps a user from sharing their password or login with other people. But you can of course still have flaws in the network protocol. You can have issues like SSID confusion and the KRACK attack on enterprise networks, no matter which type of authentication you used.

 

If you use these certificates, they also have to be generated securely. For example, recently we saw that a certain Bitcoin wallet was not properly generating their private keys. You can also have the same issue with certificates β€” if those certificates are not securely generated, then you still have a problem.

 

Certificate-based authentication is still the best authentication method, but you still have all the other components of a network. You can still have these protocol issues that need to be updated. It can still be that an internal employee turns out to be malicious, or that they installed malware, and then you still want a layered defense. So you still want this Zero Trust networking principle and to always use certificates in combination with a layered defense.

 

This Q&A is condensed and lightly edited from a phone interview with Mathy Vanhoef. Vanhoef’s views are his own and do not represent the position of SecureW2.

 

SecureW2 is a leader in modern cloud PKI and certificate-based agentic AI security. Through its Signal blog, SecureW2 works with real human technology journalists to interview a range of top industry subject matter experts and thought leaders. Subscribe to get them in your inbox.

Keep Reading

Get the brief before the breach.

SIGNAL decodes the week’s identity, certificate, and network-security events β€” for the IT and security teams who have to respond to them.

Weekly. No vendor fluff. Unsubscribe anytime.