The Secure Socket Tunneling Protocol (SSTP) is widely deployed in Windows-based VPN solutions because it tunnels PPP over HTTPS, allowing VPN traffic to traverse restrictive firewalls and proxies by using TCP port 443. For incident responders and forensic analysts, SSTP presents both opportunities and challenges: the encapsulation in TLS/SSL hides payloads, but rich server-side and endpoint logs, combined with network capture and metadata like JA3/TLS fingerprints, can enable rapid threat detection and reconstruction of attacker behavior. This article provides a technical, actionable guide to SSTP log analysis for incident response, detailing sources, parsing approaches, correlation strategies, and practical commands and queries to accelerate forensic investigations.

Understanding SSTP Protocol Artifacts

SSTP encapsulates a PPP session inside an SSL/TLS connection. Key artifacts that can be leveraged for detection and forensics include:

  • TLS metadata: SNI, certificate subject and fingerprint, TLS version, cipher suite, JA3/JA3S fingerprints.
  • Network metadata: Source/destination IPs and ports (typically TCP/443), connection durations, bytes transferred, TCP sequence anomalies.
  • PPP/Login-level logs: Username, authentication method (MS-CHAPv2, PAP, EAP), authentication success/failure, assigned IP address.
  • System and event logs: Windows RRAS (Routing and Remote Access), IIS/HTTP.sys logs (when SSTP is fronted by HTTP service), Security event log entries for logons and account lockouts.
  • Packet captures: If TLS is not decryptable, timing and size patterns; if keys are available, decrypted PPP frames yield credentials and payloads.

Log Sources and Key Event Identifiers

Collecting the right logs quickly is essential. Prioritize these sources during an investigation:

Windows RRAS and Event Logs

RRAS logs on the VPN server contain connection lifecycle events. Useful event IDs and message types include:

  • Event ID 20226 — SSTP connection started (often from rasman/RRAS logs).
  • Event ID 20227 / 20228 — SSTP connection terminated or session errors.
  • Security event IDs related to authentication: 4624 (successful logon), 4625 (failed logon), 4740 (account lockout).
  • RADIUS/NPS server logs — Access-Accept, Access-Reject, and accounting records including NAS-IP-Address, Framed-IP-Address, and username.

Use PowerShell to extract RRAS events quickly:

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-RemoteAccess'; StartTime=(Get-Date).AddDays(-7)} | fl TimeCreated, Id, LevelDisplayName, Message

IIS / HTTP.sys and TLS Termination Logs

When SSTP is terminated via HTTP.sys or fronted by IIS/reverse proxies, request-level logs can contain the TLS SNI, client IP, timestamp, and the initial CONNECT/POST that initiates the SSTP handshake. Ensure extended logs capture client certificate and SSL cipher information if configured.

RADIUS / NPS Logs

RADIUS provides authoritative authentication and accounting records. Key fields to collect include:

  • User-Name
  • NAS-IP-Address
  • Calling-Station-Id (client IP/MAC)
  • Acct-Session-Id
  • Framed-IP-Address

These fields are crucial for mapping an SSTP session to a user identity.

Network Captures and TLS Metadata

Full packet captures are invaluable. If you cannot decrypt TLS, extract metadata with tools like tshark, Zeek (Bro), or Suricata:

Example tshark to extract TLS client hello fingerprints (JA3):

tshark -r capture.pcapng -Y "ssl.handshake.type==1" -T fields -e ip.src -e ip.dst -e tcp.srcport -e tcp.dstport -e ssl.handshake.extensions_server_name -e tls.handshake.version -e tls.handshake.ciphersuite -e ja3

Zeek produces tls.log with ja3 and certificate subject fields, which you can correlate with RRAS events.

Practical Detection Techniques

Rapid detection should emphasize anomalies in authentication and connection patterns rather than relying solely on content. Consider these approaches:

Authentication Anomalies

  • Multiple failed authentications followed by success for the same account (indicative of credential stuffing or brute force).
  • Authentication from geographically disparate IPs in short time windows.
  • New device fingerprints (client IP + user agent + assigned framed-IP) for privileged accounts.

Splunk example to find multiple failed attempts:

index=vpn sourcetype=radius (Access-Reject OR Access-Challenge) | stats count by User-Name, src_ip | where count > 5

TLS Fingerprint and Certificate Anomalies

Attackers sometimes use custom VPN clients or malicious proxies with non-standard TLS stacks. Monitor for unusual JA3 fingerprints or self-signed certificates used in production environments:

  • New JA3/JA3S values for SSTP endpoints.
  • Certificates with short-lived validity or mismatched CN/SAN compared to expected server names.

Session Behavior and Data Exfiltration Patterns

Even without payload visibility, session timing and byte counts can flag exfiltration:

  • Long-lived SSTP sessions with high outbound data from a user who normally has short interactive sessions.
  • Patterns of small packets at regular intervals (beacons) within SSTP sessions.

Elasticsearch/Kibana query example for long sessions:

event.type:connection AND proto:tcp AND dst.port:443 | stats sum(bytes) as totalBytes, max(duration) as maxDuration by src_ip, user

Forensic Reconstruction Steps

When an incident is suspected, follow a methodical workflow to preserve evidence and reconstruct the attack path:

1. Preserve Volatile Data

  • Export current RRAS and RADIUS sessions, including active session lists and assigned IPs.
  • Capture memory from the SSTP server if you suspect private keys or session secrets may be recoverable (rare but possible for ephemeral forensic work).

2. Collect Relevant Logs and Packet Captures

  • Aggregate Windows Event Logs, RADIUS logs, reverse proxy logs, and any IDS/NSM alerts.
  • Acquire full packet captures for the time window. Use tcpdump: tcpdump -i eth0 -w sstp_capture.pcap port 443 and host 198.51.100.10

3. Correlate and Enrich

  • Map RADIUS session IDs to RRAS assigned IPs and packet capture flows by matching framed-IP fields and NAT mappings.
  • Enrich IPs with geolocation, ASN, and historical threat intelligence (malicious IP lists).

4. Attempt Decryption (If Feasible)

Decryption is only possible when you have server private keys for RSA key exchange or retained session keys (e.g., SSLKEYLOGFILE from the client). If the server uses ephemeral Diffie-Hellman (ECDHE), decryption without session secrets is infeasible.

  • OpenSSL RSA-based decryption option (rarely applicable): configure Wireshark with the server PEM to decrypt TLS.
  • If you can obtain NSS/Chrome session keys: load the SSL key log file into Wireshark to decrypt TLS and extract PPP frames.

5. Extract PPP and Authentication Artifacts

Once decrypted, you can parse PPP frames to find MS-CHAPv2 handshakes, CHAP challenge/response, and even plaintext credentials if PAP was used (insecure). Tools like John the Ripper or Hashcat can brute-force MS-CHAPv2 hashes, though MS-CHAPv2 is considered weak against offline cracking.

Parsing and Automation: Regexes, Scripts, and SIEM Queries

Automation reduces time to detection. Examples below show practical extraction patterns and queries.

Regex to Extract User and Framed IP from RADIUS Logs

Sample regex for line-based logs:

User-Name:s(?P<user>[^s,]+).Framed-IP-Address:s*(?P<ip>d{1,3}(?:.d{1,3}){3})

tshark to Extract SSTP-Related TLS Metadata

tshark -r sstp.pcap -Y "tcp.port==443 and ssl" -T fields -e frame.time -e ip.src -e ip.dst -e tcp.srcport -e tcp.dstport -e tls.handshake.extensions_server_name -e tls.handshake.ciphersuite -e ja3 -E separator=, > tls_meta.csv

Example Zeek Script Hook

Use Zeek to generate a focused log of SSTP candidate connections (based on port and HTTP POST pattern):

In local.zeek:


event tcp_packet(c: connection, is_orig: bool, flags: string) {
  if (c$id$resp_p == 443/tcp) {
   &nbsp# heuristics: look for POST /sra_{...} typical of SSTP start
   &nbsplocal payload = c$orig$raw?$payload ? c$orig$raw$payload : c$resp$raw$payload;
   &nbspif (payload && payload =~ /POSTs+/sra_{/) {
     &nbspprint fmt("SSTP-candidate: %s -> %s %s", c$id$src_ip, c$id$dst_ip, c$id$start_time);
    }
   }
}

Common Pitfalls and Mitigations

Be aware of challenges:

  • TLS encryption: prevents deep packet inspection without keys. Focus on metadata and logs when decryption isn’t possible.
  • NAT and load balancers: can obscure the true client IP. Correlate with load balancer logs and X-Forwarded-For headers where applicable.
  • Incomplete logging: many default deployments do not enable verbose RRAS or RADIUS accounting. Ensure these are enabled proactively for incident readiness.

Response Playbook Summary

A concise action list for responders:

  • Identify suspicious SSTP sessions via TLS/JA3 anomalies and unusual authentication patterns.
  • Preserve server and RADIUS logs, and capture network traffic for the relevant time window.
  • Map session metadata to user accounts and endpoint telemetry (EDR, sysmon logs).
  • Attempt to decrypt TLS only if legitimate keys or session secrets are available; otherwise, rely on metadata analysis.
  • Contain compromised accounts by revoking sessions, resetting credentials, and blocking malicious IPs at the edge.
  • Perform post-incident hardening: enable full accounting, increase logging retention, and consider multi-factor auth to mitigate credential-based SSTP abuse.

In modern incident response, SSTP log analysis requires combining system logs, authentication records, and network metadata to compensate for TLS-encrypted payloads. By instrumenting RRAS, RADIUS/NPS, proxies, and network sensors, and by automating extraction of TLS fingerprints and session metadata, teams can detect SSTP misuse quickly and perform reliable forensic reconstruction.

For more operational guidance and tools that integrate with these techniques, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/