Why does RDP local drive sharing create such a serious lateral movement risk?

Drive sharing turns a support session into a two way trust relationship. If a low privileged machine is compromised before the connection, the remote system can read and modify the technician’s shared files with the technician’s privileges. That gives an attacker a path to place startup scripts, stage payloads, and wait for the privileged user to log back in.

Why local drive redirection changes the trust model

Local drive sharing is risky because it extends the remote session beyond screen and keyboard control into file-system access on the technician endpoint. That matters even when the remote host is not fully trusted, because the redirected drive can be read, written, or planted with files that later execute in the technician’s context. In practice, the boundary is no longer “remote system versus local system,” but “remote system with reach into local assets.”

This is why the control is often more dangerous than clipboard sharing. Drive redirection creates persistence opportunities, staging space, and a bridge between a compromised endpoint and a higher-privilege user workflow. A benign support channel can become an attack path if the remote side can influence what is waiting on the technician’s disk when the session ends.

How the lateral movement path is built

The key failure mode is privilege borrowing. Once a local drive is shared, anything the remote session can place there may later be opened, synced, or executed by the technician with normal user rights, and sometimes with elevated rights if the technician uses the same host for admin tasks. That makes the redirected drive useful for dropping startup items, scripts, installers, or shortcut-based payloads that survive the session boundary.

Drive sharing also helps attackers move from initial foothold to broader access because it reduces the number of separate controls they must defeat. They do not need immediate remote code execution on the technician machine if they can instead weaponise the trust relationship created by the session. The remote host becomes a staging point for files that are delivered through an authorised channel, then triggered later when the user returns to the machine.

It can bypass some network-centric monitoring because the transfer appears as an allowed RDP feature rather than an obvious inbound upload.
It can expose sensitive local files if the remote endpoint is compromised before or during the session.
It can support delayed execution, which makes attribution and containment harder after the support session closes.

Risk and Threat Considerations

When drive redirection is enabled, a compromise on either side of the RDP session can turn into a cross-system infection path. The most serious threat is not file copying itself, but the ability to use an approved file channel to plant material that is later trusted by the user or by a privileged workflow.

Failure mechanism: The remote system gains write access to a local location that the technician later trusts, then uses that location to stage payloads, scripts, or disguised installers for delayed execution or credential theft.

Impact: An attacker can turn a support session into a lateral movement bridge, extend compromise into other internal systems, and preserve access until the next user login or admin action.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1021.001 — Remote Services: Remote Desktop Protocol	RDP is the access path used for lateral movement in this question.
	T1091 — Replication Through Removable Media	Drive sharing creates a file-transfer bridge that can stage payloads like portable media paths.
	T1105 — Ingress Tool Transfer	Attackers may use shared drives to move payloads onto the technician endpoint.
Recommendation — Map RDP sessions to T1021.001 and monitor for remote desktop-based propagation. Watch redirected-drive activity for staged executables and transfer abuse. Detect suspicious payload placement through redirected file channels.
CIS Controls v8	6 — Access Control Management	Restricting and reviewing access paths limits the blast radius of shared-drive trust.
	8 — Audit Log Management	Logging is needed to spot file movement and post-session execution through RDP shares.
Recommendation — Restrict RDP redirection and remove unnecessary file-transfer access paths. Log redirected-drive use and alert on unusual file writes or launches.
NIST CSF 2.0	PR.AC — Access Control	The issue is a trust-boundary and access-control expansion across the RDP session.
Recommendation — Limit session redirection to the minimum access needed for the task.

Practitioner Guidance

What to prioritise: Treat drive redirection as a higher-risk RDP feature than mouse, keyboard, or clipboard forwarding. If the support task does not truly require file transfer, disable it by default and use a separate, controlled transfer path for approved files.

What to verify: Confirm whether technicians use the same workstation for privileged and non-privileged work, because that increases the blast radius of a planted file. Also verify whether endpoint controls inspect files arriving through RDP redirection with the same scrutiny as other inbound content.

Common mistake: Teams often assume that because the RDP session is authenticated, anything moved through it is automatically trustworthy. The real question is whether the remote endpoint should be allowed to influence what later executes or opens on the technician machine.

Practitioner takeaway: The control problem is not remote desktop itself, it is whether the session is allowed to become a file delivery and persistence channel into a more trusted workstation.