1723 - Pentesting PPTP

Basic Information

Point-to-Point Tunneling Protocol (PPTP) is an old VPN tunneling protocol used for remote access. It uses TCP port 1723 for the control channel and IP protocol 47 (GRE) to carry the PPP payload. The traffic inside the tunnel is commonly protected with MPPE, while authentication is frequently based on MS-CHAPv2.

From an offensive perspective, the interesting part is usually not the control connection itself but the fact that capturing a PPTP/MS-CHAPv2 handshake can enable offline password or NT-hash recovery. Also remember that a host can answer on TCP/1723 while the tunnel still fails because GRE (protocol 47) is filtered.

Default Port:1723

Enumeration

nmap -Pn -sSV -p1723 <IP>
nmap -Pn -sO --protocol 47 <IP>

If you only confirm tcp/1723 and miss GRE, you can easily get a false sense that the VPN is reachable. During troubleshooting or sniffing, capture both the control and encapsulated traffic:

sudo tcpdump -ni <iface> 'tcp port 1723 or gre' -w pptp-handshake.pcap
tshark -r pptp-handshake.pcap -Y 'pptp || gre || ppp || chap'

If you are capturing on the VPN endpoint itself instead of from a SPAN/mirror port or another on-path vantage point, keep in mind that local PPP capture can be incomplete. On Linux in particular, normal libpcap capture on the PPP interface may miss PPP control traffic; for local troubleshooting you may need to capture the GRE packets on the physical interface or use pppd record style logging to preserve the control exchange.

Brute Force

Attack Notes

MS-CHAPv2 handshake capture

For PPTP, the relevant material is the PPP authentication exchange transported inside GRE. In MS-CHAPv2 the response depends on:

The server AuthenticatorChallenge
The client Peer-Challenge
The username
The NT-Response

That means a packet capture is often enough to move the attack offline. If you can sniff the initial connection, request the user to reconnect, or position yourself on-path, capture the handshake and extract the challenge/response data.

Useful quick filters:

tshark -r pptp-handshake.pcap -Y 'chap'
tshark -r pptp-handshake.pcap -Y 'ppp and chap'

Convert the handshake into a `hashcat` workload

For PPTP/MS-CHAPv2, the 24-byte NT-Response alone is not the full story. Per RFC 2759, the effective 8-byte challenge is derived from:

The server AuthenticatorChallenge
The client Peer-Challenge
The UserName

In practice, this means you need to preserve those fields during extraction if you want to move from a packet capture into a modern GPU workflow. A useful pattern is:

Parse the capture with chapcrack or tshark
Extract the username, peer-challenge, authenticator challenge, and NT-Response
Convert the result into a hashcat-compatible NetNTLMv1/ESS style line

The exact hashcat representation commonly used for MS-CHAPv2 is:

<user>::<domain_or_blank>:<peer_challenge>:<nt_response>:<authenticator_challenge>

Example attack:

hashcat -m 5500 -a 0 mschapv2.hashes /usr/share/wordlists/rockyou.txt

This is operationally useful when you want to keep everything local instead of sending a token to an external cracking service, or when you already have a tuned hashcat rules/masks workflow.

Parse and decrypt with `chapcrack`

chapcrack is still one of the cleanest ways to process a PPTP capture:

chapcrack.py parse -i pptp-handshake.pcap

If you recover the underlying secret material, you can decrypt the PPTP packet capture:

chapcrack.py decrypt -i pptp-handshake.pcap -o pptp-decrypted.pcap -n <recovered_nt_hash_or_token>

This is especially useful when the goal is not only credential recovery but also session decryption and post-auth traffic analysis.

Crack challenge/response material

If you already extracted the challenge/response pair, asleap can still be used directly against PPTP/MS-CHAPv2 material:

asleap -C 58:16:d5:ac:4b:dc:e4:0f -R 50:ae:a3:0a:10:9e:28:f9:33:1b:44:b1:3d:9e:20:91:85:e8:2e:c3:c5:4c:00:23 -W /usr/share/wordlists/rockyou.txt

asleap also supports working from packet captures or precomputed lookup tables, but for PPTP assessments the most common workflow is:

Capture the PPTP handshake
Extract the challenge/response
Run offline cracking with asleap, chapcrack, or a custom workflow

Recent tradecraft also includes NT-hash-first workflows such as assless-chaps, which recover the NT hash from MS-CHAPv2/NTLMv1 challenge-response material using a prepared hash database. This can be faster than conventional password cracking if you maintain a good NT-hash corpus:

./assless-chaps <challenge> <response> <hashes.db>

This matters because for PPTP the recovered NT hash is operationally valuable by itself: once obtained, it can be used to validate the crack, decrypt captures, and pivot into Windows-oriented reuse checks.

If you plan to use this at scale during assessments, the practical bottleneck is usually not the cracking step but maintaining a good NT-hash database. assless-chaps becomes especially useful when you can prebuild SQLite databases from breached NTLM corpora, HIBP-derived NT hashes, or aggressive in-house rule expansions generated with hashcat.

Protocol weakness summary

PPTP depends on a separate GRE data channel, so firewalls often expose tcp/1723 while silently breaking the tunnel.
MS-CHAPv2 security effectively collapses to recovering DES-derived material / NT-hash-equivalent secrets, making passive capture much more dangerous than with modern VPNs.
Even if the password is not immediately recovered, the handshake can usually be stored and attacked offline later.