Network Access Control (NAC)

The subject installs and uses an unapproved VPN client, potentially violating organizational policy. By using a VPN service not controlled by the organization, the subject can bypass security controls, reducing the security team’s visibility into network activity conducted through the unauthorized VPN. This could lead to significant security risks, as monitoring and detection mechanisms are circumvented.

The subject performs work-related tasks on an unauthorized, non-organization-owned device, likely violating organizational policy. Without the organization’s security controls in place, this device could be used to bypass established safeguards. Moreover, using a personal device increases the risk of sensitive data being retained or exposed, particularly after the subject is offboarded, as the organization has no visibility or control over information stored outside its managed systems.

An organization has a Bring Your Own Device (BYOD) policy, where a subject is authorized to connect personally owned devices—such as smartphones, tablets, or laptops—to organizational resources. These resources include corporate networks, cloud applications, and on-premises systems that may handle confidential and/or sensitive information.

The use of personal devices in a corporate environment introduces several risks, as these devices may lack the same level of security controls and monitoring as organization-owned equipment.

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.

An organization entrusts a Managed Service Provider (MSP) with administrative or operational access to its digital environment - typically for IT support, system maintenance, or development functions. This access is often persistent, privileged, and spans sensitive infrastructure or data environments.

The means is established when MSP personnel, including potential subjects, are permitted to authenticate into the client’s environment from systems or networks entirely outside the client's visibility or jurisdiction. These MSP endpoints may be unmanaged, unmonitored, or physically located in regions where customer organization's policies, incident response authority, or legal recourse do not apply.

This creates an unobservable access channel: the subject operates from infrastructure beyond the reach of the customer organization's logging, endpoint detection, or identity correlation. The organization is therefore unable to monitor or verify who accessed what, when, or from where—rendering all downstream actions unauditable by the customer organization's internal security teams, unless mirrored within the client-controlled environment.

The exposure can be compounded by the MSP’s internal controls (or lack thereof). Weak credential custody practices, shared administrative accounts, inadequate background checks, or poor workforce segmentation create conditions where privileged misuse or unauthorized access can occur without attribution or immediate detection. The subject does not require escalation—they begin with sanctioned access and operate under delegated trust, often without the constraints applied to internal staff.

This structural dependency - privileged access held externally, without enforceable oversight - creates the necessary conditions for an insider infringement to occur with low risk of interruption or accountability.

A subject connects their personal device, under a Bring Your Own Device (BYOD) policy, to organization resources, such as on-premises systems or cloud-based platforms. By leveraging this access, the subject exfiltrates sensitive or confidential data. This unauthorized data transfer can occur through various means, including copying files to the personal device, sending data via email, or using cloud storage services.

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 installs a browser capable of accessing anonymity networks, such as the Tor Browser (used for .onion sites), I2P Router Console, or Freenet, as part of preparation for covert research, anonymous communication, or unmonitored data exchange. This behavior may support future infringement by enabling non-attributable activity outside sanctioned IT controls.

Installation of the Tor Browser Bundle typically involves downloading a signed executable or compressed package from https://www.torproject.org, executing an installer that unpacks a portable browser (a custom-hardened Firefox variant), and launching start-tor-browser.exe—which spawns both the Tor daemon (tor.exe) and the browser instance (firefox.exe) in a sandboxed environment. Configuration files such as torrc may be modified to enable pluggable transports (e.g., obfs4, meek) designed to evade deep packet inspection (DPI) or proxy enforcement.

In environments with proxy filtering, the subject may attempt to chain Tor through bridge relays or VPNs, obfuscate traffic using SOCKS5 tunneling, or execute from non-standard directories (e.g., cloud-sync folders, external volumes). Some subjects bypass endpoint controls entirely by booting into live-operating systems (e.g., Tails, Whonix) which route all system traffic through Tor by default and leave minimal forensic artifacts on host storage.

This installation is rarely accidental and often coincides with other policy evasions or drift indicators. The presence of anonymizing tools—even in dormant form—warrants scrutiny as a preparatory indicator linked to potential data exfiltration, credential harvesting, or external coordination.