The VPN Let Them In. The Zero-Day Kept Them There

On April 15, 2026, at 13:44 UTC, an attacker connected to a corporate FortiGate SSL VPN from an IP address geolocated to Russia. No vulnerability was exploited. No zero-day was needed. The attacker had the right username and password, and the VPN let them in.

Everything that followed - the privilege escalation, the antivirus bypass, the persistent backdoor, the open outbound tunnel - was only possible because of that first step. A stolen credential. An open door.

The credential was the vulnerability

VPN authentication works on a simple premise: the right credentials prove you are the right person. This premise breaks the moment credentials are stolen. Phishing, credential stuffing, dark web purchase, prior breach- the method does not matter. Once an attacker has valid credentials, the VPN cannot distinguish them from the legitimate user.

In this case, the attacker authenticated successfully and was granted the same network access as the account owner. From that position inside the network, they staged a toolkit in user-writable directories and began hands-on reconnaissance: whoami /priv, cmdkey /list, net group. The cmdkey command lists stored credentials on the machine - meaning the attacker was immediately looking for more credentials to extend their reach.

The multi-geography follow-on sessions tell the same story. After the initial Russian connection, additional unauthorized sessions from Singapore and Switzerland were tied to the same account. The credential had been shared, sold, or used across infrastructure. One stolen password, multiple actors, one open network.

The zero-day with no patch

The attacker arrived with a toolkit built from recently leaked exploit code published by a researcher known as Nightmare-Eclipse. The researcher had followed responsible disclosure, reported the vulnerabilities to Microsoft, and then published them publicly as a protest against Microsoft's handling of the disclosure process. The code was on GitHub. Within days, it was being run against a live target.

The toolkit contained four components. Three are relevant here.

RedSun is the one that has no fix. It targets a missing reparse point validation in MpSvc.dll, the core Windows Defender Malware Protection Engine. The attack chains four legitimate Windows features: Opportunistic Locks, the Cloud Files API, Volume Shadow Copy, and Junction Points. The result is SYSTEM-level code execution by an unprivileged user, achieved by turning Windows Defender against itself. No kernel exploits. No administrator interaction required. Roughly 100% reliable. As of publication, Microsoft has released no patch. Every fully updated Windows system in the world is vulnerable.

BlueHammer (CVE-2026-33825) targets a time-of-check to time-of-use flaw combined with volume shadow copy manipulation to extract credentials from the Windows Security Account Manager. It achieves SYSTEM privileges on standard Windows and administrator elevation on Windows Server. Microsoft patched this in April 2026, but patch deployment takes time. Many environments had not applied it when this intrusion occurred.

UnDefend uses directory change notifications to lock Defender's signature files, preventing the antivirus engine from updating its definitions. With Defender blinded, the other tools operate without interference.

The open tunnel

The component that succeeded completely was BeigeBurrow, a custom Go-compiled tunneling agent. It established a persistent reverse connection to a command-and-control server at staybud.dpdns.org using HashiCorp's yamux library for multiplexed TCP relay. The tunnel was outbound, encrypted, and active.

BeigeBurrow works independently of the VPN. The VPN was the entry channel — the attacker came in through it. BeigeBurrow is a separate outbound connection, initiated from inside the network directly to the attacker's C2 server over TCP. Once the attacker was inside, the VPN was no longer needed. BeigeBurrow created its own persistent path out.

With that tunnel established, an active session inside the network, and reconnaissance commands already returning results, the infrastructure for data exfiltration was in place. Whether data left the network in this specific incident was not confirmed by Huntress's analysis. What was confirmed: the outbound channel was open, it bypassed the perimeter entirely, and it was operating from a position the VPN had granted.

What stopped it

The privilege escalation tools did not fully succeed. [LINK 1: https://www.huntress.com/blog/nightmare-eclipse-intrusion] BlueHammer was detected and quarantined. UnDefend was executed with a syntax error — the operator typed -agressive instead of the correct flag — suggesting the attacker was working with tools they did not fully understand. The intrusion was detected and investigated before the toolkit achieved its objectives.

This was not a security architecture victory. It was operational error on the attacker's side.

The architecture that created the exposure

The Nightmare-Eclipse intrusion is documented evidence of a failure pattern that repeats across breach reports: a VPN credential is stolen, an attacker gains network-level access, and the subsequent attack — lateral movement, privilege escalation, persistence, exfiltration — proceeds through infrastructure that was meant to be secure.

RedSun has no patch. Credential theft has no patch. These are not problems that a software update will resolve. They are structural properties of an architecture that grants network access based on credentials and relies on endpoint software to detect what happens next.

This incident had two distinct failure points, and they are worth treating separately.

The first is the entry. A stolen credential gave the attacker a routable network path inside the organization. Hardware-enforced remote access eliminates this failure point entirely. There is no VPN endpoint to authenticate against, no credential that grants network access, no IP path into the protected environment. Stolen credentials have nothing to open.

The second is the exfiltration channel. BeigeBurrow established an outbound TCP connection from inside the network to a remote C2 server. This connection required a routable IP path out of the organization. In an environment where the only remote access mechanism is hardware-enforced — where only pixel video exits the protected network and only keyboard and mouse input enters at the physical layer — that outbound TCP connection cannot be formed. Not filtered by a rule. Not blocked by a policy. The IP path does not exist. BeigeBurrow has no channel to establish.

Zeroport eliminates both failure points. Not by adding another layer of controls on top of a VPN, but by replacing the architecture that made both possible.

The gap between when Nightmare-Eclipse published and when attackers were inside a live network was five days. The gap between a stolen credential and full network access is measured in seconds. The gap between hardware-enforced access and this attack pattern is architectural.

‍