Destructive Malware Deployment

By only allowing pre-approved software to be installed and run on corporate devices, the subject is unable to install software themselves.

An Acceptable Use Policy (AUP) is a set of rules outlining acceptable and unacceptable uses of an organization's computer systems and network resources. It acts as a deterrent to prevent employees from conducting illegitimate activities by clearly defining expectations, reinforcing legal and ethical standards, establishing accountability, specifying consequences for violations, and promoting education and awareness about security risks.

An anti-virus solution detect and alert on malicious files, including the ability to take autonomous actions such as quarantining or deleting the flagged file.

Microsoft Litigation Hold is a built-in compliance feature within Microsoft 365 that preserves mailbox content, even if a subject attempts to delete or alter messages. When enabled, it ensures that emails, calendar items, and other mailbox content remain discoverable and immutable, regardless of user-side deletion or modification attempts.

Organizations can apply Litigation Hold to specific subjects, role types, or high-risk populations, and define custom hold durations (e.g., indefinite or time-bound).

Network Intrusion Prevention Systems (NIPs) can alert on abnormal, suspicious, or malicious patterns of network behavior, and take autonomous actions to stop the behavior, such as resetting a network connection.

Next-generation firewall (NGFW) network appliances and services provide the ability to control network traffic based on rules. These firewalls provide basic firewall functionality, such as simple packet filtering based on static rules and track the state of network connections. They can also provide the ability to control network traffic based on Application Layer rules, among other advanced features to control network traffic.

A example of simple functionality would be blocking network traffic to or from a specific IP address, or all network traffic to a specific port number. An example of more advanced functionality would be blocking all network traffic that appears to be SSH or FTP traffic to any port on any IP address.

Privileged Access Management (PAM) is a critical security practice designed to control and monitor access to sensitive systems and data. By managing and securing accounts with elevated privileges, PAM helps reduce the risk of insider threats and unauthorized access to critical infrastructure.

Key Prevention Measures:

Least Privilege Access: PAM enforces the principle of least privilege by ensuring users only have access to the systems and data necessary for their role, limiting opportunities for misuse.

• Just-in-Time (JIT) Access: PAM solutions provide temporary, on-demand access to privileged accounts, ensuring users can only access sensitive environments for a defined period, minimizing exposure.
• Centralized Credential Management: PAM centralizes the management of privileged accounts and credentials, automatically rotating passwords and securely storing sensitive information to prevent unauthorized access.
• Monitoring and Auditing: PAM solutions continuously monitor and log privileged user activities, providing a detailed audit trail for detecting suspicious behavior and ensuring accountability.
• Approval Workflows: PAM incorporates approval processes for accessing privileged accounts, ensuring that elevated access is granted only when justified and authorized by relevant stakeholders.

Benefits:

PAM enhances security by reducing the attack surface, improving compliance with regulatory standards, and enabling greater control over privileged access. It provides robust protection for critical systems by limiting unnecessary exposure to high-level access, facilitating auditing and accountability, and minimizing opportunities for both insider and external threats.

The Principle of Least Privilege should be enforced, and period reviews of permissions conducted to ensure that accounts have the minimum level of access required to complete duties as per their role.

An agent capable of Endpoint Detection and Response (EDR) is a software agent installed on organization endpoints (such as laptops and servers) that (at a minimum) records the Operating System, application, and network activity on an endpoint.

Typically EDR operates in an agent/server model, where agents automatically send logs to a server, where the server correlates those logs based on a rule set. This rule set is then used to surface potential security-related events, that can then be analyzed.

An EDR agent typically also has some form of remote shell capability, where a user of the EDR platform can gain a remote shell session on a target endpoint, for incident response purposes. An EDR agent will typically have the ability to remotely isolate an endpoint, where all network activity is blocked on the target endpoint (other than the network activity required for the EDR platform to operate).

An agent capable of User Activity Monitoring (UAM) is a software agent installed on organization endpoints (such as laptops); typically, User Activity Monitoring agents are only deployed on endpoints where a human user Is expected to conduct the activity.

The User Activity Monitoring agent will typically record Operating System, application, and network activity occurring on an endpoint, with a focus on activity that is or can be conducted by a human user. The purpose of this monitoring is to identify undesirable and/or malicious activity being conducted by a human user (in this context, an Insider Threat).

Typical User Activity Monitoring platforms operate in an agent/server model where activity logs are sent to a server for automatic correlation against a rule set. This rule set is used to surface activity that may represent Insider Threat related activity such as capturing screenshots, copying data, compressing files or installing risky software.

Other platforms providing related functionality are frequently referred to as User Behaviour Analytics (UBA) platforms.

An agent capable of User Behaviour Analytics (UBA) is a software agent installed on organizational endpoints (such as laptops). Typically, User Activity Monitoring agents are only deployed on endpoints where a human user is expected to conduct the activity.

The User Behaviour Analytics agent will typically record Operating System, application, and network activity occurring on an endpoint, focusing on activity that is or can be conducted by a human user. Typically, User Behaviour Analytics platforms operate in an agent/server model where activity logs are sent to a server for automatic analysis. In the case of User Behaviour Analytics, this analysis will typically be conducted against a baseline that has previously been established.

A User Behaviour Analytic platform will typically conduct a period of ‘baselining’ when the platform is first installed. This baselining period establishes the normal behavior parameters for an organization’s users, which are used to train a Machine Learning (ML) model. This ML model can then be later used to automatically identify activity that is predicted to be an anomaly, which is hoped to surface user behavior that is undesirable, risky, or malicious.

Other platforms providing related functionality are frequently referred to as User Activity Monitoring (UAM) platforms.

CloudTrail logs by themselves, or in conjunction with CloudWatch, can be used to identify resource deletion events. These logs contain the account that performed the action (within the userIdentity field), a timestamp (within the eventTime field), and more detailed information depending on what resource was deleted. Some eventName examples include; DeleteBucket (For S3 bucket deletion), DeleteDBInstance (For RDS deletion), and TerminateInstances (For EC2 termination).

Monitor AWS CloudTrail logs to detect unauthorized creation, modification, or deletion of compute, storage, network, or management resources. Unauthorized resource activity may indicate insider preparation for data exfiltration, illicit compute use, or unauthorized persistent access.

Where to Configure/Access

• AWS CloudTrail Console: https://console.aws.amazon.com/cloudtrail/
• AWS CloudWatch Logs Console (for log streaming and alerting): https://console.aws.amazon.com/cloudwatch/home#logsV2:log-groups

Detection Methods

Monitor CloudTrail API event types such as:

• RunInstances (EC2 instance creation)
• CreateVolume (EBS volumes)
• CreateBucket (S3 buckets)
• CreateFunction / UpdateFunctionCode (Lambda functions)
• CreateCluster (ECS/EKS clusters)

Configure event selectors to capture management events across all regions.

Set metric filters and alarms for suspicious activity through CloudWatch.

Indicators

• Unapproved resources provisioned without matching Infrastructure as Code deployments.
• Resources created manually via console or CLI outside approved automation frameworks.
• Resources missing mandatory organizational tags (e.g., project ID, owner).

Azure Activity Log can be used to identify resource deletion events by using the search bar to filter by operations related to deletion, such as Delete or Delete Resource. These logs contain the account that performed the action (within the Caller field), a timestamp and more detailed information depending on what resource was deleted (within the Resource, Status, and Properties fields).

Monitor Azure Activity Logs and Azure Resource Graph for detection of unauthorized creation, modification, or deletion of resources in Azure subscriptions. Unapproved deployments may signal insider staging, misuse of compute, or persistence attempts.

Where to Configure/Access

• Azure Activity Logs (via Azure Portal): https://portal.azure.com/#blade/Microsoft_Azure_Monitoring/AzureMonitoringBrowseBlade/activitylog
• Azure Resource Graph Explorer: https://portal.azure.com/#blade/HubsExtension/BrowseResource/resourceType/Microsoft.ResourceGraph/queries

Detection Methods

Monitor for critical resource operation event types:

• Microsoft.Compute/virtualMachines/write (VM creation)
• Microsoft.Storage/storageAccounts/write (Storage)
• Microsoft.KeyVault/vaults/write (Key Vaults)
• Microsoft.Authorization/roleAssignments/write (Role Assignments)

Deploy Azure Monitor or Sentinel queries for operational drift and unauthorized resource creation.

Indicators

VMs or services deployed outside managed resource groups.

Use of non-standard SKU types (e.g., GPU-enabled VMs).

Resources missing mandatory tags such as cost center or compliance level.

By using files with canary tokens as tripwires, investigators can create an early warning system for potential collection activities before a data exfiltration infringement occurs.

By strategically placing these files on endpoints, network shares, FTP servers, and collaboration platforms such as SharePoint or OneDrive, the canaries monitor for access and automatically trigger an alert if an action is detected.

A honeypot is a decoy system that mimics a legitimate system or service, enticing a malicious actor to interact with it. It records any interaction for later review.

Implement Deep Packet Inspection (DPI) tools to inspect the content of network packets beyond the header information. DPI can identify unusual patterns and hidden data within legitimate protocols. DPI can be conducted with a range of software and hardware solutions, such as Unified Threat Management (UTM) and Next-Generation Firewalls (NGFWs), as well as Intrusion Detection and Prevention Systems (IDPS) such as Snort and Suricata, 

File Integrity Monitoring (FIM) is a technical prevention mechanism designed to detect unauthorized modification, deletion, or creation of files and configurations on monitored systems. The most basic implementation method is cryptographic hash comparison, where a known-good baseline (typically SHA256 or SHA1) is calculated and stored for monitored files. At regular intervals (or in real time) current file states are re-hashed and compared to the baseline. Any discrepancy in hash value, size, permissions, or timestamp is flagged as an integrity violation.

While hash comparison is foundational, mature File Integrity Monitoring (FIM) solutions incorporate additional telemetry and instrumentation to increase forensic depth, reduce false positives, and support attribution:

• ACL and Permission Monitoring: Captures unauthorized changes to file ownership, execution flags (e.g. chmod +x), NTFS permissions, or group inheritance, critical for detecting silent privilege escalation.
• Timestamp Integrity Checks: Monitors for retroactive or unnatural changes to creation, modification, and access timestamps, commonly associated with anti-forensic behaviors such as timestomping.
• Event-based Hooks: Leverages OS-native event subsystems (e.g. Windows ETW, USN Journal; Linux inotify, auditd, fanotify) to trigger high-fidelity alerts on file system activity without waiting for interval-based scans.
• Process Attribution: Enriches FIM events with the user identity, process name, PID, and command line responsible for the change, enabling precise correlation with session logs, drift indicators, and subject behavior.
• Snapshot or Versioned Comparisons: Enables file state diffing across time, including rollback of modified artifacts or analysis of change sequences (common in forensic suites and some EDR platforms).

To be effective in insider threat contexts, File Integrity Monitoring should be explicitly tuned to monitor (at minimum):

• Executable and script directories (%ProgramFiles%, %APPDATA%, /usr/local/bin/, /opt/)
• Configuration and runtime paths (/etc/, C:\Windows\System32\Config, container volumes)
• Security logs, audit trails, and telemetry agents (.evtx, /var/log/, SIEM client logs)
• Credential storage and secrets locations (browser credential stores, password vaults, keyrings, .env files)
• Backup and recovery tooling (scripts, snapshot schedulers, and volume metadata)

In ransomware or destruction scenarios, File Integrity Monitoring can detect the early stages of detonation by identifying rapid, high-volume file modifications and hash changes, particularly in mapped drives, document repositories, and shared storage. This can serve as a trigger for containment actions and/or investigation before full encryption completes, especially when correlated with process telemetry and known ransomware behaviors (e.g. deletion of shadow copies, entropy spikes).

When tuned and deployed appropriately, File Integrity Monitoring provides a high-fidelity signal of tampering, staging, or covert access attempts, even when other telemetry (e.g. signature-based detection or anomaly modeling) fails to trigger. This makes it particularly valuable in environments where subjects have elevated access, control over telemetry agents, or knowledge of investigative blind spots.

GCP Cloud Audit Logs can be used to identify resource deletion events. These logs contain the account that performed the action (within the Principal field), a timestamp, and more detailed information depending on what resource was deleted. Some query examples include; resource.type="gcs_bucket" and protoPayload.methodName="storage.buckets.delete" for bucket deletion and resource.type="gce_instance" and protoPayload.methodName="v1.compute.instances.delete" for computer instance deletion.

Monitor Google Cloud Audit Logs to detect unauthorized creation or modification of compute, storage, and IAM resources. Subjects creating GCP resources without authorization may be staging infrastructure for exfiltration or persistent insider access.

Where to Configure/Access

• Google Cloud Logging (Audit Logs): https://console.cloud.google.com/logs
• Admin Activity Logs Documentation: https://cloud.google.com/logging/docs/audit

Detection Methods

Monitor Admin Activity logs for key methods:

• compute.instances.insert (VMs)
• storage.buckets.create (Buckets)
• compute.disks.insert (Persistent disks)
• iam.serviceAccounts.create (Service Accounts)

Use Log-Based Metrics and Cloud Monitoring alerting for policy violations.

Monitor project and folder-level activity for resource creation.

Indicators

• VMs or services created in unauthorized folders or projects.
• New service accounts with high privileges.
• Missing mandatory labels (environment, owner, compliance status).

Analyze network flow data (NetFlow) to identify unusual communication patterns and potential tunneling activities. Flow data offers insights into the volume, direction, and nature of traffic.

NetFlow, a protocol developed by Cisco, captures and records metadata about network flows—such as source and destination IP addresses, ports, and the amount of data transferred.

Various network appliances support NetFlow, including Next-Generation Firewalls (NGFWs), network routers and switches, and dedicated NetFlow collectors.

Network Intrusion Detection Systems (NIDS) can alert on abnormal, suspicious, or malicious patterns of network behavior. 

Monitor Oracle Cloud Infrastructure (OCI) Audit Logs to detect unauthorized system or service creation. Unauthorized provisioning in OCI can indicate insider threat activity aimed at illicit compute use, data staging, or security control bypass.

Where to Configure/Access

• OCI Audit Console: https://cloud.oracle.com/audit
• OCI Audit Documentation: https://docs.oracle.com/en-us/iaas/Content/Audit/Concepts/auditoverview.htm

Detection Methods

Analyze Audit Events such as:

• LaunchInstance (Compute instance creation)
• CreateBucket (Object Storage creation)
• CreateVolume (Block Volume creation)
• CreateVcn (Virtual Network creation)

Configure Object Storage log exports and integrate with SIEM tools (e.g., Splunk, QRadar) for real-time detection.

Indicators

• Compute or storage resources created in unauthorized compartments.
• VCNs created without associated security lists or network ACLs.
• Instances launched using high-compute shapes without approved business justification.

Detailed PowerShell logging is not enabled by default and must be configured.

PowerShell is able to record the processing of commands, script blocks, functions, and scripts whether invoked interactively, or through automation.

PowerShell logging can be enabled through Group Policy with the following: Administrative Templates → Windows Components → Windows PowerShell

There are 3 available logging types, they are: Module Logging, Script Block Logging and Transcription.

Module Logging: Records pipeline execution details, such as variable initialisation and command invocations, capturing portions of scripts and some de-obfuscated code. This logging is available since PowerShell 3.0 and generates a large volume of events, providing valuable output not captured elsewhere. Events are written to Event ID 4103.

Module logging can be enabled by setting the following registry values:

HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging → EnableModuleLogging = 1

HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging \ModuleNames → * = *

Script Block Logging: Captures blocks of code as they are executed, including de-obfuscated code, allowing visibility into the full contents of executed scripts and commands. This feature is available in PowerShell 5.0 and records events under Event ID 4104.

Script block logging can be enabled by setting the following registry values:

HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1

Transcription: Records the input and output of entire PowerShell sessions, providing a comprehensive record of all commands executed and their results.

Transcription logging can be enabled by setting the following registry values:

HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → EnableTranscripting = 1

HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → EnableInvocationHeader = 1

HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → OutputDirectory = “” (Enter path. Empty = default)

Commercial security software may have the ability to generate alerts when suspected tampering is detected, such as interacting with the process in memory, or attempting to access files related to its operation.

Monitor and analyze minor policy violations over time to detect emerging behavioral patterns that may indicate boundary testing, behavioural drift, or preparation for more serious misconduct. Isolated minor infringements may appear benign, but repeated or clustered incidents can signal a developing threat trajectory.

Detection Methods

• Maintain centralized logging of all recorded policy violations, including low-severity infractions, within case management, HR, or security systems.
• Implement analytical tools or workflows that flag individuals with multiple minor violations within defined timeframes (e.g., repeated unauthorized device use, bypassing security protocols, small unauthorized disclosures).
• Correlate minor violation data with other risk indicators such as unauthorized access attempts, changes in behavioral baselines, or indicators of disgruntlement.
• Analyze patterns across teams, units, or operational areas to detect systemic issues or cultural tolerance of rule-breaking behaviors.
• Conduct periodic behavioral risk reviews that explicitly include minor infractions as part of insider threat monitoring programs.
•  

Indicators

• Subjects accumulating multiple low-level infractions without corresponding corrective action or behavioral improvement.
• Increased frequency or severity of minor violations over time, suggesting desensitization or emboldenment.
• Violations spanning multiple domains (e.g., IT security, operational protocols, HR policy), indicating generalized disregard for rules.
• Evidence that minor violations are clustered around operational pressures, major organizational changes, or periods of reduced oversight.

Deploy User and Entity Behavior Analytics (UEBA) solutions designed for cloud environments to monitor and analyze the behavior of users, applications, network devices, servers, and other non-human resources. UEBA systems track normal behavior patterns and detect anomalies that could indicate potential insider events. For instance, they can identify when a user or entity is downloading unusually large volumes of data, accessing an excessive number of resources, or engaging in data transfers that deviate from their usual behavior.

Implement User Behavior Analytics (UBA) tools to continuously monitor and analyze user (human) activities, detecting anomalies that may signal security risks. UBA can track and flag unusual behavior, such as excessive data downloads, accessing a higher-than-usual number of resources, or large-scale transfers inconsistent with a user’s typical patterns. UBA can also provide real-time alerts when users engage in behavior that deviates from established baselines, such as accessing sensitive data during off-hours or from unfamiliar locations. By identifying such anomalies, UBA enhances the detection of insider events.

To identify events where shadow copies are being deleted on a Windows system, command-line arguments should be monitored for the string “vssadmin delete shadows,” which represents the initial syntax of a command to delete shadows with the vssadmin utility.

Windows Event Log ID 4660 “An object was deleted” is generated when an object was deleted, such as a file system, kernel, or registry object. This Event is not enabled by default, and requires “Delete” auditing to be enabled in the object’s System Access Control List (SACL). This event doesn’t contain the name of the deleted object, so investigators must also utilize Event ID 4663.

Windows Event Log ID 4663 “An attempt was made to access an object” can be used in combination with Event ID 4660 to track object deletion. This Event is not enabled by default, and requires “Delete” auditing to be enabled in the object’s System Access Control List (SACL).

This may represent an anti-forensics technique if there is no reasonable explanation for why the objected was deleted from the system.

Windows Event Log ID 1102 “The audit log was cleared” is generated when the Windows Security audit log has been cleared. This Event contains the account's SID, name, and domain that cleared the log.

This may represent an anti-forensics technique if there is no reasonable explanation for why the Event Log was cleared on this system.