Lateral movement across a workstation can turn a single compromised account into a full‑blown breach.
In many organizations the default is to hand every engineer a local administrator account, to share privileged passwords over chat, and to leave Remote Desktop Protocol (RDP) or SSH ports open on every machine. Those accounts are often long‑lived, never rotated, and used to install software, change configurations, or troubleshoot issues. When an attacker gains one of those credentials, they can log in, gain higher privileges, and then hop to any other system that trusts the same credentials. The result is a chain of compromise that spreads far beyond the original foothold, and because the connections are direct, there is no central log of what commands were run or what data was read.
The immediate fix that most teams reach for is to tighten the identity layer: enforce multi‑factor authentication, rotate passwords, and assign roles that limit what a user can do on a single host. Those steps stop the initial credential theft, but they do not change the fact that once a user is authenticated, the request still travels straight to the operating system. The operating system sees a trusted user and executes every command without a second look. There is no inline inspection, no just‑in‑time approval, and no recording of the session for later review. In other words, the attack surface that enables lateral movement remains intact.
Why lateral movement matters for computer use
When an attacker can move laterally, they can harvest credentials, exfiltrate data, and embed persistence mechanisms on multiple hosts. The blast radius expands from a single endpoint to an entire subnet, a data center, or even a cloud VPC. Auditors ask for evidence that every privileged command was authorized and that any sensitive output was protected. Without a control point that sits between the identity and the host, those questions cannot be answered definitively.
How hoop.dev stops lateral movement
hoop.dev acts as a Layer 7 gateway that proxies every RDP, SSH, or similar session before it reaches the computer. The gateway sits in the data path, so it is the only place where enforcement can happen. Because the connection is routed through hoop.dev, the system can apply just‑in‑time access, require an explicit approval for risky commands, mask sensitive fields in command output, and record the entire session for replay.
When a user presents an OIDC or SAML token, hoop.dev validates the token, extracts group membership, and decides whether the request is allowed. If the request is allowed, hoop.dev forwards the traffic to the target machine; if the request involves a high‑risk operation, hoop.dev can pause the flow and ask a designated approver to grant temporary permission. All commands that pass through the gateway are logged with the identity that issued them, and the output can be sanitized in real time to prevent leakage of secrets.
Enforcement outcomes provided by hoop.dev
- Session recording and replay, giving investigators a complete view of what happened.
- Command‑level audit that ties every action to a specific identity.
- Inline masking of sensitive data such as passwords or tokens that appear in command output.
- Just‑in‑time approval workflows that stop dangerous commands until a human signs off.
- Blocking of disallowed commands before they reach the operating system.
All of these outcomes exist only because hoop.dev occupies the data path. The setup, identity federation, role assignment, and credential provisioning, decides who may start a session, but it does not enforce policy on its own. By placing the gateway between the user and the computer, hoop.dev ensures that every lateral‑movement attempt is visible, controllable, and auditable.
Getting started with hoop.dev
To try the approach, follow the getting started guide and deploy the gateway in your network. The documentation explains how to connect the gateway to your identity provider, register a host, and enable the default guardrails for SSH and RDP. For a deeper dive into masking, approval policies, and session replay, see the feature documentation. The project is open source, so you can review the code or contribute improvements on GitHub.
FAQ
Does hoop.dev replace my existing password management process?
No. hoop.dev consumes the identities that your organization already issues. It does not store or manage passwords; it simply ensures that any privileged session that uses those identities is inspected and recorded.
Can an attacker bypass hoop.dev by connecting directly to a host?
If network segmentation is configured so that the host is reachable only through the gateway, bypass is impossible. The gateway becomes the sole ingress point for privileged protocols, which is the core of the defense.
What happens to session data after recording?
Recorded sessions are stored in a location you configure, and access to those logs is governed by the same identity checks that control live sessions. This provides a reliable audit trail for compliance and forensic analysis.
By moving the enforcement point into the data path, hoop.dev turns a flat, unmonitored connection into a controlled, observable workflow, dramatically reducing the risk of lateral movement across your fleet.
