What happens when organisations allow shared drives in RDP sessions without tight controls?

Why Shared Drive Mapping in RDP Turns a Support Session into a Write Path

Shared drives in RDP are convenient because they let a technician move logs, installers, and diagnostics between endpoints. The problem is that the redirect is usually bidirectional unless it is tightly constrained. If the remote endpoint can write into a drive that the technician later opens or executes from, the session stops being just remote support and becomes a file-injection path.

The security issue is not the drive feature itself, but the trust boundary it creates. A lower-trust system is being allowed to stage content on a higher-trust workstation, and that content may survive past the session boundary. If the technician account has broader access, the attacker inherits a path from the compromised endpoint into a privileged administrative workflow.

That is why shared drive policy has to be treated as an access control decision, not a convenience setting. When redirecting storage is necessary, it should be constrained so the remote side cannot place executable or auto-opened content into locations the technician will trust later.

How Persistence and Privilege Abuse Typically Show Up

The most common failure mode is delayed execution. An attacker uses the shared drive during the session to drop a file, shortcut, script, or payload, then waits for a login, reconnect, or reboot to trigger it. The technician may never see the initial placement as suspicious because it happened during an otherwise legitimate support interaction.

If the redirected path is writable, the attacker can also manipulate existing support materials, such as update packages, scripts, or log collections. In practice, this creates a blend of persistence and privilege abuse: the remote endpoint plants the artifact, and the technician session supplies the higher-value execution context.

In environments that rely on remote support at scale, the blast radius grows quickly. A single weak mapping policy can give many low-trust endpoints a repeatable way to influence high-trust admin workstations, especially when the same support account, folder pattern, or RDP template is reused across multiple systems.

Risk and Threat Considerations

Shared drive redirection becomes risky when organisations allow a low-trust endpoint to write into a technician context that later runs tools, opens files, or retains session artifacts. The exposure is greatest when the shared path is not isolated, not read-only, or not tightly monitored for unexpected file types and post-session persistence.

Failure mechanism: An attacker on the remote endpoint uses the redirected drive to stage malicious content, then waits for the technician to return to the same workstation, open the file, or trigger an automated login or reboot path that loads the planted artifact.

Impact: The attacker gains a persistence bridge into a higher-privilege workflow, increasing the chance of lateral movement, credential exposure, or execution on a trusted administrative system.

Practitioner Guidance

What to verify: Confirm whether the redirected drive is truly needed for the support use case, then test whether the remote side can write into any location the technician account later trusts. If the answer is yes, treat that mapping as a privileged write path rather than a harmless convenience feature.

Decision rule: If the technician account can access production or administrative systems, the shared path should be constrained so the remote endpoint cannot stage executable content into a reused or auto-processed location. Prefer the smallest possible exposed surface, and separate file transfer from interactive support whenever you can.

Practitioner takeaway: The key judgement is whether the RDP mapping creates a cross-trust write channel. If it does, the control objective is not just confidentiality of the session, but prevention of delayed code or content injection into a more trusted system.

Related resources from NHI Mgmt Group

• What happens when organisations allow shared credentials without access restrictions?
• What breaks when organisations allow BYOD without tight session and device controls?
• What happens when organisations let users run browser sessions without inside-the-browser controls?
• What happens when organisations allow public AI tools without data loss prevention controls?