Handle Duplication

What handle duplication actually changes

Handle duplication is not a new object, it is a new reference to an existing kernel object with whatever access rights are carried forward or intentionally trimmed. That matters because the security outcome is determined by the rights on the duplicated handle, not just by who originally opened the object. A duplicated handle can therefore preserve, extend, or redistribute access across process and thread boundaries.

In practice, the technique is part of how Windows shares access to files, processes, tokens, events, and similar objects between cooperating components. It is useful for coordination, but it also creates a trust decision: if the source handle is more powerful than the recipient should have, duplication can become a privilege or containment problem.

How handle duplication works in Windows

Handle tables are process-scoped bookkeeping for kernel objects. When a handle is duplicated, the destination process receives a distinct handle value that points to the same underlying object, often with a potentially different access mask depending on how the duplication was performed. The object itself is not copied, so state changes on the underlying object are visible through any valid handle to it.

This design is efficient, but it means the system is trusting the caller to decide which access should survive the transfer. If a privileged process duplicates handles too broadly, or if a less-trusted process gains access to a handle it should not have, the resulting access may be stronger than intended even though no new object was created.

Why duplicated handles matter for access and privilege

Handle duplication becomes security-relevant when the handle targets an object whose access is sensitive: a process handle can enable inspection or termination, a token handle can support impersonation or privilege use, and a file handle can expose data that should have stayed isolated. The impact is often indirect, because the duplicated handle is a bridge to the underlying authority already attached to the object.

The key governance issue is least privilege. A duplicated handle can outlive the original design intent of a process boundary, especially when handles are inherited, passed between services, or exposed through brokered workflows. In those cases, handle management becomes part of access control, not just an implementation detail.

Common failure modes and defensive handling

Security issues usually arise when developers assume that process isolation alone is enough. A child process, plugin, helper thread, or injected component may inherit or receive handles that provide more access than the designer expected. Problems also emerge when applications fail to close handles promptly, reuse them across trust boundaries, or duplicate them with rights that are convenient for functionality but broader than necessary.

Defensive design is about narrowing who can duplicate, what can be duplicated, and which access survives the transfer. That usually means treating handle passing as a controlled interface, reviewing inherited handle paths, and checking whether a component really needs direct object access or only a limited operation exposed through a safer abstraction.

Risk and Threat Considerations

Duplicated handles can become a lateral movement or privilege-abuse path when an attacker already has some execution in a process that can open or inherit powerful handles. The risk is highest when a sensitive object, such as a token or privileged process, is reachable through a handle that was meant only for an internal trusted component.

Failure mechanism: An attacker abuses inherited, leaked, or over-duplicated handles to reuse the authority of a more privileged process or object, bypassing normal access separation.

Impact: The result can be unauthorized data access, process tampering, impersonation, or persistence through trusted object access that defenders did not expect to remain reachable.

Practitioner Guidance

What to watch for: Handle duplication should be reviewed anywhere a process boundary, service boundary, or trust boundary is crossed. If a design depends on “safe” inheritance by default, it is usually worth rechecking which objects are actually exposed and whether that exposure is still justified.

Governance implication: Treat handle passing as a security-sensitive interface, not as plumbing. The ownership question is whether the component that duplicates or inherits the handle is also accountable for the rights that travel with it, especially when the handle references privileged or long-lived objects.

Related resources from NHI Mgmt Group

• How should security teams handle risks from AI browser extensions?
• How should security teams handle AI agent visibility?
• How should teams handle secrets that have no obvious owner?
• How should security teams handle leaked secrets across developer workflows?