Pivoting Through the DMZ: Why Your Jump Server Is Just a Speed Bump

TLDR: Attackers are bypassing multi-factor authentication in OT environments by exploiting misconfigured jump servers and exposed management services like WinRM and SMB. By leveraging RDP session hijacking and hidden desktop sessions, they can move laterally from IT to OT without needing valid credentials for the target systems. Security teams must move jump servers behind strict firewall rules and monitor for suspicious session management events to prevent these silent pivots.

Most security professionals treat the jump server as the ultimate gatekeeper between the enterprise IT network and the Operational Technology (OT) DMZ. We assume that if we force users through a hardened gateway with multi-factor authentication, we have effectively neutralized the risk of lateral movement. This assumption is dangerous. Recent engagements show that once an attacker gains domain admin rights in the IT environment, the jump server often becomes the primary target for pivoting, not because it is inherently weak, but because the surrounding network design is riddled with implicit trust.

The Mechanics of the Pivot

Pivoting into an OT environment is rarely about finding a single zero-day exploit. It is about exploiting the path of least resistance. When an operator logs into a jump server five days a week, they rarely want to re-authenticate every time they switch tasks. This leads to saved RDP credentials and persistent sessions that are ripe for harvesting. Using tools like SharpDPAPI or Mimikatz, an attacker with local admin access on a compromised workstation can extract these cleartext credentials or session tokens.

Once the attacker has a foothold on a jump server, the game changes. They are no longer an outsider; they are a trusted entity inside the DMZ. From here, they can perform RDP session hijacking. If a legitimate user has an active session, the attacker can use the built-in tscon command to attach their own session to the existing one. This bypasses MFA entirely because the session is already authenticated. The attacker effectively inherits the user's desktop, their permissions, and their access to the OT network.

Beyond Standard Hijacking

While session hijacking is effective, it is not always stealthy. A more sophisticated approach involves Remote Desktop Shadowing. By modifying the registry to allow shadowing without user consent, an attacker can observe or interact with a user's session in real-time. This is particularly effective for gathering intelligence on how operators interact with HMI (Human Machine Interface) systems.

For those who need to operate completely under the radar, Hidden Desktop (hVNC) implementations are the gold standard. By running a hidden instance of the desktop, an attacker can execute commands, open files, and interact with the system while the legitimate user remains completely unaware. The White Knight Labs implementation of hVNC is a prime example of how this can be achieved. Because this technique relies on standard Windows APIs to create and switch desktops, it often evades traditional signature-based detection.

The Insecure Network Design Trap

The most common failure point is not the jump server itself, but the services exposed alongside it. Many organizations implement MFA on the RDP port but leave SMB, DCOM, or WinRM open to the entire IT subnet. This is a critical Identification and Authentication Failure. An attacker does not need to RDP into the jump server if they can use WinRM to execute commands remotely or use SMB to move files and tools.

During a penetration test, I often see jump servers that are dual-homed or have routes that allow them to communicate with management interfaces on switches, routers, and UPS devices. If these devices have default credentials or weak access controls, they become the perfect bridge into the OT environment. Once you have access to a network switch, you can sniff traffic, perform ARP spoofing, or simply reconfigure the network to grant yourself access to restricted segments.

Hardening the Perimeter

Defending against these techniques requires a shift in how we view the DMZ. First, stop treating the jump server as a standalone solution. It must be placed behind a strict firewall that denies all traffic except for the specific protocols required for the jump. If you are using RDP, ensure that only RDP is allowed. If you need to manage other devices, use a separate, dedicated management network that is physically or logically isolated.

Detection should focus on the behavioral anomalies associated with these attacks. Monitor for the execution of tscon.exe or shadow.exe by non-administrative accounts. Look for unexpected logon types, specifically Type 10 (Remote Interactive) or Type 7 (Unlock), that occur without a corresponding logoff event. If you see a user session being hijacked or shadowed, it is almost certainly malicious.

Finally, audit your Active Directory environment to ensure that IT and OT identities are strictly separated. A compromise in the IT domain should not grant an attacker the keys to the OT kingdom. Use separate forests or at least separate administrative groups with no trust relationships that allow for lateral movement. The goal is to make the cost of moving from IT to OT so high that an attacker is forced to make noise, giving your SOC the chance to catch them before they reach the critical infrastructure. Stop relying on the jump server as a magic bullet and start building a network that assumes the jump server will eventually be compromised.