Delayed Execution Triggers

When an employee leaves the organization, a formal process should be followed to ensure all equipment is returned, and any associated accounts or access is revoked.

Provide a process for all staff members to report concerning and/or suspicious behaviour to the organization's security team for review. An internal whistleblowing process should take into consideration the privacy of the reporter and the subject(s) of the report, with specific regard to safeguarding against reprisals against reporters.

Static code analysis integrated into CI/CD pipelines provides a critical prevention mechanism against anti-forensic behaviors embedded in code, scripts, and infrastructure definitions. By enforcing automated review of logic patterns prior to deployment, organizations can detect concealed execution paths, scheduling abuse, and evasive constructs before they reach production.

This control is especially vital in mitigating deferred execution techniques, where the subject inserts code that activates long after submission—typically to evade scrutiny or delay attribution. Static analysis enables defenders to identify high-risk patterns at rest, before runtime, reducing reliance on reactive detection and shortening investigative timelines.

Detection of Time-Based Execution Logic:
Flag conditional statements that compare system time or date against hardcoded thresholds or calculated values.
Examples:

• if (datetime.now() > target_date)
• if time.time() > 1723468800 (UNIX timestamp obfuscation)

Abnormal Delay Functions and Sleep Calls:
Block or escalate the use of delay functions exceeding operational thresholds. Focus on calls intended to stall execution post-deployment.
Examples:

• sleep(3600)
• Start-Sleep -Seconds 1800
• Thread.sleep(900000) (in Java)

Embedded Scheduler References in Scripts:
Detect scripting logic that attempts to create or modify scheduled tasks, cron jobs, or background triggers.
Examples:

• echo '0 4 * * * /usr/bin/script.sh' >> /etc/crontab
• schtasks /create /tn "Update" /tr C:\temp\payload.exe /sc once /st 23:59
• at now + 1 minute /interactive "cmd.exe"

Identification of Obfuscation and Dynamic Constructs:
Scan for base64-encoded, concatenated, or dynamically constructed commands that attempt to evade static detection of time or scheduling logic.
Examples:

• eval(base64.b64decode(payload))
• task_command = "schtasks" + " /create /sc daily"
• exec("sleep " + str(delay_seconds))

CI/CD Blocking and Exception Escalation:
Treat the above patterns as rule violations within CI/CD pipelines. Enforce blocking behavior unless a security-reviewed exception is filed. Ensure exception cases are logged, tagged, and auditable.

Pre-Deployment Artifact Scanning:
Apply static analysis not only to source code but to bundled artifacts such as container images, compiled scripts, or deployment templates (e.g., Terraform, CloudFormation) to catch embedded logic in infrastructure as code (IaC).

Cross-Team Code Review and Signature Expansion:
Maintain shared detection signatures across DevSecOps, application security, and insider risk teams. Regularly review triggered matches to refine accuracy and discover new anti-forensic variants.

Attestation of Safe Logic by Departing Engineers:
Require final code audits for subjects flagged for departure or termination. Mandate re-review of any automation, CI/CD jobs, or privileged scripting authored by the subject.

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.

A Data Loss Prevention (DLP) solution refers to policies, technologies, and controls that prevent the accidental and/or deliberate loss, misuse, or theft of data by members of an organization. Typically, DLP technology would take the form of a software agent installed on organization endpoints (such as laptops and servers).

Typical DLP technology will alert on the potential loss of data, or activity which might indicate the potential for data loss. A DLP technology may also provide automated responses to prevent data loss on a device.

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.