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.

The subject causes interruptions, degradation, or instability in organizational systems, processes, or data flows that impair day‑to‑day operations and affect availability, integrity, or service continuity. This category encompasses non‑exfiltrative and non‑theft forms of disruption, distinct from data exfiltration or malware aimed at permanent destruction.

Disruptive actions may include misuse of administrative tools, intentional misconfiguration, suppression of services, logic interference, dependency tampering, or selective disabling of critical functions. The objective is operational impact; slowing, blocking, or misrouting workflows, rather than data removal or theft.

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.

The subject deploys ransomware within the organization’s environment, resulting in the encryption, locking, or destructive alteration of organizational data, systems, or backups. Ransomware used by insiders may be obtained from public repositories, affiliate programs (e.g. RaaS platforms), or compiled independently using commodity builder kits. Unlike external actors who rely on phishing or remote exploitation, insiders often bypass perimeter controls by detonating ransomware from within trusted systems using local access.

Ransomware payloads are typically compiled as executables, occasionally obfuscated using packers or crypters to evade detection. Execution may be initiated via command-line, scheduled task, script wrapper, or automated loader. Encryption routines often target common file extensions recursively across accessible volumes, mapped drives, and cloud sync folders. In advanced deployments, the subject may disable volume shadow copies (vssadmin delete shadows) or stop backup agents (net stop) prior to detonation to increase impact.

In some insider scenarios, ransomware is executed selectively: targeting specific departments, shares, or systems, rather than broad detonation. This behavior may indicate intent to send a message, sabotage selectively, or avoid attribution. Payment demands may be issued internally, externally, or omitted entirely if disruption is the primary motive.

A subject deletes organizational files or data (manually or through tooling) outside authorized workflows, resulting in the loss, concealment, or unavailability of operational assets. This infringement encompasses both targeted deletion (e.g. selected records, logs, or documents) and bulk removal (e.g. recursive deletion of directories or volumes).

Unlike Destructive Malware Deployment, which uses self-propagating or malicious code to irreversibly damage systems, this behavior reflects direct user-driven actions or scripts that remove or purge data without employing destructive payloads. Deletions may be conducted via built-in utilities, custom scripts, scheduled tasks, or misuse of administrative tools such as backup managers or version control systems.

This activity frequently occurs to:

• Conceal evidence of other infringing actions (e.g. log deletion to frustrate investigation)
• Sabotage availability of critical information (e.g. deleting shared drives or project directories)
• Facilitate exfiltration or preparation (e.g. purging redundant files before copying sensitive data)

It may also involve secondary actions such as emptying recycle bins, purging shadow copies, disabling version histories, or wiping removable media to obscure the scope of deletion.

The subject deliberately interferes with operational systems in ways that degrade, interrupt, or misroute services relied upon by customers, without relying on file deletion or malware. This includes misconfigurations, service disabling, authentication interference, or intentional introduction of latency, instability, or incorrect outputs. The result is operational degradation that directly or indirectly affects service delivery, availability, or trust.

Unlike File or Data Deletion, this infringement does not depend on erasing data, and unlike Destructive Malware Deployment, it does not rely on malicious payloads or automated damage. The disruption instead stems from direct manipulation of infrastructure, configurations, service states, or user access.

Examples include:

• Intentionally disabling authentication or API endpoints
• Modifying DNS, firewall, or routing rules to block legitimate traffic
• Tampering with load balancers or HA/failover logic
• Altering service configurations to break dependency chains (e.g. pointing production systems to empty dev databases)
• Injecting false flags into monitoring or orchestration tools to trigger auto-scaling failures or mis-alerts
• Enabling excessive logging or computation to induce service latency or memory exhaustion
• Locking critical service accounts, API keys, or secrets in vault systems

These actions may be motivated by retaliation, concealment, sabotage, or insider coercion, and often occur in environments where the subject has legitimate system access but uses it to destabilize service delivery covertly.