When an info leak on your VPN gateway is really a pre-auth credential dump

An improper-authentication vulnerability in an internet-facing security gateway, the kind now showing up in the CISA Known Exploited Vulnerabilities catalog for products like the Check Point Security Gateway, teaches a lesson responders keep relearning: an information-disclosure bug on the device that authenticates your users is not a low-severity file read. It is a pre-authentication credential dump. The attacker reads the gateway before ever logging in, walks off with the secrets that prove who your users are, and then signs in as one of them. By the time you notice, patching the appliance fixes almost nothing.

How it works

The gateway is reachable from the internet and running remote-access VPN. The flaw lets an unauthenticated caller send a crafted request to the VPN portal and receive appliance configuration and secret material in response, with no login required (T1190, Exploit Public-Facing Application). The gateway should never return secrets to a caller that has not authenticated, but the improper-authentication class does exactly that.

What comes back is the part that matters. An internet-facing VPN gateway stores the secrets it needs to authenticate everyone through it: local administrator password hashes, the VPN server certificate and its private key, and the LDAP bind account it uses to validate user logins against Active Directory. The disclosure hands those to the attacker (T1552, Unsecured Credentials). No brute force, no phishing, no malware on an endpoint. The read is the credential theft.

With a harvested credential the attacker authenticates to the remote-access VPN as a real domain user (T1133, External Remote Services, and T1078, Valid Accounts). The login is clean: a first-try success from a new IP with no failed attempts. From that foothold the session sweeps the internal network, enumerating hosts and privileged groups (T1046, Network Service Discovery) while blending in as ordinary VPN traffic.

Why an info leak is a credential dump

The non-obvious insight is that the gateway is not just a network device. It is an identity device. It holds the material that authenticates users and back-end integrations, so anything that can read it can impersonate them.

Two of the disclosed secrets are worse than the rest. The VPN certificate and any local account hashes let the attacker present as the gateway or as a local admin. The LDAP bind account is worse still: it is a domain credential, and it reaches past the appliance into Active Directory. A leak that starts as an appliance file read now includes a directory-integration credential in an attacker’s hands.

And a leaked credential does not care that you patched. Patching closes the read, but the secret already walked out the door and it stays valid until you rotate it. This is the property most responders underestimate. You apply the vendor fix, you confirm the disclosure endpoint stops responding, and you feel contained. You are not. The attacker keeps signing in with a real, harvested credential and looks exactly like a normal user while you believe the incident is closed.

How to detect it

The disclosure signal is a response that should never exist. An internet-facing VPN portal takes probes all day, so TLS handshakes, served login pages, and CPU load from a new IP are all normal noise. The tell is a pre-authentication request that draws a response containing configuration or secret material, with no successful login tied to that session. An unauthenticated caller receiving secrets is the unambiguous signal.

The login signal is the sequence that follows. Correlate the gateway VPN authentication log with Active Directory sign-ins, filtered to the exposure window. A clean first-try VPN success from a new IP or geography, with no failed attempts before it, is the signature of a harvested credential in use. The vendor advisory tells you what could leak. The VPN authentication log tells you who actually logged in.

How to contain and shut it down

This is the part people get wrong. Patching the appliance closes the read, but it does not invalidate a single secret that already leaked. Isolating the one gateway is not containment. Treat every credential the gateway stored or could disclose as burned:

• Patch the appliance and confirm the pre-auth disclosure endpoint no longer returns secret or configuration material.
• Reissue the VPN server certificate and distribute the new one.
• Reset the Active Directory bind account and any other domain credential the gateway held.
• Rotate the local administrator secret and any cached user secrets on the appliance.
• Hunt the VPN authentication log against AD sign-ins across the exposure window for clean first-try successes from new IPs or geographies with no failed attempts, and scope every session that used a harvested credential.

Then recover carefully. Do not restore the appliance from its pre-incident configuration backup: that backup contains the very secrets the attacker holds, and restoring it hands them back their access. Bring the VPN back only after the appliance is patched and every disclosed secret is replaced, then force re-authentication and confirm no session is still riding an old credential.

Eradication closes the class, not the one box. Inventory every internet-facing gateway for the same disclosure pattern, minimize the standing secrets stored on the appliance where you can, scope the AD bind account to least privilege so a leak is low-value, and require certificate-plus-MFA on remote-access VPN so a single harvested credential is not enough to complete a login. Obligations follow what the trusted VPN sessions could reach, not the appliance bug that started it.

Practice it

We built this as a scenario in GraphLattice Range: an unauthenticated read against a remote-access VPN gateway that discloses the local admin hash, the VPN certificate, and the AD bind account, followed by a clean VPN login on a harvested credential and internal recon. It forces the non-obvious call under time pressure. Patch the box and confirm the endpoint is closed, or recognize the info leak as a pre-auth credential dump, rotate everything it disclosed, and hunt the VPN logs. Teams that have made that call in a drill make it faster when it is real.