 Hello, everyone. I'm very happy to be there. Let's start. This is defeating VPN always on. My name is Maxime Clemens. As you can hear, I'm French. Hopefully the speech-to-text will be able to translate what I can say. Sorry if that's not the case. Yeah, okay. I got my first indistinguishable. Okay. Let's go. I work in Luxembourg. It's a very small country. I work in the PwC company. Do we have anyone from PwC in the room? Yeah. Great. Okay. Okay, let's start. So I will try to show you how our liaison can be a bit off sometimes. So the reason of this talk is that I uncontrolled this kind of control during some penetration tests on. I managed to find one bypass, then two bypasses, then three. So I decided to dig further and to try to better understand how it works when it does not really work. We will start with the high-level concepts, with the components of always on, and then we will see the practical analysis. So what it is made of. We will almost directly identify some naive attacks. I would say naive because we don't need to understand exactly how it is implemented. Just based on the documentation, we will find some attack that might work or not. Those attacks on the results will raise some questions. And maybe we will need to look behind the scenes to better understand all these results. We will inspect some of the filters to try to find new attacks that will allow us to break free from the always on. And then obviously I will finish with some recommendations. So who is this talk for? Definitely red teams or offensive teams. I will try to show some of the attacks that I found that will allow you to defeat always on to bypass this control. For the blue team, of course, I will try to show what are the main issues that we have in the most popular VPN agents. Or definitely we will try to improve the situation here. Most importantly, we can find a lot of ways to actually bypass VPN always on. I will be focusing on all the techniques that we can use without privileges, without complex tools, without specific attacks. So I'm really looking forward to showing some attacks that anyone can replay so that you can use it in your offensive assignments, for instance, on the victim side as well. I want to run some attacks that might work without privileges. So the main concept I guess that I don't need to explain what the VPN is, but I'm specifically referring to VPN in the corporate context. So if the company, the organization tries to protect their remote end users, then of course they will try to implement a tunnel so that you can get all the protection from the corporate controls. If you know VPN, then you might already know the differences between split tunneling and full tunneling, but today we are going to focus on always on, which is also called lockdown mode, which is again like full tunneling mode, but then with the user is not even able to disable the control. So it will be forced to connect to the VPN gateway. Today I selected three editors that we are going to attack and we are going to review how they are implementing such controls, but basically they are almost all the same. If you look at the documentation of other providers, you will see that they are probably going to be vulnerable to the same things. So this is the typical symptoms of having enforced always on, on Windows machine, for instance. You will see the quite typical general failure, like when you are doing some ping comment, it will not say that the ping is not coming back and that there is no response. Now it will be this weird message, general failure. So this is kind of a typical symptom that we can have on. Obviously, if the tunnel is not established, like I took AVNT for instance, then in that case we have a restricted network access. We will get some error messages from the browser. And again, since it is enforced, the end user is not able of, cannot disable this control. So we will get some other error messages. In the scenarios that we have, obviously if we are admin, if we can steal all the data by plugging in USB key, if we can decrypt the drive, all those we are not, I would say they are not relevant for this scenario. I'm really speaking about a scenario in which the endpoint is very well hardened, so the end user doesn't have any admin access. We cannot just plug a USB key, and so on, and so on. So the web proxy in the corporate environment is doing TLS interception, so everything is there to actually prevent any kind of data leak or any kind of C2 bidirectional channel. But another thing very important, we know there have been many talks about exfiltration with sound, electromagnetic noise, pixel, QR code and so on. They are great, but we are really interested in simple things with high throughput. So we want to be able to exfiltrate big files, for instance. So we need to find much effective attacks. The scenarios that we are going to consider, obviously the first one, the hacker in the middle, the hacker does not have access to the target device, so the target device can be a laptop, typically. And the other scenario that we can consider is if the attacker has access to the device or if it is a malicious insider, then obviously it will be able to do both commands on the laptops as well as controlling the network. So enough theory, let's have a look at some of the components that are needed for always on to work. The first one is trusted network detection. Of course, the local VPN agent must understand, must conclude if it has to connect to the gateway or not. So for this, the algorithms that are being implemented in the VPN agents are called trusted network detection. When outside of the trusted network, the VPN agent needs to know if the gateway is directly accessible or not, because if you are behind a captive portal, for instance, you will not be able to reach the VPN gateway and you will be first allowed some specific network access until you can authenticate on the captive portal, pay what you want or just enter your credentials until you are authenticated and then you can eventually reach out the VPN gateway. If we look at the implementation of trusted network detection in the three VPN agents that I selected, it's more or less the same. Let's take for example Cisco to determine if we are on the trusted network, then it can use the internal DNS suffix or the internal DNS server IP. Just to mention a very important point here, Cisco is the only one provider that is actually proposing an option that is secure enough. So if you want to determine that you are on the LAN, on the trusted network, then you can still use the fingerprint of TLS certificate. So this in my opinion is the only way you can do that properly, but it's so impractical that to be honest, I've never seen that implemented correctly in the wild. For the other ones, you can see that it's also something that are pushed by JCP offers or IP settings, these kind of things. I'm already showing the pass on location of these settings on logs because we will actually find all the values that we need to attack these agents. Another observation is the files that we have there on the logs, they are all user readable. So you do not even need admin rights to get these files to read them and to understand what is expected so that the VPN agent will conclude that it's on the trusted network. Obviously, most of these checks can be tracked. Finally, I referred to split turning earlier. This is also where you will find all the exceptions for the IPs, domains that you can connect to directly. If you look at these files, you might already find everything you need to perform your attack if you want to break free from this situation. Let's move on to the captive portal detection. So it's a kind of security trade-off for connectivity. I just explained there what are the main algorithms that are being used to determine if the laptop, if the system that you are using is directly connected to the Internet or not. For Microsoft, Google, and Apple, it's quite similar in the way that they are performing some HTTP requests and depending on the response, of course, it will determine that you are directly connected or not. When not, if this check fails, then it is assumed that you are behind a captive portal and this is where you will get the prompt that you need to authenticate with your web browser before you can get access to the Internet. The VPN agents that I'm going to, I would say, attack today are using a combination of these tech checks, but for Cisco, it's a bit different. It will use some HTTPS connection before, but all these tests can be tricked. So we had a look at trusted network detection. We had a look at captive portal detection. Obviously, you know that we can already find some attacks that we can try. But just a quick reminder, what you are trying to achieve there is to do some data expiltration, but with important files, very big stuff, or to establish a commoner control with a bidirectional channel. So this is what we try to achieve there. And again, with the constraints, we are not admin or we do not even have access to the laptop itself. We want simple attacks. We don't want to use binaries that we would have to compile and to put on the laptop and so on. And again, the endpoint is hardened. So as you understood, the VPN agent still needs DNS to work because this will be the only way for it to get the IP address of the gateway, the VPN gateway. So, thankfully, we can think that maybe we can use DNS ourselves in order to establish some tunnel. And indeed, it works. So indeed, I mentioned some of the tools right here, but again, we do not need any external tools to do these kind of things. We can simply use PowerShell, for instance, that is capable of doing DNS on LLMNR. The conclusion for this quick on-nive attack is that it will work for Cisco on Palo Alto. The UDP LLMNR will work with Palo Alto only and with Eventi, nothing works. So it's not possible to try to establish a tunnel or to send some data over DNS with Eventi. We already found some discrepancies here that I will try to explain later. Another example of attack that is highly effective is if you are able to do some Ethernet management like with Slim Machine or these kind of things, but they only make sense if you are inside the corporate environment and you have access to network plugs. So let's not discuss about this there. The third option that we have, based on the design issues of VPN Always On, is that we can try some other protocols that could be there and that could be useful and that could work. Honestly, I wanted this talk to be about some crazy exfiltration protocols and ideas that I have, but it was so easy to bypass the actual controls that we can already forget about those, especially since I do not want to compile or to add some new binaries to the victim machines. Okay, I mentioned DNS, but we do not really need to comply with the DNS protocol. We can simply try to use UDP 53 as an outbound connection to try to send some data grams, you know. It will be much more effective than a DNS tunnel because then we will have the full bandwidth that we can try to send. So I'm just putting there a very naive PowerShell script because we can use the UDP client PowerShell function that will allow us to send some data grams over the port that we like. On again, some kind of discrepancy there. So this is a not DNS UDP 53. It will work with Cisco on Palo Alto, but again, not with Eventi. So you might think that, okay, Eventi managed to implement a much better always-on feature. Wait for the end of this talk. For some reasons, you might think that, okay, DNS worked, but we also need DHCP to be working even if we haven't always enabled. Well, it did not work at all for any of these three, and we will try to figure out later. Another thing that I found interesting is a kind of lockdown grace period that can be observed for Cisco on Eventi. So as long as we get the DHCP response with an IP in it, then for Cisco on Eventi, it will take them between four to 10 seconds in my experience before the connection is, I would say, locked again. Unfortunately, this is long enough to get this kind of screenshot that I know you like seeing on your screen. You are completely able to get the hashes of the user with Responder or any other tool. So this is well enough either to get this kind of hash or to extract some small files already. So you have nothing to do just with this grace period. You can already get some nice results. But again, another discrepancy with Palo Alto Global Protect, there is no such grace period observed. So again, something that we will try to answer later. So I mentioned captive portal detection. It's kind of obvious what we will try to do there now. If you remember some of the algorithms that I explained about, okay, how can we determine if we are behind captive portal or not? Well, then it's trivial to spoof, this kind of things. And I'm just suggesting some IP tables will allow you to make the VPN agent to think that you are behind a captive portal and it will unlock some connectivity so that you can use that on authenticate. So for event T on Palo Alto, it's just with the 80, HTTP, so TCP 80 port for Cisco. It just requires to redirect the 443 as well just because of the algorithm that they use. But now that we can pretend we are a captive portal, the VPN agent will unlock some connectivity and we can then try to steal credentials. We can try to establish bidirectional channel to exfiltrate data on to send some commands. So we can try that. On the right, I wrote a very, very naive captive portal web server which will pretend that we have to authenticate to connect. So based on, thanks to the IP tables rules, we will redirect all the connection to that. Depending on the type of VPN agent, we will have, I would say, different outcomes. So for Cisco, by default, it's five minutes of unlocked access. We must use the embedded browser. But the embedded browser has all HTTP features that you might need to establish a tunnel or to exfiltrate some data. For Pulsecure or the new name of Pulsecure is event T. Then it's not even restricted to the captive portal IP so you can have access to the full LAN as long as event T believes that you are behind a captive portal. But we are still forced to use the embedded browser. For Palo Alto, there is no restrictions on the binary that is authorized to connect on the network. So as long as you pretend you have a captive portal on the network, you can then use any binary, any program to connect on the network. And I'm just giving an example where we can simply use some HTTP form to upload some files on. It was very naive. You can use any other more convenient web server that you want to do some file sharing, to do your C2, whatever. It can work this way. Now I think it's time to move on to the most interesting attack, I believe, because it's definitely the most powerful one. It will completely unlock the network access. So as I mentioned, the trusted network detection for the vulnerable ones, again, I have to insist, Cisco made a night job because they are the only ones to propose something that is secure enough. But for the other one, it's either IP values or DNS values that are pushed in GHCP offers. And for some others, you also have to do some ping. Again, ping is trivial to spoof. So if we combine all this information, indeed, not only all these values can be spoofed, there is no authentication on these values, but they are also returned in clear in the logs or in the configuration, and they can also leak in the traffic. So you will be able to see all these values in the traffic. And if you made some assumptions, you do not even need to understand everything to actually spoof the trusted network detection. So we will try to pretend that our rogue network is the actual LAN, and you will see that it will be happy with it. So I'll just give you an example with Cisco that has not been configured with the trusted network, or the secure version. So it's not a TLS certificate there, but you can see that, okay, it will consider that we are not trusted network, while that's not the case, obviously. And then that the network access is available. Yes, this is what we want to do, even though the Divcon bank does not exist at all, but Cisco will be happy with what we give in our DHCP offers. So let's try to explore that. I will give the examples for the three. You will see that it's more or less the same. On the left we have, on the right, sorry, top right we have an extract of the eventy connection settings. So it is located at this pass. It is user readable, and you will find the connection policy there that is Boolean statement that will combine all the criterias, all the checks that are available. So if we want to avoid the VPN agent to force the connection, we just have to simply understand the Boolean logic here and try to inverse it. And we can do it one by one. So I will be using DNS mask as a DHCP server, as well as the DNS server. I will simply say that, okay, let's look at every values that is expected there, and I will propose everything so that eventy will believe that it's on the social network. So I will use host record. I will just write what is expected there. DHCP launch, I will write something that matches with what is expected there. On DHCP option six for the DNS server IP, I will just give it what it wants to read. If I do that, eventy will consider that the device is connected to the internal network and completely unlock the network access. So unfortunately for eventy, they only implement weak or spoofable trusted network detection check. DNS server, DNS A records on interface IP launch. And you can select and you can create a very big statement. Since it will only be composed of these spoofable checks, you will always be able to pretend you are the trusted network. Let's move on to the TND of Cisco. Again, if it is not configured with this secure trusted network, it will only use the trusted DNS domain on sometimes the IP address of the internal DNS domain. These values can be found in the profile, in an XML file at this location. And if you do that, it will be enough for Cisco to consider that, okay, this is indeed the trusted network. And since I like to work in a very convenient and easy way, I can also tell you that if you run this command, that works, but you can also avoid any conflicts with your already running DNS mask. And you can use that on the default hotspot features on any user friendly Linux distribution. If you put all these values there in the command line, you put them in the DNS mask shared configuration, it will peacefully run along the already running DNS mask, and you will not even need to run any commands actually to spoof the trusted network. And let's finish with Palo Alto because it's also vulnerable. This time, it will not be in the configuration because good for them. They decided to encrypt part of the configuration. Nice, unfortunately. The same values are leaking in clear text in the logs. So you will find everything you need as well. There you will see the IP on the name of the host. On little trick, it's not a DNS A record that is expected, it's a DNS PTR record. So it will require you to do some effort on to write the IP address in the inverse order. But once you do that, you are completely breaking free from the always on feature, and you have access to that. So just to show you this how quickly it can be in a short demo, on the left of the screen, you will see the target machine with Cisco VPN agent. And on the right, you will see my own Linux distribution with this DNS mask that is running. Okay, so I will first try with giving the nope.local, which is not the expected value. So we will see that when we do that, I'm trying some pings so that we can see the results almost in real time. You will see that we might get some ping response because of the grace period that I explained earlier because Cisco is amenable to that. Now since it is not the DHCP value, since it is not the internal DNS domain, we will see that Cisco is not happy about that. And we will definitely try to connect to the VPN gateway, which obviously does not exist for this one, but then I will try with what is expected on what I could see in the configuration file. I'm restarting my DHCP server with the DNS values that I want to push on after a few graphical glitches. Then we should be able to see that Cisco is happy with that. So we get the ping replies, meaning that the network is now completely unlocked, and I just want to see the graphical interface. Thanks. So it's now happy. Consider that we are on a trusted network. On that, we have completely unlocked the network access, and now we can do whatever we want. So again, we did not need to understand how it is completely implemented. I did not need to reverse anything to understand all that. I just had to read the documentation on to do some experiments with some assumptions. But we raised some questions. We have some discrepancies between the VPN agents. We have some things that did not work while we expected such DHCP or other protocols to work. It was not the case. So we will now need admin privileges just to try to understand how it works and try to get new attacks that might be working without privileges, okay? So let's have a look at behind the scene. Behind the scene is the Windows filtering platform. I'm not going to explain it at length there because there are other talks that will deep dive in this. You just have to understand that it is an API that is provided by Microsoft so that you can interact with the filtering engine of Windows. So the main idea is you have a provider that you can define. So it will be Cisco, Eventi, Palo Alto, for instance. They will open a session to the Windows engine, to the Windows kernel, basically. And then they will define some layers on sublayers which are network definitions. And then they will add, they will commit filters. And the filter will simply be something that you will define as, okay, you block this protocol from this IP to this port and you can define everything you want. The Windows firewall is actually using this API. So everything that is network filtering on Windows, on modern Windows platform, is using WFP. I'm showing there some API functions that we will be using later. So because it's using WFP, the Windows filtering platform, we already have some nice tools on Event1 that are already built in Windows. It's part of the NetSH command. You can use NetSH WFP on show filters and it will show you all the filters that are currently enabled on the system. You can see there that since I just run this command again, I have to be admin to execute this command. I will get, as an output, a nice XML file that is quite clear to understand. And I can see there the filter that is being committed by Event1 to block all the outgoing connections. So this is kind of an artifact of the always-on configuration there. And you will see that, okay, this is the name of the filter. This is connectV4, so it will block all the outbound connections on IPv4. And then the main action there is block with no condition. So this is kind of the most important rule of the VPN always-on feature. It will just block everything. So we can inspect all these rules with just a simple command. On the other tools that I want to talk about are WFP Explorer from Pavel Yosifovich on Jams4Show who made a lot of WFP functions available in his nice anti-object manager. Thanks to these two tools, we will be able to actually impact and change the rules or specifically delete some rules. So let's have a look at the WFP Explorer. This is just an attack. It's not an exploit. It's just to prove that it's just by deleting the filters that have been committed to the kernel, to the Windows filtering platform framework, we will be able to get our connectivity back. So I will obviously choose to delete this outgoing V4 rule. Okay, same situation. The tunnel is not established, so I'm in lockdown mode. I cannot connect to anything. I will just select the rule. You can see on the right that as soon as I delete the rule, then the connectivity is back for being to work. But again, that was just to demonstrate or to illustrate these filters. So now that we know what we have to look at, I used and I obviously tried to inspect all the filters so that I could maybe find some nice hard-coded values, some backdoors on some things that could be interesting. And I've done that with Palo Alto, even T. But for Cisco, it did not work. I could not see the filters that were implemented by Cisco for some reason. And it was kind of a big problem for me because I really wanted to see all these filters. So none of the filters implemented by Cisco would show up in the net-to-state WFP output. But by enabling the audit policy, you could have a look at all the things that are being made, all the changes that are being made on WFP. So we can definitely select some event logs that will show the fact that some filters are being committed. But on Cisco, they will commit filters very frequently. So it was very hard to follow. I really wanted to look at all the filters that were being implemented and being pushed to the platform live. So this is where I wrote some Frida scripts to hook all the calls to the API. It was quite long because I wanted to decode everything. Unfortunately, this was not necessary at all, but anyways, I'm using some codes to do that. I will show you this example. So I'm injecting in the VPN agent binary. What I want to do is simply to hook the filter add function based on that, then I will parse all the scripts, follow all the pointers, and so on, so that I can reconstruct the values that are being there pushed in the filters. So by the way, Cisco chose a very nice lead grid there, you can see. But again, I'm happy now because I can look at my filters directly in live, but it will not show up if I'm trying to ask the API after that. I finally get this weird answer that access is denied. So maybe this is why I could not see all the filters on Indeed. One subtlety of the WFP framework is that you can define some security descriptor that will block or reduce the access to the filters themselves, to the providers on everything that you can add to the filtering engine. This security descriptor is a nightmare to parse because it's with a lot of variables, some pointers, so it's really hard to do that. But I got the hint from James Forshohe himself to actually just dump the first values appointed by the security descriptor pointer, and then we will try to parse them automatically with his anti-object manager and try to format that as a security descriptor. And then we finally have this answer that if you want to look at all the filters that are being committed by Cisco, then you will see that system does not even have a read access to these filters. It only has write on delete access. If you want to read these filters, you will need to be local service because only local service has open on read. So we got our answer there, but it's not over. We still need to craft a token that will show that we can be local service. So again, kudos to James Forshohe who actually gave me the trick on Twitter when we discussed about that. And we can see there that we just need to define the token with the local service value there. So you can see that if I'm opening the engine without this token, then I get no results right here. Get filter. If for all Cisco filter, then I got no answer. But if I'm actually using the engine that I use, for which I open a session with the proper token, then I finally get all the filters. So that was kind of good news. Even if I spent several weeks writing something to dump in the function, I just had to do that. But anyways, I got my answers. The other ways to do that is since we are able to hook the functions, we can also try to change these values. So another alternative to do that is to either hook the function call on set the SID on the DACL to null so that everyone, every admin will get direct access to the filters or eventually you can use your admin access to first become owner of the object and then you will be able to change the DACL. So those are just some Pog code that I'm using as well as they are not so complex. But again, you need to be admin to do that. So now that we've managed to get the list of filters, we can now answer our questions if we take them one by one. DHCP was not usable at all because all the permit filters specify this true support as well. This is not possible on Windows if you do not have privileges. So this is why it could not work. The fact that we cannot use TCP DNS on TCP LMNR, well, that's similar. The permit filters are only defined for UDP protocols. The fact that we could not use even DNS tunnel with Eventi, it's because Eventi only permits a system process to be able to use the EDP 53 because with Windows filtering platform you can even define a user, a system, account groups and you can define who can access the network based on these values. And finally for the grace period that is not observable for Global Protect, it's because Global Protect is using persistent filters and not dynamic filters. So the filters are already there at all time and only when it's happy with the connection it will decide to remove that. So unfortunately I could not explain all the attacks that I managed to find, but if you see this table again I insist it's only unprivileged techniques. So I really want to be able to do this kind of break free exercise of VPN always on. But you can see that none of the VPN agent is perfect because they are always vulnerable to at least one of the attack that I explained there. I also found some hard coded values but you do not even need to do that because they are most of the time vulnerable to the trusted network detection which is in my opinion the most important one. The most flexible one. When it comes to recommendation, I try to prepare this talk with all the ideas that I have for detecting all the attacks that I could imagine or that I demonstrated but it's not practical at all. You have to do some correlation. ETW will not give you all the information that you are looking for so you will have to do a lot of things. So let's not waste our time on detection opportunities there and let's directly move on to the prevention part. The security agency in France wrote a very nice report which is full of guidelines and they are a bit extreme but I think that I agree with them. If you want to circumvent the captive portal problem then do not connect on always connect your laptop through a smartphone access point for instance. So you would use 3, 4, 5G just to avoid being connected to any Wi-Fi network that you do not trust. The other way to do that I think they are right you can use your smartphone that will connect to the captive portal and then your laptop will connect through the smartphone. I think that works quite well on Android devices I'm not sure for iOS. When it comes to the trusted network detection well they concluded well before me that most of the mechanisms are not secure except the one from Cisco that is relying on a certificate hash. And the other idea they have I think it's promising but not so convenient is to deploy an internal VPN gateway as well. In that case there will never be any notion of trusted network it will either be connected to the internal gateway or the external gateway. So it's a bit extreme but it works. On from the recommendation from this research I would say that from a configuration point of view for the blue team there you will need to check the access rights. You might want to change them because I use simple users have access to settings on logs and you might also consider looking at your TND on CPD settings. For the implementation issues well now that you get to know the various weaknesses of the VPN agents depending on your own provider you might consider changing a bit how you are configuring them and eventually you can consider deploying your own WFP filter but then you will need to know the API provided by Microsoft it is well documented but it's not so convenient so good luck with that. Key takeaways again as I said always can be a bit off sometimes definitely VPN agents are not securing the always on feature in the same way. None of them is perfect so you have to keep that in mind. Naive attacks work you do not need privileges you do not always need to have access to the laptop that you are attacking on all the information that you need for instance to do the Trusted Networks Poofing are found in files that are accessible to the low privileged user even sometimes on the packets themselves if you are able to do some man in the middle or just to look at what's happening on the wire. TND Spoofing again from my point of view is the most convenient on generic technique on for the rest most of the answers can be found in the documentation itself as well as in open source tools that are well made and that will give you all the answers that you need provided that you are able to look at the trap that I fault into with the Cisco settings. And finally IT admins have to consider configuration mistakes because even if we have weaknesses in the VPN agents themselves we also form in many occurrences the fact that the IT admins change the settings through the end user would also be able to change the profiles on the settings themselves so it's not demonstrated there but it is also something to consider. Thank you very much for your attention .