[EXP] Linux Foothold-to-Root Privilege Escalation and Cloud Workload Trust Compromise Risk

Report Type: EXP — Exploit Behavior and Enterprise Risk Analysis
Threat Category: Linux Local Privilege Escalation and Cloud Workload Trust Compromise
Assessment Date: July 10, 2026
Primary Impact Domain: Host and Workload Trust Compromise
Secondary Impact Domains: Credential and Trust-Material Exposure; Cloud and Kubernetes Access; CI/CD and Repository Risk; Security-Control Degradation; Persistence; Downstream Infrastructure Expansion
Affected Asset Class: Linux Servers, Cloud Instances, Kubernetes Nodes, Container Hosts, CI Runners, Build Systems, Developer Systems, Privileged Automation Hosts, Repositories, and Production Workloads
Threat Objective Classification: Privilege Escalation, Root-Level Control, Credential and Trust-Material Access, Persistence, Defense Evasion, Workload-Boundary Abuse, and Downstream Trust Expansion

Published by: CyberDax LLC
Author: Edward “Tony” Dolley
Role: Founder / Principal Threat Researcher, CyberDax LLC
Publication Date: July 10, 2026
Publication Type: Cybersecurity Research Report / White Paper

BLUF

‍  Linux foothold-to-root privilege escalation and cloud workload trust compromise create material business risk because constrained access to a Linux host, application, container, CI runner, developer system, or workload may be converted into root-level control over infrastructure that stores credentials, workload identities, Kubernetes tokens, cloud access material, deployment secrets, repository credentials, signing material, and security-control configurations. The technical risk arises when a low-privilege foothold is combined with a vulnerable kernel path, package flaw, authentication weakness, SUID or setgid mechanism, namespace or mount interaction, filesystem condition, memory-corruption issue, race condition, synchronization flaw, privileged utility, or comparable local trust-boundary failure that enables an abnormal transition to root-level execution. Observed activity may reflect failed exploitation, unconfirmed escalation, or successful root compromise, with successful escalation potentially enabling sensitive-resource access, security-control degradation, persistence, workload-boundary abuse, credential or trust-material use, unauthorized cloud or Kubernetes activity, CI/CD or repository access, and downstream infrastructure expansion. Immediate executive action is required to identify exposed and high-value Linux systems, validate vulnerable-state and patch history, preserve endpoint and audit evidence, review privilege transitions and root-level activity, assess credential and trust-material exposure, examine container, Kubernetes, cloud, and CI/CD activity, rotate exposed credentials where required, and rebuild affected systems when trust cannot be restored.

Executive Risk Translation

Linux privilege escalation shifts the business risk from a single vulnerable kernel, package, service, or exploit path to uncertainty over whether the organization can still trust the workloads, identities, secrets, automation systems, and downstream infrastructure connected to the affected host. When available evidence cannot reliably distinguish failed exploitation from successful root compromise and subsequent trust abuse, leadership may need to assume that host-level trust, workload identities, administrative credentials, deployment secrets, signing material, cloud access, and dependent production systems were exposed until proven otherwise. That response may require emergency patch validation, host isolation, forensic preservation, credential and token rotation, cloud-role review, Kubernetes and container investigation, CI/CD and repository review, workload replacement, legal and compliance assessment, cyber-insurance coordination, executive reporting, and formal confirmation that affected infrastructure can safely return to service.

S3 — Why This Matters Now

·        Multiple Linux local privilege-escalation CVEs can produce the same durable operational sequence: constrained execution, exploit staging, abnormal privilege transition, root-level activity, sensitive-resource access, security-control degradation, persistence, workload-boundary interaction, or downstream expansion.

·        Public proof-of-concept availability, exploit adaptation, vulnerable workload exposure, and recurring discovery of Linux privilege-escalation flaws increase urgency, but compromise confidence must come from correlated endpoint, audit, identity, file, container, Kubernetes, cloud, CI/CD, and network evidence.

·        Linux systems frequently support internet-facing applications, production services, Kubernetes nodes, container hosts, CI runners, build infrastructure, automation platforms, identity-adjacent services, repositories, databases, and other business-critical workloads.

·        Root access can expose SSH keys, service credentials, cloud tokens, workload identities, Kubernetes service account material, runtime sockets, host-mounted secrets, CI/CD credentials, repository tokens, signing material, and security-control configurations.

·        Patching alone is not sufficient containment when suspicious low-privilege execution, abnormal root-owned process creation, sensitive-resource access, security-agent degradation, persistence, credential use, or infrastructure expansion occurred before remediation.

·        The highest-risk condition occurs when constrained execution is followed by abnormal root activity and access to credentials, cloud identity material, Kubernetes resources, runtime sockets, host-mounted secrets, deployment systems, repositories, or internal management infrastructure.

·        Containerized, autoscaled, ephemeral, cloud-hosted, and CI/CD environments can make malicious activity difficult to reconstruct because affected workloads may be replaced, terminated, rebuilt, or rotated before evidence is preserved.

·        Legitimate administration, package management, configuration management, orchestration, vulnerability validation, build activity, deployment activity, backup operations, troubleshooting, and incident response can resemble portions of the attack sequence when viewed in isolation.

·        Missing process ancestry, inconsistent effective-user fields, incomplete audit policy, weak container-to-host mapping, poor pod-to-node mapping, stale vulnerability data, limited sensitive-file visibility, or short telemetry retention can force a broader and more expensive investigation.

·        Detection focused only on CVE identifiers, kernel versions, exploit filenames, public repositories, hashes, or isolated SUID activity cannot provide durable assurance across changing Linux privilege-escalation techniques.

S4 — Key Judgments

·        Linux foothold-to-root activity should be treated as a host-trust, workload-identity, credential-exposure, cloud-access, and infrastructure-expansion risk, not only as a vulnerability-management or patching issue.

·        The primary enterprise risk is reduced ability to determine whether low-privilege access led to root-level execution, sensitive-resource exposure, security-control degradation, persistence, credential use, workload-boundary abuse, or downstream compromise.

·        Suspicious writable-path or transient execution followed by an abnormal effective-user transition, root-owned process creation, sensitive-resource access, security-agent degradation, persistence, or unusual outbound or east-west activity is the strongest executive risk signal.

·        A vulnerable kernel, package, image, or workload finding should not be treated as confirmed compromise without supporting process, identity, file, root-activity, trust-material, security-control, container, Kubernetes, cloud, CI/CD, or network evidence.

·        Business exposure increases sharply when affected systems are internet-facing, production-critical, identity-adjacent, container hosts, Kubernetes nodes, CI runners, build systems, privileged automation platforms, or trusted access points into cloud and deployment environments.

·        Root compromise on a Linux host can invalidate confidence in locally stored credentials, workload identities, service accounts, SSH material, repository access, deployment secrets, signing material, and connected infrastructure.

·        Incomplete telemetry increases cost because the organization may need to reconstruct foothold activity, exploit staging, privilege transition, root process ancestry, sensitive-resource access, credential use, cloud activity, Kubernetes interaction, CI/CD access, and internal expansion across separate systems.

·        Rebuilding or replacing an affected workload may be necessary when root compromise cannot be ruled out, process ancestry is incomplete, security controls were degraded, trust material was exposed, or forensic evidence is insufficient.

·        The most damaging outcome occurs when Linux privilege escalation enables cloud-role abuse, Kubernetes node or cluster access, container-host compromise, CI/CD or repository access, credential reuse, signing-material exposure, lateral movement, production disruption, destructive activity, or multi-system compromise.

·        Detection must remain behavior-driven so that the organization can identify comparable compromise paths across multiple CVEs, exploit implementations, kernel subsystems, authentication mechanisms, namespace boundaries, filesystem behaviors, and workload types.

S5 — Executive Risk Summary

Business Risk

Linux foothold-to-root compromise can weaken the organization’s ability to trust systems that run business applications, support cloud workloads, host containers, operate Kubernetes nodes, execute CI/CD pipelines, build software, manage automation, store credentials, or connect to production infrastructure. Risk increases when affected systems support customer-facing services, regulated workloads, authentication functions, developer platforms, repositories, deployment systems, databases, storage, backup services, monitoring platforms, identity-adjacent services, or privileged administrative workflows. The business impact is not limited to the exploited host; it can expand into uncertainty over whether adversaries accessed credentials, workload identities, Kubernetes tokens, cloud metadata, runtime sockets, deployment secrets, repository tokens, signing material, security-control configurations, or downstream systems after obtaining root-level control.

Technical Cause

The risk is driven by a constrained or low-privilege foothold combined with a local privilege-escalation path that enables abnormal effective-user transition, root-owned process creation, or root-level access to protected resources. The enabling mechanism may involve a Linux kernel flaw, vulnerable package, SUID or setgid path, authentication weakness, namespace interaction, mount function, filesystem behavior, race condition, memory-corruption issue, synchronization flaw, privileged utility, container-host boundary, or other local trust failure. Technical exposure becomes material when suspicious execution from writable, transient, user-controlled, build, workspace, mounted, or container-layer paths aligns with exploit staging, privileged-binary interaction, abnormal root activity, credential access, security-control modification, persistence, cloud identity use, Kubernetes access, CI/CD activity, or internal expansion. Exposure increases when process lineage, effective-user telemetry, audit coverage, file-access visibility, vulnerable-state history, workload ownership, container mapping, node mapping, cloud identity records, and administrative baselines are incomplete.

Threat Posture

The threat posture is elevated because Linux privilege escalation can convert limited application, service-account, container, CI-runner, workload, or user access into unrestricted host control and broader infrastructure trust abuse. Exploitation may follow remote application compromise, credential theft, web-shell activity, exposed-service access, malicious dependency execution, compromised build activity, container access, or another constrained foothold. The posture becomes critical when root-level access occurs on cloud instances, Kubernetes worker nodes, container hosts, CI runners, build systems, privileged automation platforms, identity-adjacent systems, repositories, signing infrastructure, production databases, storage systems, or other workloads that hold reusable credentials or trusted paths into downstream environments.

Executive Decision Requirement

Executives must require measurable assurance that high-risk Linux systems are inventoried, vulnerable-state and patch history are validated, suspicious low-privilege activity is investigated, process ancestry and effective-user transitions are preserved, root-level activity is reviewed, sensitive credentials and trust material are assessed, security-control health is confirmed, container and Kubernetes boundaries are examined, cloud identities and roles are reviewed, CI/CD and repository access is validated, and affected workloads are isolated, rebuilt, or replaced when trust cannot be restored. Leadership should also require evidence that infrastructure, cloud, platform engineering, application owners, identity teams, SOC, incident response, legal, compliance, cyber insurance, communications, and business owners can support rapid decisions if root compromise, credential exposure, workload-identity abuse, production disruption, or infrastructure expansion is suspected.

S6 — Executive Cost Summary

Linux foothold-to-root privilege escalation creates financial exposure because the organization must determine whether a constrained foothold became unrestricted host control and whether that control exposed credentials, workload identities, cloud access, Kubernetes resources, runtime sockets, deployment systems, repositories, signing material, security controls, or downstream production infrastructure. The cost profile is different from a routine kernel or package update because a root-compromised Linux system may sit inside a trusted workload path, run business-critical services, support production applications, execute CI/CD pipelines, host containers, operate as a Kubernetes node, manage automation, or hold credentials that provide access beyond the local asset. Response cost is driven by the work required to validate vulnerable-state history, preserve endpoint and audit evidence, reconstruct process ancestry, confirm effective-user transitions, inspect root activity, review sensitive-resource access, assess security-agent health, analyze persistence, examine outbound and east-west communication, validate cloud and Kubernetes activity, rotate credentials and tokens, rebuild affected systems, and prove that host and workload trust have been restored.

Cost increases materially when process command lines are truncated, parent-child relationships are incomplete, effective-user or UID fields are unreliable, audit policy excludes temporary paths or sensitive resources, container-to-host or pod-to-node mapping is unavailable, vulnerability data is stale, ephemeral workloads have already been replaced, security agents were degraded, sensitive-file reads were not captured, cloud identity activity cannot be tied back to the host, CI/CD and repository records use separate identities, or telemetry retention is too short to reconstruct the compromise window. The highest-cost cases occur when suspected or confirmed root compromise affects Kubernetes nodes, container hosts, cloud instances, CI runners, build infrastructure, privileged automation systems, identity-adjacent services, production databases, repositories, deployment platforms, signing systems, backup environments, or multiple workloads that share credentials, images, roles, tokens, or downstream trust relationships.

Low Impact Scenario

Rapid investigation confirms suspicious exploit-attempt, writable-path execution, compilation, SUID interaction, or local privilege-escalation testing without evidence of abnormal root-owned process creation, sensitive-resource access, security-control degradation, persistence, credential use, cloud identity activity, Kubernetes or container-host abuse, CI/CD access, or downstream expansion. Activity may involve public proof-of-concept-like artifacts, failed execution, kernel warnings, short-lived files, unusual privileged-binary interaction, or vulnerable-state exposure, but endpoint, audit, identity, vulnerability, file, network, container, Kubernetes, cloud, and change-management records support a failed, contained, or non-impacting event. Response is limited to targeted patch validation, host isolation where necessary, evidence preservation, focused hunting, administrative review, credential precaution, short-term monitoring, and executive assurance that host and workload trust were not materially affected. Estimated impact $300K - $2.5M.

Moderate Impact Scenario

Confirmed or strongly suspected Linux privilege escalation affects one or more production, cloud, container, Kubernetes, CI/CD, build, or high-value Linux systems where suspicious low-privilege execution aligns with abnormal root-owned process creation, privileged-resource access, security-control degradation, persistence, rare outbound activity, credential access, cloud metadata access, runtime-socket interaction, or unusual internal expansion. The organization cannot immediately determine whether root access exposed SSH keys, service credentials, workload identities, Kubernetes tokens, cloud roles, repository credentials, deployment secrets, signing material, or downstream systems. Response requires enterprise-focused asset review, process and audit reconstruction, root-activity analysis, sensitive-resource review, credential and token rotation, cloud and Kubernetes investigation, CI/CD and repository validation, security-control restoration, workload rebuilds, legal and compliance review, cyber-insurance coordination, executive reporting, and strengthened monitoring for post-remediation activity. Estimated impact $4M - $25M.

High Impact Scenario

Linux foothold-to-root compromise becomes an enterprise-impact event when confirmed or suspected root access results in cloud-role abuse, Kubernetes node or cluster compromise, container-host takeover, CI/CD or repository access, signing-material exposure, credential reuse, privileged automation abuse, lateral movement, production disruption, destructive activity, ransomware deployment, data exposure, or multi-system compromise. The organization may need to assume that affected hosts, workload identities, SSH keys, service accounts, cloud credentials, Kubernetes tokens, deployment secrets, repository access, container images, signing material, production services, and downstream infrastructure were exposed until audit evidence proves otherwise. Response may require broad forensic investigation, emergency workload isolation, credential and token rotation, cloud-role restriction, node and host replacement, container-image validation, pipeline shutdown, repository and signing-system review, production recovery, customer or partner notification analysis, legal and privacy escalation, cyber-insurance engagement, communications planning, executive and board reporting, and formal validation that affected environments can safely return to operation. Estimated impact $30M - $150M+.

S6A — Key Cost Drivers

·        Number and sensitivity of affected Linux servers, cloud instances, Kubernetes nodes, container hosts, CI runners, build systems, developer systems, privileged automation hosts, identity-adjacent systems, production workloads, and high-value operational assets.

·        Scope of the initial foothold, including exposed services, compromised application accounts, service accounts, workload identities, container processes, CI jobs, developer access, web shells, malicious dependencies, or other constrained execution paths.

·        Availability and retention of Linux EDR, audit, Sysmon for Linux, osquery, eBPF, kernel, journal, process, file, authentication, security-agent, vulnerability, container, Kubernetes, cloud, CI/CD, DNS, proxy, firewall, NDR, and network-flow telemetry.

·        Whether response must reconstruct low-privilege execution, exploit staging, compilation, permission changes, privileged-binary interaction, abnormal effective-user transition, root process creation, credential access, persistence, security-control degradation, workload-boundary interaction, and downstream expansion across separate telemetry sources.

·        Reliability of parent-process lineage, real-user fields, effective-user fields, UID and effective-UID values, executable paths, working directories, timestamps, container identifiers, pod identifiers, namespace identifiers, node mappings, workload identities, and canonical asset identifiers.

·        Scope of credentials and trust material potentially exposed, including SSH keys, password stores, service credentials, application secrets, cloud credentials, workload identities, Kubernetes service account tokens, host-mounted secrets, CI/CD credentials, repository tokens, package-registry credentials, signing keys, and deployment secrets.

·        Scope of privileged workload and host-control interfaces potentially accessed, including kubelet resources, container runtime sockets, host namespaces, hostPath-mounted resources, cloud metadata services, and node-level or infrastructure-management interfaces.

·        Size and complexity of the affected environment, including autoscaling groups, ephemeral instances, container clusters, Kubernetes node pools, multi-cloud workloads, hybrid infrastructure, shared images, golden images, build pipelines, artifact platforms, deployment systems, and production dependencies.

·        Ability to distinguish legitimate administration, sudo activity, package management, configuration management, orchestration, patching, backup, vulnerability validation, build activity, deployment activity, troubleshooting, red-team work, and incident-response activity from attacker-driven behavior.

·        Need to rotate or review administrative credentials, SSH keys, service accounts, workload identities, cloud roles, Kubernetes tokens, CI/CD secrets, repository credentials, package-registry credentials, signing material, API tokens, and reused passwords.

·        Business disruption caused by emergency host isolation, workload shutdown, node cordoning, container rescheduling, pipeline suspension, repository restrictions, credential rotation, cloud-role restriction, workload replacement, image rebuilds, production failover, and service restoration.

·        Scope of security-control degradation, including EDR stopping, audit-policy changes, logging disruption, telemetry-forwarding modification, cloud-agent tampering, vulnerability-scanner interference, container-security degradation, or deliberate evidence destruction.

·        Legal, privacy, regulatory, cyber-insurance, communications, customer, partner, executive, or board-level obligations triggered by credential exposure, cloud compromise, Kubernetes compromise, production disruption, data access, signing-material exposure, incomplete containment, or inability to prove non-exposure.

S6B — Compliance and Risk Context

Figure 1

Linux foothold-to-root privilege escalation and cloud workload trust compromise executive risk model showing how constrained execution can escalate into root-level control, credential and trust-material exposure, security-control degradation, workload-boundary abuse, cloud or Kubernetes access, downstream infrastructure expansion, operational disruption, and enterprise-level business exposure.

Compliance Exposure Indicator

High

Risk Register Entry

Risk Title

Linux Foothold-to-Root Privilege Escalation and Cloud Workload Trust Compromise Risk

Risk Description

Adversaries may use Linux local privilege-escalation behavior to move from constrained user, application, service-account, container, workload, CI-runner, or other low-privilege execution into abnormal root-owned process creation, unrestricted host control, sensitive-resource access, security-control degradation, persistence, credential use, workload-boundary abuse, cloud identity activity, Kubernetes access, CI/CD or repository access, and downstream infrastructure expansion. This may increase business interruption, credential and token exposure, cloud and container trust loss, production-service disruption, software-supply-chain concern, regulated workload exposure, legal and compliance review, cyber-insurance scrutiny, customer or partner notification analysis, and board-level concern around Linux, cloud, Kubernetes, and deployment-infrastructure resilience. Compliance exposure should be driven by local evidence of abnormal privilege transition, root activity, sensitive-resource access, credential use, security-control degradation, persistence, cloud or Kubernetes activity, downstream access, production disruption, or post-remediation behavior, not by vulnerable-version status, CVE association, public exploit availability, KEV status, isolated SUID execution, or writable-path activity alone.

Likelihood

High

Impact

Severe

Risk Rating

Critical

Annualized Risk Exposure

Estimated annualized exposure of $4M - $30M+ for materially exposed enterprise environments where recurring Linux vulnerability exposure, internet-facing or production-critical workloads, cloud instances, Kubernetes nodes, container hosts, CI runners, build infrastructure, privileged automation, incomplete process lineage, unreliable effective-user fields, limited audit coverage, weak sensitive-resource monitoring, poor container-to-host mapping, incomplete cloud identity correlation, short telemetry retention, or concentrated credential and trust dependencies increase both incident likelihood and response burden. A realized severe event may exceed $30M - $150M+ when Linux privilege escalation expands into cloud-role abuse, Kubernetes compromise, container-host takeover, CI/CD or repository access, signing-material exposure, credential reuse, production disruption, destructive activity, ransomware deployment, multi-system compromise, incomplete containment, cyber-insurance review, legal escalation, communications response, or board-level reporting.

S7 — Risk Drivers

·        Linux systems frequently operate as production servers, cloud workloads, Kubernetes nodes, container hosts, CI runners, build systems, privileged automation platforms, identity-adjacent services, repositories, databases, storage systems, and other trust-sensitive infrastructure.

·        A constrained foothold can become materially more dangerous when a local privilege-escalation path allows an adversary to move from application, service-account, workload, container, CI, developer, or user context into effective root control.

·        Root-level control can expose credentials, SSH material, service secrets, cloud identities, Kubernetes tokens, runtime sockets, host-mounted secrets, CI/CD credentials, repository tokens, signing material, and security-control configurations.

·        Multiple CVEs, kernel subsystems, race conditions, memory-corruption issues, filesystem behaviors, namespace interactions, authentication weaknesses, SUID paths, and privileged utilities can produce the same operational compromise sequence.

·        Vulnerable-version status, public proof-of-concept availability, exploit reporting, and KEV status create urgency, but they cannot prove compromise or non-compromise without correlated process, identity, root-activity, sensitive-resource, security-control, workload, cloud, Kubernetes, CI/CD, or network evidence.

·        Patch completion can create false closure when pre-remediation exploit staging, abnormal root activity, credential access, security-agent degradation, persistence, or downstream expansion has not been reviewed.

·        Legitimate administration, package installation, configuration management, orchestration, backup, vulnerability validation, build activity, deployment activity, troubleshooting, and incident response can resemble portions of the attack chain without strong behavioral baselines.

·        Ephemeral cloud instances, containers, Kubernetes nodes, and CI runners may be terminated, rebuilt, or rotated before investigators preserve process, file, identity, and workload evidence.

·        Missing or inconsistent process ancestry, effective-user fields, audit records, file-access events, container mappings, Kubernetes node mappings, vulnerability history, cloud identity data, CI/CD records, DNS logs, proxy logs, firewall logs, or network-flow telemetry can increase investigation scope and cost.

·        Security-agent tampering, audit-policy modification, log deletion, telemetry-forwarding disruption, and workload replacement can create evidence gaps precisely when confirmation is most important.

·        Business exposure increases when affected systems hold reusable credentials, support privileged automation, front regulated workloads, operate production clusters, build or sign software, manage deployment systems, or connect to multiple downstream environments.

·        Credential exposure, cloud-role abuse, Kubernetes compromise, CI/CD access, repository compromise, signing-material exposure, production disruption, and incomplete containment can transform a local privilege-escalation event into legal, regulatory, communications, cyber-insurance, customer, partner, executive, and board-level exposure.

S8 — Bottom Line for Executives

Linux foothold-to-root privilege escalation and cloud workload trust compromise should be treated as a high-priority host-trust, credential-protection, workload-identity, cloud-security, Kubernetes, CI/CD, and production-resilience risk because a constrained Linux foothold can become unrestricted root control and a path into connected infrastructure. The executive question is not only whether the affected kernel or package was patched, whether a public exploit exists, whether a vulnerable image was replaced, or whether the host remains online; it is whether the organization can prove that suspicious low-privilege activity did not lead to abnormal root execution, credential or token exposure, security-control degradation, persistence, container-host interaction, Kubernetes access, cloud-role use, CI/CD or repository access, internal expansion, or continued activity after remediation. Response must focus on validating exposed and high-value assets, preserving process and audit evidence, confirming effective-user transitions, reviewing root activity, assessing sensitive-resource access, validating security-control health, examining container and Kubernetes boundaries, reviewing cloud and CI/CD trust, rotating exposed credentials, rebuilding systems where required, and confirming that host and workload trust have been restored before leadership relies on the affected environment.

S9 — Board-Level Takeaway

Linux privilege escalation becomes a board-level issue when limited access to a workload, service, application, container, CI runner, developer environment, or user context can be converted into root control over infrastructure that holds credentials, cloud identities, deployment secrets, Kubernetes access, repository tokens, signing material, or production dependencies. The risk is not simply that a Linux vulnerability existed, a patch was required, a public exploit was released, or suspicious local execution occurred; it is the possibility that adversaries used a foothold-to-root path to expose trust material, weaken security controls, establish persistence, abuse workload boundaries, access cloud or Kubernetes environments, compromise CI/CD or repository systems, disrupt production, or expand across multiple assets. Leadership should require evidence that Linux asset inventory, vulnerable-state history, process and audit telemetry, identity-transition visibility, sensitive-resource monitoring, container and Kubernetes mapping, cloud-role review, CI/CD and repository validation, credential rotation, workload-rebuild capability, incident-response readiness, legal readiness, and business-continuity planning can support rapid and defensible decisions when Linux host trust cannot be confirmed.

S10 — Threat Overview

Linux foothold-to-root privilege escalation and cloud workload trust compromise describe adversary behavior in which constrained access to a Linux host, application service, container process, CI runner, build system, developer environment, workload identity, or other low-privilege execution context may be converted into root-level control through a vulnerable kernel path, package flaw, authentication weakness, SUID or setgid mechanism, namespace interaction, mount behavior, filesystem condition, memory-corruption issue, race condition, synchronization flaw, privileged utility, or comparable local trust-boundary failure. Multiple Linux local privilege-escalation CVEs are directly covered by this behavior model, but the durable enterprise risk is broader than any single CVE identifier, exploit name, kernel subsystem, proof-of-concept implementation, vulnerable version, or privileged binary.

·        This is not only a vulnerable-version, CVE, KEV, public proof-of-concept, exploit-filename, hash, repository, SUID, syscall, kernel-warning, or isolated root-process model.

·        The core threat behavior is movement from constrained execution into abnormal privilege transition and unauthorized root-level execution, which may then be followed by sensitive-resource access, security-control degradation, persistence, workload-boundary abuse, credential use, or downstream infrastructure expansion.

·        Internet-facing Linux servers, cloud instances, Kubernetes worker nodes, container hosts, CI runners, build systems, developer infrastructure, privileged automation platforms, identity-adjacent systems, and production-critical workloads represent the highest exposure when an adversary can first obtain constrained execution.

·        The primary enterprise risk is reduced ability to determine whether suspicious local execution remained limited to failed exploitation, vulnerability validation, troubleshooting, build activity, package management, or approved administration, or crossed into unauthorized root control and broader trust compromise.

·        Linux endpoint telemetry, audit records, process ancestry, effective-user fields, file activity, security-agent health, vulnerability history, container context, Kubernetes records, cloud identity telemetry, CI/CD activity, and network data may be incomplete or difficult to reconcile during active investigation.

·        Suspected root compromise can create uncertainty around host trust, workload identities, SSH material, service credentials, cloud roles, Kubernetes tokens, runtime sockets, host-mounted secrets, CI/CD credentials, repository access, signing material, security-control integrity, production availability, and downstream infrastructure exposure.

·        Public reporting on individual Linux privilege-escalation CVEs, exploit releases, exploitation attempts, or KEV inclusion should increase urgency without narrowing the assessment into a single-CVE, exploit-artifact, kernel-version, actor, or IOC-only model.

S11 — Threat Classification and Type

Threat Type

Linux local privilege escalation and cloud workload trust compromise risk.

Threat Sub-Type

Constrained or low-privilege foothold escalation, local kernel or package exploitation, SUID or setgid abuse, authentication-boundary failure, namespace or mount abuse, filesystem exploitation, memory-corruption exploitation, race-condition or synchronization abuse, privileged-utility misuse, abnormal effective-user transition, root-owned process creation, credential and secret access, security-control degradation, persistence, workload-boundary interaction, cloud workload identity abuse, and downstream infrastructure expansion.

Operational Classification

Linux host privilege-boundary compromise, root-level trust loss, workload-identity exposure, cloud and Kubernetes trust-path abuse, and downstream infrastructure expansion pathway.

Primary Function

Abuse a constrained Linux execution context to move from low-privilege access into root-level control, protected-resource access, security-control modification, persistence, credential use, workload-boundary interaction, cloud or Kubernetes access, or internal expansion, creating uncertainty around host trust, workload identity, containment completeness, credential exposure, production integrity, and downstream system assurance.

S12 — Campaign or Activity Overview

Figure 2

Linux foothold-to-root privilege escalation and cloud workload trust compromise activity model showing constrained execution, exploit staging, privilege-boundary interaction, abnormal root transition, and possible post-root credential access, security-control degradation, persistence, workload-boundary abuse, or downstream infrastructure expansion.

This report assesses Linux foothold-to-root privilege escalation and cloud workload trust compromise as a durable behavior class rather than a single CVE, exploit release, vulnerable package, kernel advisory, SUID binary, proof-of-concept repository, actor cluster, or patch event. The core activity pattern begins with constrained execution on a Linux system or workload, progresses through local exploit staging and privilege-boundary interaction, and may result in unauthorized root-level execution. Successful escalation may then enable one or more conditional post-root behaviors, including credential or trust-material access, security-control degradation, persistence, workload-boundary abuse, or expansion into connected cloud, Kubernetes, CI/CD, repository, or production environments.

·        The activity is best understood as a host-trust, workload-identity, credential-exposure, cloud-security, Kubernetes, CI/CD, and production-resilience threat rather than a routine patch-management issue or isolated local exploit event.

·        Adversaries may begin from compromised web services, exposed applications, stolen credentials, service accounts, application accounts, containers, CI jobs, developer systems, malicious dependencies, web shells, or other constrained execution contexts.

·        Exploit staging may involve temporary files, short-lived scripts, compiled ELF binaries, source code, build tools, interpreters, permission changes, privileged utilities, authentication mechanisms, namespaces, mount functions, or unfamiliar executables.

·        Activity may remain limited to failed exploit attempts, vulnerable-state probing, kernel warnings, process faults, SUID interaction, compilation, or short-lived local execution.

·        Successful privilege escalation is indicated by abnormal effective-user transition, root-owned process creation, or other unauthorized root-level execution linked to the constrained foothold.

·        Post-root activity may include access to SSH keys, service credentials, workload identities, cloud credentials, Kubernetes service account tokens, host-mounted secrets, CI/CD credentials, repository tokens, package-registry credentials, deployment secrets, or signing material.

·        Container-originated or pod-originated activity may progress into host-level root execution, namespace interaction, runtime-socket use, kubelet access, host-mounted resource access, or node-level resource interaction.

·        Cloud and workload trust abuse may involve metadata-service access, managed identity use, role activity, secret retrieval, storage access, snapshot activity, infrastructure-management APIs, or security-control changes after suspected root compromise.

·        Actor names, exploit names, CVE references, KEV status, public proof-of-concept releases, filenames, hashes, or kernel-specific indicators should enrich the assessment rather than replace local behavior-led evidence of privilege transition and post-root activity.

S13 — Targets and Exposure Surface

The exposure surface includes Linux systems and workloads where an adversary can obtain constrained execution and where successful privilege escalation could expose host-level control, credentials, cloud or Kubernetes trust, CI/CD infrastructure, repositories, signing material, production services, or downstream systems. It also includes the privileged mechanisms, sensitive paths, workload boundaries, identities, sockets, secrets, and management relationships reachable from the affected host.

·        Internet-facing Linux servers, application servers, API backends, web servers, reverse proxies, database servers, file-transfer systems, identity-adjacent systems, and production-critical workloads.

·        Cloud-hosted Linux instances, autoscaling groups, ephemeral workloads, golden images, image templates, managed instance groups, node pools, and hybrid-cloud Linux infrastructure.

·        Kubernetes worker nodes, control-adjacent Linux systems, container hosts, privileged pods, host-networked workloads, host-PID workloads, hostPath-mounted workloads, kubelet resources, and node-level management paths.

·        CI runners, build servers, developer infrastructure, artifact builders, package builders, deployment systems, privileged automation hosts, infrastructure-as-code runners, and release-management systems.

·        Constrained execution contexts, including application users, web-service users, service accounts, container users, workload identities, CI users, developer accounts, automation accounts, and local non-administrative users.

·        Writable and transient execution paths, including temporary directories, shared-memory paths, user home directories, application workspaces, CI workspaces, build directories, runner paths, mounted volumes, and container writable layers.

·        Privilege-boundary mechanisms, including SUID-root binaries, setuid or setgid paths, authentication utilities, sudo or equivalent workflows, namespaces, mount functions, privileged services, kernel interfaces, and other elevation mechanisms.

·        Sensitive resources, including /etc/shadow, /etc/sudoers, /root/.ssh, service credentials, application secrets, cloud credentials, workload identity material, Kubernetes tokens, kubelet resources, container runtime sockets, host-mounted secrets, CI/CD credentials, repository credentials, package-registry credentials, and signing material.

·        Persistence and control paths, including cron, systemd, init scripts, shell profiles, SSH authorized keys, users, groups, sudoers, authentication policy, security-agent paths, audit configuration, logging configuration, telemetry forwarding, cloud-agent configuration, and workload-protection controls.

·        Downstream trust relationships, including cloud accounts, Kubernetes clusters, container registries, repositories, package registries, deployment systems, artifact platforms, databases, storage systems, backup environments, identity services, monitoring platforms, and infrastructure-management systems.

·        Environments with incomplete Linux inventory, weak process telemetry, unreliable effective-user fields, insufficient audit coverage, stale vulnerability records, poor container-to-host mapping, incomplete pod-to-node mapping, weak sensitive-file visibility, short telemetry retention, unclear workload ownership, or incomplete trust-path mapping.

S14 — Sectors / Countries Affected

Sectors Affected

·        Technology, SaaS, software, telecommunications, hosting, cloud-service, managed-service, and digital-platform organizations operating large Linux, container, Kubernetes, CI/CD, or cloud-workload estates.

·        Financial services, insurance, banking, payment-adjacent, legal, consulting, and professional-services organizations using Linux systems for customer portals, transaction platforms, identity services, automation, repositories, or regulated workloads.

·        Healthcare, life sciences, public-sector, education, research, nonprofit, and regulated-service organizations using Linux infrastructure for applications, data platforms, scientific workloads, portals, cloud services, or operational systems.

·        Retail, e-commerce, hospitality, travel, transportation, logistics, media, marketing, and customer-facing service organizations running Linux-based web services, APIs, data platforms, reservation systems, support platforms, or high-availability applications.

·        Manufacturing, industrial, energy, utilities, supply-chain, aerospace, engineering, and supplier-dependent organizations using Linux for automation, engineering systems, production support, remote services, cloud workloads, repositories, or build infrastructure.

·        Organizations operating Kubernetes clusters, container platforms, CI/CD pipelines, software factories, package repositories, artifact platforms, signing systems, privileged automation, cloud-native applications, or infrastructure-as-code environments.

·        Large enterprises, distributed organizations, cloud-forward organizations, multi-region operators, and managed hosting customers with complex Linux trust relationships, shared images, reusable credentials, workload identities, or centralized deployment systems.

Countries Affected

·        Global.

·        Exposure is not limited to a single country or region because Linux servers, cloud workloads, Kubernetes platforms, container hosts, CI/CD systems, developer infrastructure, and automation platforms are deployed globally across enterprise, public-sector, regulated, industrial, and service environments.

·        Countries with large populations of cloud-hosted infrastructure, managed services, software-development environments, internet-facing Linux applications, Kubernetes deployments, technology providers, and regional data centers may face elevated operational exposure.

·        Country-specific impact should be assessed by Linux workload exposure, vulnerable-state presence, public-service reachability, workload criticality, cloud and Kubernetes dependency, credential concentration, CI/CD trust, telemetry maturity, regulatory obligations, and incident-response capability rather than geography alone.

S15 — Adversary Capability Profiling

Capability Level

Moderate

Technical Sophistication

Adversaries require enough technical capability to obtain constrained execution on a Linux system, identify a viable local privilege-escalation path, stage or adapt exploit material, interact with privileged mechanisms, and determine whether the resulting behavior produced root-level control. Lower-complexity activity may involve public proof-of-concept reuse, commodity exploit replay, scripted compilation, known vulnerable-version targeting, standard SUID or authentication abuse, temporary-file execution, or direct use of published local exploit code. Higher-capability activity may involve custom exploit adaptation, kernel or package-specific changes, race-condition tuning, namespace or mount manipulation, memory-corruption exploitation, in-memory execution, container-aware exploitation, telemetry suppression, selective credential access, stealthy persistence, and coordinated expansion into cloud, Kubernetes, CI/CD, repository, or production environments.

Infrastructure Maturity

Moderate

Infrastructure maturity varies by activity pattern. Lower-maturity activity may rely on a single compromised host, public exploit code, commodity web shells, exposed services, basic download infrastructure, common cloud hosting, or direct local compilation. Higher-maturity activity may use separate foothold and payload infrastructure, encrypted staging, trusted repositories, compromised developer systems, segmented command-and-control infrastructure, cloud-hosted redirectors, stolen workload identities, container-aware tooling, and activity designed to resemble administration, vulnerability validation, package management, build operations, deployment activity, or incident response.

Operational Scale

Single compromised Linux workload to multi-environment infrastructure trust exposure

Operational scale ranges from suspicious local activity on one Linux host to broader enterprise compromise when multiple servers, cloud instances, Kubernetes nodes, container hosts, CI runners, build systems, automation platforms, repositories, identities, or production workloads share vulnerable states, credentials, images, roles, tokens, or downstream trust relationships. Within one organization, scale can expand from one constrained foothold into root access, credential exposure, security-control degradation, persistence, cloud-role abuse, Kubernetes access, CI/CD compromise, repository access, signing-material exposure, lateral movement, destructive activity, or multi-system compromise.

Escalation Likelihood

Moderate to High

Escalation likelihood is moderate to high when suspicious low-privilege execution is followed by exploit staging, privileged-binary interaction, abnormal effective-user transition, root-owned process creation, sensitive-resource access, security-control degradation, persistence, cloud metadata access, runtime-socket use, kubelet interaction, Kubernetes token use, CI/CD credential access, repository access, rare outbound communication, or unusual internal expansion. Escalation likelihood increases when affected systems are internet-facing, production-critical, cloud-hosted, containerized, identity-adjacent, privileged, ephemeral, weakly monitored, highly connected, or responsible for build, deployment, signing, orchestration, authentication, storage, backup, or critical application delivery.

S16 — Targeting Probability Assessment

Overall Targeting Probability

High

Targeting Drivers

·        Linux systems commonly support internet-facing services, cloud applications, production workloads, Kubernetes nodes, container hosts, CI/CD pipelines, build systems, repositories, databases, and privileged automation.

·        Initial access through exposed applications, compromised credentials, service accounts, web shells, vulnerable services, containers, developer systems, or malicious dependencies can provide the constrained execution needed for local privilege escalation.

·        Public exploit knowledge, proof-of-concept availability, repeatable vulnerable conditions, commodity automation, and widely deployed Linux packages can lower the barrier for opportunistic adversaries.

·        Root access can provide direct access to credentials, workload identities, cloud roles, Kubernetes tokens, runtime sockets, CI/CD secrets, repository tokens, signing material, security controls, and downstream production systems.

·        Attackers benefit from environments where Linux inventory, vulnerable-state history, process ancestry, effective-user telemetry, audit coverage, container mapping, node mapping, sensitive-resource monitoring, cloud identity correlation, and administrative baselines are incomplete.

·        Ephemeral workloads, autoscaling, container replacement, node rotation, short telemetry retention, stale vulnerability records, and inconsistent agent coverage can make exploitation harder to reconstruct and easier to misclassify.

·        Normal administration, package management, configuration management, orchestration, vulnerability validation, build activity, deployment activity, backup operations, troubleshooting, red-team work, and incident-response cleanup can make attacker-driven activity harder to distinguish without strong baselines.

·        Targeting probability should be assessed through foothold exposure, vulnerable-state presence, workload criticality, privilege-boundary opportunity, credential concentration, cloud or Kubernetes trust, CI/CD dependency, telemetry maturity, and local evidence of constrained-execution-to-root behavior rather than CVE count or exploit names alone.

Most Likely Targets

·        Internet-facing, partner-reachable, cloud-hosted, production, staging, disaster-recovery, and high-availability Linux systems where an adversary can first obtain constrained execution.

·        Linux application servers, web servers, API backends, reverse proxies, databases, file-transfer systems, identity-adjacent systems, monitoring platforms, and management systems.

·        Cloud Linux instances, autoscaling groups, instance templates, golden images, node pools, managed instance groups, and hybrid-cloud workloads with reusable identities or privileged roles.

·        Kubernetes worker nodes, container hosts, privileged pods, host-networked workloads, host-PID workloads, hostPath-mounted workloads, kubelet resources, and runtime-socket access paths.

·        CI runners, build systems, developer infrastructure, deployment platforms, artifact builders, package builders, software-signing systems, privileged automation hosts, and infrastructure-as-code runners.

·        Systems holding SSH keys, service credentials, cloud credentials, workload identities, Kubernetes tokens, CI/CD secrets, repository credentials, package-registry credentials, signing keys, or deployment material.

·        Environments with delayed patching, incomplete vulnerable-state validation, weak process telemetry, unreliable effective-user fields, limited audit coverage, poor workload mapping, weak security-agent protection, short telemetry retention, or insufficient credential and trust-path controls.

S17 — MITRE ATT&CK Chain Flow Mapping

Stage 1 — Constrained Linux Execution

The adversary operates from an application, service-account, container, CI-runner, developer, workload, or other low-privilege Linux execution context and may use shell or interpreter activity to prepare or execute local exploitation.

·        T1059 — Command and Scripting Interpreter.

Stage 2 — Local Privilege Escalation

The adversary exploits a vulnerable kernel path, package flaw, privileged mechanism, authentication boundary, namespace, filesystem behavior, race condition, synchronization flaw, or comparable local trust failure to cross the Linux privilege boundary.

·        T1068 — Exploitation for Privilege Escalation.

Stage 3 — Credential and Trust-Material Access

Following successful root-level execution, the adversary may access SSH material, service credentials, application secrets, cloud credentials, workload identities, Kubernetes service account tokens, host-mounted secrets, CI/CD credentials, repository credentials, package-registry credentials, deployment secrets, signing material, or other exposed trust resources.

·        T1552 — Unsecured Credentials.

Stage 4 — Security-Control Degradation

After obtaining elevated control, the adversary may disable, stop, modify, or interfere with endpoint protection, audit controls, logging, telemetry forwarding, cloud agents, vulnerability scanners, container-security controls, or workload-protection services.

·        T1562.001 — Impair Defenses: Disable or Modify Tools.

Stage 5 — Scheduled Root-Level Persistence

After obtaining elevated control, the adversary may establish persistence through root-level cron jobs.

·        T1053.003 — Scheduled Task/Job: Cron.

Stage 6 — Downstream Trust Expansion

The adversary may use valid user, service, workload, cloud, Kubernetes, CI/CD, repository, or deployment accounts and associated credentials exposed through the compromised Linux system to access connected infrastructure.

·        T1078 — Valid Accounts.

S18 — Attack Path Narrative (Signal-Aligned Execution Flow)

Linux foothold-to-root privilege escalation and cloud workload trust compromise begin when an adversary operates from an application, service-account, container, CI-runner, developer, workload, or other constrained Linux execution context. The core attack path is movement from constrained execution into unauthorized root-level control through a local privilege-escalation mechanism. Successful escalation may then enable one or more conditional post-root behaviors, including credential or trust-material access, security-control degradation, scheduled persistence, and downstream use of valid accounts. Ransomware deployment, destructive activity, broad data theft, software-supply-chain compromise, cluster-wide compromise, or cloud-account takeover remain conditional outcomes unless supporting telemetry confirms them.

Stage 1: Constrained Linux Execution

The adversary operates from a low-privilege Linux context obtained through a compromised application, exposed service, stolen account, service account, web shell, container process, CI job, developer system, or other foothold. Observable evidence may include shell or interpreter execution, application-service child processes, commands launched by service accounts, container-originated activity, CI-runner execution, unfamiliar local binaries, or execution from writable, transient, workspace, mounted, or container-layer paths. This stage does not establish privilege escalation by itself because legitimate applications, build systems, automation, and administrative workflows may generate similar behavior. It becomes material when constrained execution aligns with exploit staging, privileged-mechanism interaction, abnormal effective-user transition, or subsequent root-level activity.

Stage 2: Local Privilege Escalation

The adversary exploits a vulnerable kernel path, package flaw, privileged mechanism, authentication boundary, namespace, filesystem condition, race condition, synchronization flaw, or comparable local trust failure to cross the Linux privilege boundary. Observable evidence may include temporary exploit files, compiled ELF binaries, source code, build-tool execution, permission changes, repeated failed-to-success execution, unusual privileged-binary interaction, kernel warnings, process faults, service instability, or abnormal user-transition records. This stage becomes the central compromise point when a constrained process chain produces an effective-root process, root-owned shell, privileged utility, service process, or unfamiliar root executable outside an approved administrative workflow.

Stage 3: Credential and Trust-Material Access

Following successful root-level execution, the adversary may access SSH material, service credentials, application secrets, cloud credentials, workload identities, Kubernetes service account tokens, host-mounted secrets, CI/CD credentials, repository credentials, package-registry credentials, deployment secrets, or signing material. Observable evidence may include root-level reads, copies, archives, permission changes, ownership changes, token access, credential-file access, or unusual interaction with protected credential and secret paths. This stage increases business risk because exposed trust material may allow the adversary to impersonate workloads, services, administrators, automation identities, or deployment systems beyond the original host.

Stage 4: Security-Control Degradation

After obtaining elevated control, the adversary may disable, stop, modify, or interfere with endpoint protection, Linux audit controls, logging, telemetry forwarding, cloud agents, vulnerability scanners, container-security controls, workload-protection services, or related defensive mechanisms. Observable evidence may include agent stops, service disables, audit-policy changes, logging-configuration changes, log deletion, telemetry-forwarding disruption, protected-process termination, or confirmed control-health state changes. This stage becomes materially significant when defensive-control degradation follows suspicious root activity and cannot be tied to approved maintenance, security operations, incident response, package management, deployment, or troubleshooting.

Stage 5: Scheduled Root-Level Persistence

After obtaining elevated control, the adversary may establish recurring privileged execution through root-level cron jobs. Observable evidence may include new or modified root cron entries, unfamiliar scheduled scripts, execution from temporary or user-controlled paths, or scheduled commands that restore attacker-controlled activity. This stage increases containment risk because patching the original vulnerability or terminating the initial exploit process may not remove the recurring privileged access path.

Stage 6: Downstream Trust Expansion

The adversary may use valid user, service, workload, cloud, Kubernetes, CI/CD, repository, or deployment accounts and associated credentials exposed through the compromised Linux system to access connected hosts, cloud services, Kubernetes resources, CI/CD platforms, repositories, deployment systems, databases, storage systems, backup platforms, or production infrastructure. Observable evidence may include new account use, remote authentication, unusual SSH access, cloud API activity, Kubernetes API access, repository or package-registry access, deployment activity, storage access, snapshot activity, or abnormal east-west communication. This stage becomes high priority when downstream behavior aligns with suspicious Linux host activity by identity, asset, workload, resource, destination, or bounded time window.

S19 — Attack Chain Risk Amplification Summary

Linux foothold-to-root privilege escalation amplifies risk because it converts constrained execution into root-level control over systems that may hold credentials, workload identities, Kubernetes access material, cloud roles, CI/CD secrets, repository credentials, signing material, security-control configurations, privileged workload interfaces, and trusted paths into production infrastructure. The chain becomes materially more dangerous when suspicious low-privilege activity is followed by abnormal root-owned process creation, sensitive-resource access, defensive-control degradation, scheduled persistence, workload-boundary interaction, or downstream use of exposed trust material.

·        Exposed Linux footholds increase risk because adversaries may begin from compromised applications, vulnerable services, stolen accounts, web shells, containers, CI jobs, developer systems, or other constrained execution paths.

·        Suspicious constrained execution increases concern when shells, interpreters, compilers, build tools, temporary files, unfamiliar executables, or permission changes appear in writable or transient paths outside approved workflows.

·        Local privilege escalation increases risk because successful exploitation can bypass the original user, application, service-account, container, or workload restrictions and provide effective-root control.

·        Root-level execution amplifies impact because the adversary can access protected resources, alter system configuration, manipulate services, weaken monitoring, establish persistence, and interact with privileged host interfaces.

·        Credential and trust-material exposure increases business risk when affected resources include SSH keys, service credentials, cloud credentials, workload identities, Kubernetes service account tokens, host-mounted secrets, CI/CD secrets, repository credentials, deployment secrets, or signing material.

·        Security-control degradation increases uncertainty because endpoint, audit, logging, vulnerability, container-security, cloud-agent, or telemetry controls may become unreliable when compromise confirmation is most important.

·        Scheduled root-level persistence increases containment risk because recurring privileged execution may survive process termination, patching, workload restart, or incomplete remediation.

·        Container and Kubernetes environments increase scope when root access enables runtime-socket use, host-level interaction, kubelet access, host namespace interaction, hostPath access, or node-resource access.

·        Cloud-connected Linux systems increase exposure when root access enables metadata-service interaction, managed identity use, cloud-role activity, secret retrieval, storage access, snapshot access, or infrastructure-management activity.

·        CI/CD, repository, package-registry, deployment, and signing dependencies amplify risk when exposed credentials or tokens provide access to software-delivery and production trust paths.

·        Shared images, reusable credentials, common workload roles, repeated deployment patterns, or vulnerable node pools can extend one compromise pattern across multiple hosts or environments.

·        Ephemeral workloads increase investigation difficulty because instances, containers, pods, nodes, or runners may be replaced before process, file, identity, and trust-material evidence is preserved.

·        Business exposure increases when affected systems support production applications, regulated workloads, customer-facing services, privileged automation, build infrastructure, software delivery, databases, storage, backup, or critical operational services.

·        Incomplete process ancestry, unreliable effective-user fields, limited audit coverage, stale vulnerability history, weak workload mapping, short telemetry retention, or fragmented cloud and CI/CD records can force broader investigation.

·        Response burden increases because teams may need to isolate and rebuild hosts, rotate credentials and tokens, review cloud and Kubernetes activity, validate CI/CD and repository access, restore security controls, and prove that downstream trust was not abused.

S20 — Tactics, Techniques, and Procedures

Figure 3

Constrained Linux Execution

Adversaries may operate from application users, service accounts, web-service processes, containers, CI runners, developer systems, workloads, compromised credentials, web shells, or other limited Linux contexts. Observable behavior may include shell or interpreter execution, application-service child processes, unfamiliar local binaries, commands from writable or transient paths, container-originated activity, CI workspace execution, or activity inconsistent with the user, workload role, maintenance window, or approved administrative workflow. This behavior becomes risk-relevant when it aligns with exploit staging, privileged-mechanism interaction, abnormal root transition, or subsequent root-level activity.

Local Privilege Escalation

Adversaries may create, compile, modify, execute, or rapidly delete scripts, source files, ELF binaries, exploit helpers, or unfamiliar executables before interacting with a vulnerable kernel path, package flaw, privileged mechanism, authentication boundary, namespace, filesystem condition, race condition, synchronization behavior, or comparable local trust failure. This behavior becomes high priority when temporary or writable-path activity is followed by unusual privileged-binary interaction, repeated failed-to-success execution, kernel instability, abnormal effective-user transition, or root-owned process creation outside an approved workflow.

Credential and Trust-Material Access

Following successful root-level execution, adversaries may access SSH material, service credentials, application secrets, cloud credentials, workload identities, Kubernetes service account tokens, host-mounted secrets, CI/CD credentials, repository credentials, package-registry credentials, deployment secrets, or signing material. This behavior becomes materially significant when protected credential or secret access follows suspicious privilege transition and cannot be explained by approved backup, monitoring, secret rotation, configuration management, deployment, security operations, or incident-response activity.

Security-Control Degradation

Adversaries may stop, disable, modify, or interfere with endpoint protection, Linux audit, logging, telemetry forwarding, cloud agents, vulnerability scanners, container-security controls, workload-protection services, or related defensive mechanisms. This behavior becomes high priority when a confirmed state change follows suspicious root execution, affects protected agents or services, reduces visibility, or cannot be tied to approved maintenance, troubleshooting, package activity, deployment, or security operations.

Scheduled Root-Level Persistence

Adversaries may create or modify root-level cron jobs to preserve recurring privileged execution after the original exploit process ends. This behavior becomes materially significant when cron entries use unfamiliar scripts, temporary paths, user-controlled locations, encoded commands, remote communication, credential-access behavior, or execution patterns inconsistent with approved administration, backup, monitoring, patching, or orchestration.

Downstream Trust Expansion

Adversaries may use valid user, service, workload, cloud, Kubernetes, CI/CD, repository, or deployment accounts and associated credentials exposed through the compromised Linux system to access connected hosts, cloud services, Kubernetes resources, repositories, package registries, deployment systems, databases, storage systems, backup platforms, or production infrastructure. This behavior becomes high risk when new account use, remote authentication, cloud API activity, Kubernetes API access, repository activity, deployment changes, storage access, or east-west communication follows suspicious Linux root activity.

Operational Blending With Linux Administration and Automation

Adversaries may blend malicious behavior into legitimate sudo use, package management, configuration management, orchestration, vulnerability validation, CI/CD activity, build operations, backup activity, troubleshooting, maintenance, red-team work, or incident-response cleanup. This blending is effective because Linux environments routinely generate shell execution, root-owned processes, package changes, scheduled tasks, service modifications, credential access, privileged-interface interaction, and automation activity. Detection and response require correlation across user identity, effective identity, process ancestry, executable path, working directory, file activity, workload role, administrative context, and bounded time windows rather than reliance on one artifact.

Post-Remediation Access and Trust Validation Failure

Adversaries may retain access through root-level cron execution, exposed credentials, workload identities, valid downstream accounts, modified security controls, or abused workload interfaces after patching, workload replacement, process termination, or initial containment. This behavior becomes high priority when suspicious root activity, identity use, security-control degradation, remote authentication, cloud activity, Kubernetes activity, CI/CD activity, repository access, or internal expansion continues after remediation and cannot be tied to approved recovery or validation work.

S20A — Adversary Tradecraft Summary

Linux foothold-to-root privilege escalation and cloud workload trust compromise target the trust relationship between constrained Linux execution, privilege boundaries, root-level control, credentials, workload identities, privileged workload interfaces, security controls, scheduled persistence, and downstream infrastructure access. The adversary objective is to convert limited host or workload access into root control and possible broader trust abuse while blending into legitimate Linux administration, automation, build, deployment, and maintenance activity.

·        The core tradecraft pattern is constrained Linux execution followed by local privilege escalation and unauthorized root-level activity, with possible follow-on credential access, workload-boundary interaction, defensive-control degradation, scheduled persistence, or downstream use of exposed accounts and identities.

·        The behavior is not dependent on a single CVE, exploit name, kernel subsystem, vulnerable version, filename, hash, repository, SUID binary, syscall, proof-of-concept artifact, actor name, or static IOC.

·        Adversaries may use shells, interpreters, temporary files, compiled binaries, build tools, permission changes, privileged mechanisms, kernel or package flaws, authentication boundaries, namespaces, filesystem behaviors, race conditions, synchronization flaws, or other local trust failures.

·        The strongest operational risk occurs when root-level access affects cloud instances, Kubernetes nodes, container hosts, CI runners, build systems, privileged automation, identity-adjacent systems, repositories, signing infrastructure, production databases, storage systems, or workloads holding reusable credentials.

·        Credential and trust-material access may extend the incident beyond the affected host into cloud, Kubernetes, CI/CD, repository, deployment, signing, database, storage, backup, or production environments.

·        Privileged-interface interaction may expose container hosts, Kubernetes nodes, workload boundaries, cloud metadata services, or node-level management paths without being misclassified as credential access.

·        Security-control degradation and scheduled persistence increase uncertainty over whether containment succeeded and whether affected hosts or workloads can be safely trusted.

·        Detection requires visibility into the constrained execution that begins the chain and the privilege-transition, root-process, credential-access, privileged-interface, control-health, persistence, identity, cloud, Kubernetes, CI/CD, and network evidence that confirms or disproves broader impact.

·        Response requires treating suspected Linux privilege escalation as a host-trust, credential-exposure, workload-identity, privileged-interface, security-control, cloud, Kubernetes, CI/CD, and containment-validation incident, not only as a vulnerable-version finding or patch-management task.

·        The behavior remains durable because the adversary objective is to convert constrained Linux access into root control and possible broader trust abuse regardless of the specific vulnerability, exploit implementation, kernel subsystem, privileged mechanism, workload type, or campaign branding used.

S21 — Detection Strategy Overview

Detection Philosophy

Detect Linux foothold-to-root privilege escalation through correlated behavior across endpoint, Linux audit, process, identity, file, vulnerability, container, Kubernetes, cloud-workload, CI/CD, security-control, and network telemetry, not through CVE identifiers, exploit names, vulnerable-version status, proof-of-concept artifacts, hashes, repository names, or isolated kernel events alone. The durable detection model is constrained or low-privilege execution followed by exploit staging, abnormal privilege transition, root-level execution, privileged-resource or trust-material access, security-control degradation, persistence, workload-boundary abuse, or downstream expansion.

Primary Detection Anchors

·        Suspicious execution by a non-root user, service account, application account, workload identity, container process, CI runner, or other constrained execution context from writable, transient, user-controlled, build, workspace, mounted, or container-layer paths.

·        Rapid file creation, compilation, permission change, execution, and deletion involving scripts, ELF binaries, temporary executables, exploit helpers, interpreters, shells, build tools, or unfamiliar binaries.

·        Low-privilege execution followed by a root-owned shell, command interpreter, privileged utility, service process, or unexpected root-owned child process without an approved administrative transition.

·        Root process creation from suspicious parentage, including temporary paths, scripting engines, exposed services, application services, container workloads, CI jobs, build processes, or unfamiliar local executables.

·        Unexpected interaction with SUID-root binaries, setuid or setgid paths, privileged utilities, authentication mechanisms, namespaces, mount functions, or other elevation mechanisms before an abnormal root transition.

·        Kernel, syscall, eBPF, Linux audit, EDR, crash, or fault evidence associated with exploit-specific behavior where reliable telemetry exists, treated as supporting evidence rather than a universal requirement.

·        Root-level access to credential stores, SSH keys, service credentials, application secrets, cloud metadata paths, workload identity material, Kubernetes service account tokens, kubelet resources, container runtime sockets, host-mounted secrets, or CI/CD credentials after suspicious low-privilege activity.

·        Root-level discovery, credential access, defense evasion, persistence, remote access, tunneling, service manipulation, lateral-movement preparation, or destructive activity shortly after abnormal privilege transition.

·        Security-agent, audit, logging, cloud-agent, vulnerability-scanner, container-security, or workload-protection degradation following suspected escalation.

·        Container-originated or pod-originated activity followed by unexpected host-level root execution, namespace interaction, runtime-socket access, kubelet-resource access, host-mounted secret access, or node-level process activity.

·        Suspicious root-level activity on cloud Linux instances, Kubernetes worker nodes, container hosts, CI runners, build infrastructure, internet-facing workloads, privileged automation systems, or production-critical Linux servers.

·        Cloud, Kubernetes, repository, package-registry, deployment, identity, or infrastructure-management activity involving credentials or trust material exposed from a suspected root-compromised Linux system.

·        Multiple Linux systems showing similar staging, privilege-transition, root-activity, credential-access, security-control, or expansion behavior within a bounded time window.

Detection Prioritization Model

Prioritize activity where suspicious low-privilege execution is followed within a bounded time window by abnormal root-owned process creation, privileged binary interaction, sensitive-resource access, security-control degradation, persistence, workload-boundary interaction, credential use, or broader infrastructure expansion. Treat vulnerable-state findings, public proof-of-concept availability, exploit-artifact discovery, unusual SUID execution, isolated writable-path execution, or direct kernel evidence as exposure, supporting, or exploit-attempt inputs unless joined to a credible privilege-transition or post-root behavior sequence.

Correlation Strategy (Strict Enforcement)

Do not promote a single writable-path execution event, vulnerable-state finding, CVE match, proof-of-concept artifact, SUID invocation, root process, kernel event, container alert, cloud event, or sensitive-file access event to high-confidence compromise without correlation by host, asset identifier, cloud instance, Kubernetes node, container, pod, namespace, service account, process lineage, source user, effective user, executable path, working directory, command line, file object, workload role, administrative workflow, maintenance window, or bounded time window. High-confidence detection requires a sequence connecting constrained or low-privilege execution to abnormal privilege transition, root-level execution, privileged-resource access, trust-material exposure, defensive-control modification, persistence, workload-boundary abuse, or downstream expansion.

Telemetry Prioritization

Prioritize Linux endpoint process telemetry, Linux audit telemetry, process ancestry, source-user and effective-user context, executable path, working directory, command line, file activity, privileged-binary execution, authentication and privilege-transition records, security-agent health, vulnerable-state inventory, host-role data, cloud workload inventory, Kubernetes audit and node context, container runtime telemetry, CI/CD execution records, cloud identity activity, metadata-service access, DNS, proxy, firewall, NDR, network-flow, sensitive-resource access, and downstream infrastructure activity. Process lineage, user-transition context, host identity, workload role, container-to-host mapping, pod-to-node mapping, vulnerable-state context, and timestamp precision are mandatory for strong privilege-escalation correlation.

Detection Design Constraints

Avoid detection designs based only on CVE identifiers, KEV status, exploit nicknames, public proof-of-concept repositories, filenames, hashes, source IP addresses, static strings, kernel versions, package versions, isolated syscalls, one SUID binary, generic root-process creation, or vulnerable-asset status. Detection must remain useful across Linux local privilege-escalation variants that differ in kernel subsystem, race condition, memory-corruption mechanism, filesystem behavior, synchronization behavior, namespace interaction, exploit language, compilation method, staging path, privileged binary, container context, workload type, and post-exploitation sequence.

Baseline and Deployment Requirements

Baseline approved Linux administrators, sudo and privilege-management workflows, package managers, configuration-management systems, orchestration tools, backup agents, monitoring agents, security tools, vulnerability scanners, patch-validation activity, maintenance windows, CI/CD build behavior, container runtime activity, Kubernetes administrative operations, node-management workflows, cloud-init activity, automated image pipelines, incident-response tooling, and approved root-level service behavior. Validate host identity, process ancestry, real-user and effective-user fields, workload ownership, vulnerable-state enrichment, container-to-host mapping, pod-to-node mapping, cloud-instance mapping, CI runner classification, asset criticality, internet exposure, and approved administrative transitions before promoting correlation logic to alert mode.

Variant Resilience Requirements

Rules should remain effective for future Linux kernel, local privilege-escalation, namespace, container-host, authentication-boundary, SUID, filesystem, memory-corruption, race-condition, or synchronization-abuse paths that produce the same operational sequence: constrained execution, exploit staging, abnormal privilege transition, root-owned process creation, privileged-resource access, credential or trust-material exposure, security-control degradation, persistence, workload-boundary interaction, or infrastructure expansion.

Operational Detection Model

Run detections in hunt mode first, validate Linux endpoint and audit parsing, confirm process ancestry and user-transition fidelity, test writable-path normalization, validate root-process attribution, confirm vulnerable-state and host-role enrichment, tune approved administrative and automation workflows, verify container-to-host and pod-to-node mapping, test sensitive-path visibility, validate security-agent health events, and then promote to alert mode. Use escalating confidence: suspicious low-privilege execution, suspicious staging plus high-risk host context, staging plus privileged-binary interaction, abnormal privilege transition, privilege transition plus root-owned process activity, root activity plus sensitive-resource access, and root activity plus defensive-control modification, persistence, credential use, workload-boundary abuse, or downstream expansion.

Explicit Non-Deployment Guardrails

Do not deploy weak CVE-name, proof-of-concept-name, filename, hash, kernel-version, or vulnerable-state rules as compromise detection. Do not claim successful privilege escalation from writable-path execution, compilation activity, SUID execution, public exploit availability, KEV status, isolated root-process creation, generic sensitive-file access, container activity, cloud activity, or network activity alone. Do not attribute credential use, security-control degradation, persistence, Kubernetes activity, container-host interaction, cloud-control-plane behavior, CI/CD access, or lateral movement to Linux privilege escalation without host, process, user, workload, resource, identity, destination, or time-window linkage.

S22 — Primary Detection Signals

Figure 4

Primary Detection Signals

·        Low-privilege execution of shells, scripting engines, build tools, compiled ELF binaries, short-lived executables, or unfamiliar local binaries from writable, transient, user-controlled, workspace, mounted, or container-layer paths.

·        Rapid creation, compilation, permission change, execution, and deletion of scripts or binaries by non-root users, service accounts, application accounts, workload identities, container processes, or CI runners.

·        Root-owned shell, command interpreter, privileged utility, or service process created from a suspicious non-root parent chain without an approved sudo, privilege-management, package-management, orchestration, or administrative workflow.

·        Abnormal effective-user or UID transition from constrained execution to root-level process activity.

·        Unexpected interaction with SUID-root binaries, setuid or setgid files, privileged authentication utilities, namespace controls, mount functions, or elevation mechanisms shortly before root process creation.

·        Root-level access to credential stores, SSH material, service secrets, workload identity material, Kubernetes tokens, kubelet paths, container runtime sockets, host-mounted secrets, cloud metadata services, or CI/CD credentials after suspicious staging or privilege transition.

·        Root-level discovery, persistence, security-control tampering, remote access, tunneling, credential use, or lateral-movement preparation following suspicious low-privilege execution.

·        Security-agent, audit, logging, vulnerability-scanner, cloud-agent, container-security, or workload-protection degradation following an abnormal privilege transition.

·        Container-originated or pod-originated activity followed by unexpected host-level root execution, namespace entry, runtime-socket interaction, kubelet access, or host-mounted resource access.

·        Suspicious privilege transition or root-level activity on cloud Linux instances, Kubernetes nodes, container hosts, CI runners, build systems, internet-facing workloads, or production-critical Linux servers.

·        Cloud, Kubernetes, repository, package-registry, deployment, identity, or infrastructure-management activity using trust material exposed from a suspected root-compromised Linux system.

Supporting Detection Signals

·        Vulnerable Linux kernel, package, image, or workload state on a host showing suspicious local execution or privilege behavior.

·        Execution from /tmp, /var/tmp, /dev/shm, user home directories, CI workspaces, build paths, runner directories, mounted volumes, or container writable layers.

·        Use of bash, sh, dash, zsh, python, python3, perl, ruby, gcc, cc, make, or similar interpreters and build tools from unusual paths or user contexts.

·        Short-lived scripts, ELF binaries, archives, downloaded source code, compiled objects, exploit helpers, or unfamiliar executable files.

·        Unusual SUID or privileged utility execution by application users, web-service users, CI accounts, container workloads, service accounts, or non-administrative users.

·        Kernel, syscall, eBPF, audit, crash, fault, or EDR evidence involving unusual local privilege-escalation behavior where available.

·        Root process execution from temporary paths, unfamiliar binaries, scripts, interpreters, exposed services, container processes, CI jobs, or application-service parents.

·        Sensitive file, token, socket, secret, metadata, or configuration access shortly after suspicious local execution.

·        Administrative activity inconsistent with the user, process lineage, host role, workload role, maintenance window, or approved change record.

·        DNS, proxy, firewall, NDR, or cloud-control-plane activity following suspected root escalation.

·        SIEM, ITSM, vulnerability-management, orchestration, and asset-inventory records confirming that no approved maintenance, vulnerability validation, deployment, or administrative activity occurred during the suspicious window.

Exploit Attempt and Instability Signals

·        Repeated staging, execution, compilation, or testing of local binaries or scripts by non-root users on vulnerable or high-value Linux systems.

·        Rapid failed-to-success execution patterns involving temporary binaries, privileged utilities, shells, authentication mechanisms, or root-process creation.

·        Kernel warnings, crashes, faults, hangs, watchdog events, process termination, service instability, or host restart behavior near suspicious local execution.

·        Unusual syscall, eBPF, audit, EDR-kernel, namespace, filesystem, synchronization, or privilege-transition events where reliable telemetry exists.

·        Multiple short-lived exploit attempts that create, execute, fail, change permissions, or disappear within a narrow time window.

·        Proof-of-concept-like filenames, strings, repositories, commands, source-code fragments, or compiled artifacts treated only as exploit-attempt evidence when locally observable and correlated with execution.

·        Unexpected root-owned process creation immediately after exploit staging, privileged-binary interaction, kernel instability, or unusual authentication behavior.

·        Repeated exploitation-like activity across multiple Linux systems, workloads, containers, Kubernetes nodes, or CI runners within a bounded time window.

Outbound Communication Signals

·        DNS, HTTP, HTTPS, SSH, SMTP, raw-IP, file-transfer, tunneling, paste-site, repository, package-registry, or command-and-control-like communication initiated by a newly created or suspicious root process.

·        Outbound communication from Linux systems immediately following abnormal privilege transition, credential access, secret access, persistence setup, or security-control degradation.

·        Connections from root-owned shells, interpreters, temporary binaries, unfamiliar executables, application-service processes, container-originated processes, or CI jobs to rare, newly seen, suspicious, unknown, unapproved, or geographically unusual destinations.

·        Access to cloud metadata services, workload identity endpoints, managed identity services, token endpoints, repository services, package registries, deployment systems, or infrastructure-management APIs after suspected escalation.

·        Repeated callbacks or beacon-like communication from Linux workloads after suspicious staging or root-process creation.

·        Network activity inconsistent with approved updates, package retrieval, telemetry, monitoring, vulnerability scanning, backup, configuration management, orchestration, build, or deployment behavior.

·        Unexpected communication from compromised Linux systems to internal identity, backup, repository, database, storage, orchestration, monitoring, or management services.

Persistence and Post-Exploitation Signals (Conditional)

·        Creation or modification of cron jobs, systemd units, init scripts, shell profiles, SSH authorized keys, privileged services, startup scripts, kernel-module configuration, or authentication settings after suspected privilege escalation.

·        New users, group-membership changes, sudoers modifications, SSH-key changes, service-account changes, authentication-policy changes, or privileged access grants.

·        Security-agent stopping, audit-policy modification, log deletion, telemetry-forwarding disruption, cloud-agent tampering, vulnerability-scanner interference, or container-security degradation.

·        Access to /etc/shadow, /etc/sudoers, /root/.ssh, service credentials, application secrets, cloud credentials, Kubernetes tokens, kubelet material, runtime sockets, host-mounted secrets, CI/CD secrets, repository credentials, or signing material.

·        Root-level discovery of users, groups, processes, network interfaces, mounts, containers, Kubernetes resources, cloud metadata, repositories, build systems, or production services.

·        Creation of archives, compressed files, credential collections, diagnostic bundles, staged transfer files, or hidden temporary artifacts.

·        Service stops, workload disruption, data destruction, encryption, destructive commands, or operational degradation following root-level compromise.

·        Log clearing, timestamp manipulation, artifact deletion, process termination, or system reboot behavior intended to reduce forensic visibility.

Lateral Movement and Expansion Signals (Conditional)

·        Use of SSH keys, service credentials, cloud roles, workload identities, Kubernetes tokens, CI/CD credentials, repository tokens, package-registry credentials, or deployment secrets obtained from a suspected root-compromised Linux system.

·        SSH, remote service, cloud API, Kubernetes API, repository, package-registry, backup, database, storage, or management-platform access after suspected privilege escalation.

·        Container runtime socket use, host namespace entry, kubelet interaction, service account token use, hostPath access, or node-resource access following suspicious root transition.

·        Role assumption, managed identity use, secret retrieval, snapshot access, storage access, security-control changes, or unusual cloud API activity following suspected host compromise.

·        Expansion from CI runners, build systems, developer infrastructure, or automation hosts into repositories, artifact platforms, deployment systems, cloud accounts, or production environments.

·        Similar privilege-transition, root-activity, credential-use, or expansion patterns across multiple Linux systems, cloud accounts, clusters, namespaces, containers, or CI/CD environments.

·        Downstream authentication, service-account, workload-identity, repository, deployment, or infrastructure-management anomalies temporally aligned with suspicious Linux host activity.

Signal Usage Constraints

Do not treat any single signal as compromise confirmation. Promote confidence only when signals align by host, asset identifier, cloud instance, Kubernetes node, container, pod, namespace, service account, process lineage, source user, effective user, executable path, working directory, file object, vulnerable state, workload role, destination, maintenance window, or bounded time window. Treat KEV status, public proof-of-concept availability, vulnerable-version status, exploit-artifact discovery, and direct kernel evidence as urgency or supporting inputs, not standalone proof of successful privilege escalation.

S23 — Telemetry Requirements

Endpoint and Process Execution Telemetry

·        Linux EDR, Linux audit, Sysmon for Linux, osquery, eBPF, workload-security, container-security, or equivalent host telemetry.

·        Parent process, child process, process user, real user, effective user, UID, effective UID, command line, current directory, executable path, hash where available, timestamp, hostname, asset identifier, cloud instance identifier, container identifier, pod, namespace, node, service account, and workload owner.

·        Process ancestry linking low-privilege execution, exploit staging, privileged-binary interaction, abnormal user transition, root-owned process creation, sensitive-resource access, persistence, security-control modification, and outbound activity.

·        Detection of shell, scripting, compilation, transfer, archive, encoding, discovery, credential-access, persistence, network, authentication, namespace, mount, and privilege-management tooling executed from suspicious Linux contexts.

·        Host grouping for internet-facing Linux workloads, cloud instances, Kubernetes worker nodes, container hosts, CI runners, build systems, developer infrastructure, identity-adjacent systems, production servers, and high-value operational systems.

·        Approved administrator, approved sudo, approved package-manager, approved configuration-management, approved orchestration, approved CI/CD, approved backup, approved vulnerability-validation, approved incident-response, and approved maintenance exceptions.

Memory and Execution Telemetry

·        EDR-kernel, eBPF, syscall, audit, kernel-log, crash, fault, or forensic telemetry capable of identifying unusual privilege-transition behavior where available.

·        Process memory, execution, syscall, namespace, authentication, privileged-binary, kernel-interface, filesystem, synchronization, or race-condition evidence where available and reliable.

·        Runtime execution evidence linking staging processes to abnormal root-owned children or privileged resources.

·        Interpreter invocation, compiled payload execution, in-memory execution, child-process spawning, unusual argument handling, or unexpected service-context execution.

·        Container-originated process lineage linked to host-level execution where the collection platform supports it.

·        Memory and direct kernel-behavior telemetry are conditional enrichment and should not be treated as minimum requirements.

·        Runtime process and privilege-transition telemetry are strongly recommended and should carry greater operational weight than exploit-specific artifacts.

Crash and Fault Telemetry

·        Linux kernel logs.

·        Audit logs.

·        EDR fault and process-termination events.

·        Systemd journal records.

·        Application and service crash logs.

·        Container runtime logs.

·        Kubernetes node-health and workload-failure records.

·        Kernel warnings, oops events, panics, hangs, watchdog events, resource-exhaustion events, segmentation faults, abnormal process termination, and unexplained system restarts near suspicious local execution.

·        Authentication, PAM, sudo, privilege-management, and failed-to-success transition records.

·        Cloud, orchestration, monitoring, and workload-health alerts that identify instability on high-value Linux systems.

·        Authorized vulnerability validation, stress testing, maintenance, driver changes, kernel updates, and incident-response activity must be available for tuning.

File and Persistence Telemetry

·        File creation, modification, rename, write, read, execution, deletion, permission, ownership, setuid, setgid, timestamp, archive, download, and temporary-file telemetry.

·        Coverage for /tmp, /var/tmp, /dev/shm, user home directories, CI workspaces, build directories, runner paths, mounted volumes, container writable layers, shell profiles, cron paths, systemd paths, SSH directories, privileged configuration paths, and security-tool directories.

·        Detection of unexpected ELF binaries, scripts, source code, compiled objects, archives, command-output files, exploit helpers, hidden files, encoded files, compressed collections, and temporary executables.

·        Coverage for /etc/shadow, /etc/sudoers, /etc/passwd, /etc/group, /root/.ssh, service credentials, application secrets, cloud credentials, Kubernetes service account tokens, kubelet paths, runtime sockets, host-mounted secrets, CI/CD secrets, repository credentials, and signing material.

·        Known-good host, image, container-host, Kubernetes-node, CI-runner, and production-server baselines.

·        Persistence-change records for cron, systemd, startup scripts, shell profiles, SSH keys, users, groups, sudoers, services, authentication policy, security tools, audit settings, and telemetry forwarding.

·        Package-manager, configuration-management, orchestration, deployment, image-build, patch, backup, and administrative change records.

Network and Outbound Communication Telemetry

·        DNS logs.

·        Proxy logs.

·        Firewall logs.

·        NDR metadata.

·        EDR network telemetry.

·        NetFlow, VPC flow, cloud network flow, data-center flow, or equivalent network telemetry.

·        Container runtime and Kubernetes network telemetry where available.

·        Destination domain, destination IP, destination port, protocol, process context where available, source host, source container, source pod, source namespace, source account, timestamp, action, and reputation enrichment.

·        Recently seen and newly registered domain enrichment.

·        Destination country and ASN enrichment where available.

·        Approved update, repository, package-registry, telemetry, monitoring, backup, vulnerability-management, orchestration, cloud-service, build, deployment, and vendor destinations.

·        Internal identity, repository, package-registry, database, storage, backup, orchestration, monitoring, and management-service destination mapping.

·        Cloud metadata, workload identity, managed identity, Kubernetes API, repository, CI/CD, and infrastructure-management access records.

Web and Application Telemetry (Conditional Availability)

·        Web server, application server, reverse proxy, API gateway, WAF, container platform, Kubernetes ingress, service-mesh, and workload logs that identify the prerequisite local-execution path.

·        HTTP method, URI path, query string, source IP, forwarded source IP, user agent, status code, response size, request size, timestamp, application identity, service account, container, pod, namespace, node, and backend host where available.

·        Web-shell, command-execution, template-injection, deserialization, file-upload, application-account, or exposed-service activity preceding suspected local privilege escalation.

·        Application process lineage linking exposed services, service accounts, or workload identities to suspicious local execution.

·        CI/CD job records, build logs, runner logs, pipeline identities, repository events, artifact events, deployment events, and workspace activity where applicable.

·        Cloud workload, instance, image, container-host, Kubernetes-node, CI-runner, and application ownership inventory.

·        Vulnerability and patch inventory for Linux kernels, packages, images, node pools, autoscaling groups, and ephemeral workload templates.

·        Web and application telemetry should establish foothold context but should not be treated as direct proof of the local privilege-escalation mechanism.

Telemetry Availability Requirements

·        Minimum viable coverage requires Linux process telemetry with command line, executable path, process ancestry, user and effective-user context, host identity, host role, and vulnerable-state enrichment.

·        Strong coverage requires process and audit telemetry joined to privileged-binary activity, sensitive-file access, security-agent health, container-to-host mapping, Kubernetes node context, cloud workload context, CI/CD context, and network activity.

·        Highest confidence requires correlation across suspicious low-privilege execution, exploit staging, abnormal privilege transition, root-owned process creation, sensitive-resource access, security-control degradation, persistence, credential use, workload-boundary interaction, and downstream expansion.

·        Environments without direct kernel, memory, syscall, or eBPF visibility require compensating evidence from process ancestry, effective-user transitions, file activity, sensitive-resource access, container and Kubernetes context, cloud identity activity, security-control health, and post-root behavior.

·        Ephemeral, autoscaled, containerized, cloud-hosted, or managed environments require historical vulnerable-state data, image lineage, workload ownership, node mapping, identity mapping, and sufficient telemetry retention to reconstruct the exposure window.

·        Network, cloud-control-plane, vulnerability, or static-artifact telemetry alone is not sufficient.

Telemetry Limitations and Gaps

·        Linux process command lines may be truncated, redacted, or unavailable.

·        Parent process and effective-user fields may not be preserved consistently.

·        Audit policies may exclude temporary directories, container paths, CI workspaces, sensitive files, or privileged execution.

·        Direct kernel, syscall, synchronization, namespace, memory-corruption, or race-condition telemetry may be unavailable.

·        EDR coverage may be incomplete on Kubernetes nodes, container hosts, appliances, hardened systems, ephemeral workloads, or specialized Linux distributions.

·        Container telemetry may not map reliably to host-level processes.

·        Kubernetes logs may not preserve node, pod, namespace, service account, and host-process relationships in one view.

·        Cloud logs cannot directly prove local Linux privilege escalation.

·        Vulnerability scanners may report stale kernel, package, image, or reboot state.

·        Live-patch, backport, custom-kernel, and distribution-specific package states may complicate vulnerable-state assessment.

·        Sensitive-file access may not be captured at sufficient fidelity.

·        Root process creation may overlap with legitimate administration, automation, orchestration, package management, CI/CD, and maintenance activity.

·        File timestamps may be altered by image creation, deployment, container layering, backup restoration, incident response, or attacker cleanup.

·        Short telemetry retention may prevent retrospective reconstruction.

·        Exploit-specific artifacts may be renamed, recompiled, embedded, encrypted, deleted, or never written to disk.

S24 — Detection Opportunities and Gaps

Detection Opportunities

·        Suspicious low-privilege execution can be correlated with exploit staging, abnormal effective-user transition, root-owned process creation, privileged-binary interaction, sensitive-resource access, security-control degradation, persistence, and outbound activity.

·        Linux process ancestry and user-transition telemetry can reveal the durable foothold-to-root sequence without requiring direct observation of the underlying exploit primitive.

·        Writable-path execution, rapid compilation, temporary-binary activity, and short-lived file behavior can identify local exploit preparation.

·        SUID-root, setuid, setgid, authentication, namespace, mount, and privileged utility activity can provide supporting context when joined to abnormal parentage and root transition.

·        Kernel logs, audit telemetry, eBPF, syscall visibility, EDR-kernel events, crash records, and forensic artifacts may provide exploit-specific confidence where available.

·        Vulnerability and patch inventory can prioritize Linux workloads where suspicious behavior occurred during a confirmed vulnerable period.

·        File-access telemetry can identify post-root access to credentials, SSH material, service secrets, cloud identity material, Kubernetes tokens, runtime sockets, host-mounted secrets, and CI/CD credentials.

·        Security-agent and audit-health telemetry can identify defensive-control degradation following suspected escalation.

·        Container runtime and Kubernetes telemetry can identify container-originated activity that crosses into host-level root execution, node resources, namespaces, runtime sockets, kubelet paths, or host-mounted secrets.

·        Cloud workload and identity telemetry can identify metadata access, managed identity use, role activity, secret retrieval, storage access, snapshot access, or security-control changes after suspected host compromise.

·        CI/CD, repository, package-registry, build, and deployment telemetry can identify downstream use of credentials or trust exposed from compromised Linux systems.

·        Network telemetry can identify callbacks, tool retrieval, tunneling, lateral movement, repository access, package-registry access, cloud API use, or internal service access from suspicious root processes.

·        Multi-host and multi-workload correlation can identify repeated exploitation patterns across Linux servers, cloud instances, Kubernetes nodes, container hosts, CI runners, and production workloads.

·        Known-good baselines, ITSM records, orchestration records, patch records, and administrative-change records can separate approved root activity from suspicious privilege escalation.

·        The behavior model can support multiple Linux privilege-escalation CVEs without depending on one kernel subsystem, exploit name, or proof-of-concept implementation.

Detection Gaps

·        Direct observation of the exploit primitive may be impossible without specialized syscall, eBPF, kernel, memory, audit, or forensic telemetry.

·        Privilege-transition fields may be missing, inconsistent, or normalized incorrectly.

·        Parent-child relationships may be incomplete across shells, service managers, containers, namespaces, or short-lived processes.

·        Root-owned process creation may not identify the original low-privilege source when process ancestry is lost.

·        Writable-path execution can be common on CI runners, build systems, developer hosts, container workloads, and automation systems.

·        Legitimate administration, patching, package installation, vulnerability validation, troubleshooting, orchestration, backup, and incident-response activity may resemble portions of the attack sequence.

·        Vulnerable-state inventory may be stale or inaccurate because of live patching, backports, custom kernels, reboot requirements, ephemeral images, autoscaling, or disconnected scanning.

·        Kernel crashes, service faults, and restarts may have benign operational causes.

·        Sensitive-file access may not be captured or may overlap with backup, monitoring, security, or configuration-management activity.

·        Container-to-host and pod-to-node mappings may be incomplete.

·        Kubernetes audit records may identify API activity without proving the originating host-level compromise.

·        Cloud-control-plane and identity telemetry cannot prove the local privilege-escalation mechanism.

·        CI/CD and repository activity may be separated from endpoint telemetry by different identities, systems, or retention periods.

·        Exploit artifacts can be renamed, minimized, encrypted, embedded, compiled in memory, or removed immediately after use.

·        Attackers may operate entirely through existing tools, interpreters, administrative utilities, or trusted binaries.

·        Security-agent tampering may create telemetry gaps precisely when confirmation is most important.

·        Ephemeral hosts, containers, nodes, and runners may be terminated or rebuilt before forensic collection.

·        Network telemetry may not attribute outbound communication to a specific process, container, pod, user, or privilege transition.

·        Post-root behavior can result from other local privilege-escalation methods and is not unique to one CVE family.

Compensating Controls

·        Preserve Linux EDR, audit, kernel, journal, vulnerability, container, Kubernetes, cloud, CI/CD, identity, DNS, proxy, firewall, and network-flow telemetry before rotation or workload replacement.

·        Validate process ancestry, real-user, effective-user, UID, executable-path, working-directory, command-line, file-path, container, pod, namespace, node, and host fields before production deployment.

·        Correlate vulnerable-state history with suspicious behavior at the time it occurred rather than relying only on current patch status.

·        Map containers and pods to underlying hosts and Kubernetes nodes.

·        Map cloud instances, Kubernetes nodes, container hosts, CI runners, build systems, and production workloads to owners, business criticality, internet exposure, identities, and trust relationships.

·        Baseline approved sudo, privilege-management, package-management, configuration-management, orchestration, CI/CD, backup, vulnerability-validation, maintenance, and incident-response activity.

·        Monitor execution from writable, transient, build, workspace, mounted, and container-layer paths.

·        Monitor abnormal root-process creation from suspicious low-privilege parentage.

·        Monitor sensitive credentials, SSH material, cloud identity paths, Kubernetes tokens, kubelet resources, runtime sockets, host-mounted secrets, CI/CD credentials, repository credentials, and signing material.

·        Monitor EDR, audit, cloud-agent, vulnerability-scanner, container-security, logging, and telemetry-forwarding health.

·        Restrict container runtime sockets, hostPath mounts, privileged containers, host namespaces, kubelet access, metadata-service access, and unnecessary workload identities.

·        Reduce standing cloud, Kubernetes, CI/CD, repository, package-registry, and deployment privileges available from Linux workloads.

·        Rotate credentials, tokens, keys, service accounts, workload identities, and deployment secrets when root compromise cannot be ruled out.

·        Rebuild or replace high-risk cloud instances, Kubernetes nodes, container hosts, CI runners, and production workloads when forensic confidence is insufficient.

·        Use public proof-of-concept availability, KEV status, vulnerability exposure, and exploit reporting as prioritization inputs, not standalone proof of compromise.

Non-Coverage Conditions

·        Activity limited to vulnerable-kernel, package, image, or CVE status without suspicious local execution, privilege transition, root activity, sensitive-resource access, security-control degradation, persistence, or expansion evidence.

·        Proof-of-concept files, strings, hashes, repository references, or exploit nicknames without execution or behavior linkage.

·        Generic writable-path execution with no suspicious user, process, host-role, vulnerable-state, privilege-transition, or post-root context.

·        Ordinary sudo, package-management, service-management, orchestration, configuration-management, backup, patching, build, deployment, or maintenance activity that matches approved workflows.

·        Generic root-process activity with no abnormal parentage, low-privilege origin, suspicious timing, resource access, or post-exploitation behavior.

·        Isolated SUID, setuid, setgid, authentication, namespace, mount, kernel, crash, or syscall activity without a broader escalation sequence.

·        Cloud-only, identity-only, Kubernetes-only, container-only, CI/CD-only, network-only, sensitive-file-only, or vulnerability-only anomalies without Linux host, process, user, workload, privilege-transition, resource, or time-window correlation.

·        Container escape, Kubernetes compromise, cloud compromise, repository compromise, CI/CD compromise, or lateral movement where no Linux foothold-to-root behavior is present.

·        Remote Linux exploitation that does not involve subsequent local privilege escalation.

·        Generic post-root activity where the initial privilege-transition path cannot be tied to the Linux foothold-to-root behavior family.

·        Approved vulnerability testing, penetration testing, incident response, forensic collection, red-team activity, or exploit validation performed within authorized scope.

S25 Ultra-Tuned Detection Engineering Rules

NDR / Network Behavioral Analytics

Detection Viability Assessment

NDR and Network Behavioral Analytics platforms can provide viable behavior-driven coverage for Linux foothold-to-root activity when they support canonical workload identity resolution, Linux asset grouping, role-aware baselining, destination enrichment, east-west visibility, cloud and Kubernetes mapping, approved-service exceptions, and bounded-time behavioral correlation.

NDR cannot directly observe the local privilege-transition mechanism or independently prove that root access was obtained. Its viable role is to detect durable network behavior associated with post-foothold execution, trust-material exposure, command-and-control, cloud or workload-identity abuse, and internal expansion.

Three rules survive validation:

·        Rare or anomalous outbound communication from high-risk Linux workloads.

·        Cloud metadata or workload-identity access followed by anomalous network or cloud-service activity.

·        Abnormal east-west expansion from Linux workloads into trust-sensitive infrastructure.

Each rule remains independently evaluable. Supporting endpoint, identity, cloud, container, Kubernetes, CI/CD, or vulnerability context may increase confidence but is not required for the core NDR behavior to alert. No rule depends on another CyberDax rule firing first.

Rule

Rare Outbound Communication From High-Risk Linux Workloads

Rule Format

NDR or Network Behavioral Analytics anomaly and correlation pattern using canonical Linux workload identity resolution, asset grouping, workload-role classification, expected-egress baselining, destination enrichment, approved-destination exceptions, connection-cadence analysis, and optional supporting-context enrichment.

Detection Purpose

Detect rare, newly observed, suspicious, or role-inconsistent outbound communication from Linux servers, cloud workloads, Kubernetes nodes, container hosts, CI runners, build systems, privileged automation hosts, and production workloads.

The rule identifies communication consistent with tool retrieval, callback activity, tunneling, command-and-control, unusual repository or package-registry access, or other post-compromise network behavior without claiming that NDR directly observed successful privilege escalation.

Detection Logic

·        Resolve host, asset, cloud-instance, Kubernetes-node, container-host, CI-runner, workload-identity, and source-host identifiers through a canonical asset crosswalk before filtering or correlation.

·        Group monitored Linux workloads by role, environment, cloud account, Kubernetes cluster, container-host function, CI/CD role, business criticality, and expected egress profile.

·        Identify outbound communication to rare, first-seen, newly registered, suspicious, malicious, unknown, or role-inconsistent destinations.

·        Prioritize raw-IP connections, unusual destination ports, unexpected protocols, repeated callbacks, beacon-like cadence, tunneling behavior, paste-site access, file-sharing access, tool-retrieval patterns, or unexpected repository and package-registry access.

·        Exclude approved update, package, repository, telemetry, monitoring, backup, vulnerability-management, orchestration, cloud-service, build, deployment, and vendor-support destinations.

·        Alert independently when rare-egress behavior exceeds role-aware thresholds.

·        Increase severity when the behavior aligns with unusual inbound access, suspicious SSH activity, application-compromise indicators, container anomalies, metadata access, endpoint-derived process anomalies, or a sharp deviation from the workload’s historical baseline.

·        Do not describe the alert as confirmed root compromise or local privilege escalation without corroborating host evidence.

Required Telemetry

·        NDR connection metadata.

·        DNS telemetry.

·        Proxy telemetry.

·        Firewall telemetry.

·        NetFlow, VPC Flow Logs, cloud flow logs, or equivalent network-flow telemetry.

·        Asset crosswalk data that maps host, asset, cloud-instance, Kubernetes-node, container-host, CI-runner, workload-identity, and source-host identifiers to one canonical workload identifier.

·        Asset role, business criticality, environment, and exposure classification.

·        Destination domain, IP, port, protocol, ASN, geography, reputation, domain age, and first-seen status.

·        Connection count, cadence, session duration, bytes sent, bytes received, and recurrence.

·        Approved-destination and approved-maintenance context.

·        Optional endpoint process, identity, container, Kubernetes, cloud, or application enrichment.

Engineering Implementation Instructions

·        Build and validate a canonical workload-identity crosswalk before production deployment.

·        Do not select one identifier merely because it is the first populated field.

·        Preserve all available source identifiers and resolve them to the same canonical workload record.

·        Validate source attribution before production deployment.

·        Build separate expected-egress baselines for production servers, cloud workloads, Kubernetes nodes, container hosts, CI runners, build systems, developer infrastructure, and administrative Linux systems.

·        Maintain approved destination sets for operating-system updates, package repositories, code repositories, artifact repositories, container registries, monitoring, backup, vulnerability management, cloud services, orchestration, CI/CD, security tooling, vendor support, and telemetry.

·        Use role-aware rarity and deviation thresholds rather than global fixed thresholds.

·        Require a minimum connection count, recurrence threshold, duration threshold, or rate change before classifying beacon-like or callback-like behavior.

·        Tune ephemeral workloads separately from persistent workloads.

·        Preserve canonical workload mapping across NAT, proxies, shared egress, service meshes, container overlays, Kubernetes networking, and cloud gateways.

·        Use process attribution only where validated.

·        Route events involving Kubernetes nodes, container hosts, CI runners, privileged automation hosts, internet-facing systems, and production-critical workloads at higher priority.

·        Deploy in hunt mode first and validate identity resolution, destination baselines, approved-destination exceptions, and cadence thresholds.

·        Present the alert as suspicious rare outbound behavior from a high-risk Linux workload.

DRI Assessment

The rule is behaviorally durable and remains applicable across multiple Linux privilege-escalation families because it detects post-compromise communication rather than exploit-specific artifacts. Detection strength is constrained by the fact that rare egress is not unique to privilege escalation and requires canonical source attribution, role-aware baselining, and destination enrichment.

DRI

8.5

TCR Assessment

Operational confidence depends on canonical source attribution, accurate workload-role classification, approved-egress baselines, destination enrichment, and sufficient network visibility. Full-telemetry confidence improves when the event is enriched with endpoint process activity, identity context, cloud or Kubernetes mapping, vulnerable-state history, or preceding suspicious access.

Operational TCR

8.2

Full-Telemetry TCR

8.9

Limitations

·        Rare egress can result from legitimate updates, troubleshooting, package retrieval, new application behavior, build activity, backup, telemetry, or vendor support.

·        NAT, proxies, service meshes, shared gateways, container overlays, and centralized egress can obscure the true source workload.

·        Asset-crosswalk gaps may prevent canonical attribution.

·        NDR may not identify the initiating process or user.

·        Attackers may use approved destinations, common cloud services, existing sessions, or internal infrastructure.

·        The rule does not prove successful Linux privilege escalation.

·        Environments without reliable canonical asset mapping, asset-role classification, and expected-egress baselines should not deploy the rule directly at high severity.

Detection Query Pattern

Use this pattern as an implementation guide for NDR and Network Behavioral Analytics platforms that support canonical workload identity resolution, Linux asset grouping, role-aware expected-egress baselines, destination enrichment, approved-destination context, connection-cadence analysis, optional supporting-context joins, and standalone anomaly logic.

LET HIGH_RISK_LINUX_CANONICAL_WORKLOADS =

ENV_INTERNET_FACING_LINUX_CANONICAL_IDS

OR ENV_CLOUD_LINUX_CANONICAL_IDS

OR ENV_KUBERNETES_WORKER_NODE_CANONICAL_IDS

OR ENV_CONTAINER_HOST_CANONICAL_IDS

OR ENV_CI_RUNNER_CANONICAL_IDS

OR ENV_BUILD_SYSTEM_CANONICAL_IDS

OR ENV_DEVELOPER_LINUX_CANONICAL_IDS

OR ENV_PRIVILEGED_AUTOMATION_CANONICAL_IDS

OR ENV_PRODUCTION_LINUX_CANONICAL_IDS

OR ENV_IDENTITY_ADJACENT_LINUX_CANONICAL_IDS

OR ENV_HIGH_VALUE_OPERATIONAL_LINUX_CANONICAL_IDS

LET APPROVED_LINUX_EGRESS_DESTINATIONS =

ENV_APPROVED_OS_UPDATE_DESTINATIONS

OR ENV_APPROVED_PACKAGE_REPOSITORIES

OR ENV_APPROVED_CODE_REPOSITORIES

OR ENV_APPROVED_ARTIFACT_REPOSITORIES

OR ENV_APPROVED_CONTAINER_REGISTRIES

OR ENV_APPROVED_MONITORING_DESTINATIONS

OR ENV_APPROVED_TELEMETRY_DESTINATIONS

OR ENV_APPROVED_BACKUP_DESTINATIONS

OR ENV_APPROVED_SECURITY_VENDOR_DESTINATIONS

OR ENV_APPROVED_VULNERABILITY_MANAGEMENT_DESTINATIONS

OR ENV_APPROVED_CLOUD_SERVICE_DESTINATIONS

OR ENV_APPROVED_ORCHESTRATION_DESTINATIONS

OR ENV_APPROVED_BUILD_AND_DEPLOYMENT_DESTINATIONS

OR ENV_APPROVED_VENDOR_SUPPORT_DESTINATIONS

LET APPROVED_LINUX_CONTEXT_EXCEPTIONS =

ENV_APPROVED_MAINTENANCE_WINDOWS

OR ENV_APPROVED_PATCH_WINDOWS

OR ENV_APPROVED_BUILD_WINDOWS

OR ENV_APPROVED_DEPLOYMENT_WINDOWS

OR ENV_APPROVED_BACKUP_WINDOWS

OR ENV_APPROVED_VULNERABILITY_VALIDATION_WINDOWS

OR ENV_APPROVED_INCIDENT_RESPONSE_WINDOWS

OR ENV_APPROVED_RED_TEAM_WINDOWS

OR ENV_APPROVED_VENDOR_SUPPORT_WINDOWS

LET normalized_linux_egress_events =

dns_proxy_firewall_ndr_or_flow_events

EVAL canonical_source_workload =

RESOLVE_CANONICAL_WORKLOAD_ID(

source_asset_id,

cloud_instance_id,

kubernetes_node_id,

container_host_id,

ci_runner_id,

workload_identity_id,

source_host_id,

source_ip

)

EVAL normalized_destination =

COALESCE(

destination_domain,

destination_ip,

destination_service

)

WHERE canonical_source_workload IN HIGH_RISK_LINUX_CANONICAL_WORKLOADS

AND canonical_source_workload IS NOT NULL

AND normalized_destination IS NOT NULL

AND event_time NOT IN APPROVED_LINUX_CONTEXT_EXCEPTIONS

LET suspicious_linux_outbound_behavior =

normalized_linux_egress_events

WHERE normalized_destination NOT IN APPROVED_LINUX_EGRESS_DESTINATIONS

AND (

destination_first_seen_status IN ("new", "rare")

OR destination_reputation IN ("unknown", "suspicious", "malicious")

OR destination_domain_age IN ("newly_registered", "recently_registered")

OR destination_asn IN ENV_SUSPICIOUS_OR_UNEXPECTED_ASNS

OR destination_geo NOT IN ENV_EXPECTED_DESTINATION_GEOS_BY_SOURCE_ROLE

OR destination_port IN ENV_UNUSUAL_EGRESS_PORTS_BY_SOURCE_ROLE

OR destination_protocol IN ENV_UNUSUAL_EGRESS_PROTOCOLS_BY_SOURCE_ROLE

OR destination_role NOT IN ENV_EXPECTED_DESTINATION_ROLES_BY_SOURCE_ROLE

OR network_behavior IN (

"callback_like",

"beacon_like",

"tool_retrieval_like",

"tunneling_like",

"raw_ip_connection",

"rare_external_connection",

"paste_site_access",

"file_sharing_access",

"unexpected_repository_access",

"unexpected_package_registry_access"

)

)

GROUP BY

canonical_source_workload,

normalized_destination,

destination_port,

destination_protocol

WHERE (

connection_count >= ENV_MINIMUM_RARE_EGRESS_CONNECTION_COUNT

OR recurring_session_count >= ENV_MINIMUM_RECURRING_SESSION_COUNT

OR session_duration >= ENV_MINIMUM_SUSPICIOUS_SESSION_DURATION

OR connection_rate_change >= ENV_MINIMUM_ROLE_AWARE_RATE_CHANGE

OR destination_reputation IN ("suspicious", "malicious")

)

LET supporting_linux_source_context =

network_endpoint_identity_container_kubernetes_or_application_events

EVAL canonical_context_workload =

RESOLVE_CANONICAL_WORKLOAD_ID(

source_asset_id,

cloud_instance_id,

kubernetes_node_id,

container_host_id,

ci_runner_id,

workload_identity_id,

source_host_id,

source_ip

)

EVAL supporting_context_type =

COALESCE(

inbound_behavior,

endpoint_behavior,

workload_behavior

)

WHERE canonical_context_workload IN HIGH_RISK_LINUX_CANONICAL_WORKLOADS

AND supporting_context_type IN (

"unusual_external_access",

"suspicious_ssh_access",

"application_compromise_like",

"web_shell_like",

"unexpected_remote_session",

"container_originated_anomaly",

"suspicious_writable_path_execution",

"unexpected_root_process",

"privileged_binary_anomaly",

"security_control_degradation",

"unexpected_metadata_access",

"unusual_workload_identity_use",

"container_to_host_anomaly",

"kubernetes_node_anomaly",

"ci_runner_anomaly"

)

LET enriched_suspicious_linux_outbound_behavior =

ENRICH suspicious_linux_outbound_behavior

WITH OPTIONAL supporting_linux_source_context

WHERE canonical_source_workload = canonical_context_workload

WITHIN ENV_OPTIONAL_CONTEXT_TO_RARE_EGRESS_WINDOW

OUTPUT enriched_suspicious_linux_outbound_behavior

canonical_source_workload,

source_asset_id,

source_host,

source_host_id,

source_ip,

source_asset_role,

source_business_criticality,

source_exposure_class,

cloud_account,

cloud_instance_id,

kubernetes_cluster,

kubernetes_node_id,

container_host_id,

ci_runner_id,

workload_identity_id,

supporting_context_present,

supporting_context_type,

normalized_destination,

destination_domain,

destination_ip,

destination_port,

destination_protocol,

destination_asn,

destination_geo,

destination_reputation,

destination_domain_age,

destination_first_seen_status,

network_behavior,

connection_count,

recurring_session_count,

session_duration,

connection_rate_change,

bytes_sent,

bytes_received,

first_seen,

last_seen

Rule

Cloud Metadata or Workload Identity Access Followed by Anomalous Activity

Rule Format

NDR or Network Behavioral Analytics sequence pattern using canonical workload identity resolution, cloud metadata identification, workload-identity endpoint classification, approved metadata-access baselines, destination-service classification, conditional application-layer fields, optional cloud-audit enrichment, and bounded-time same-workload correlation.

Detection Purpose

Detect Linux workloads that access cloud metadata, workload-identity, managed-identity, service-account token, or local token-broker endpoints and then initiate unusual external communication or access cloud, identity, secret-management, storage, repository, deployment, or infrastructure-management services.

The rule identifies network behavior consistent with possible trust-material exposure or use without claiming that metadata access proves credential theft, successful privilege escalation, secret retrieval, role assumption, or cloud-control-plane compromise.

Detection Logic

·        Resolve all source and workload-identity identifiers through the canonical workload crosswalk before filtering or correlation.

·        Identify Linux workloads accessing known cloud metadata, managed-identity, workload-identity, service-account token, or token-broker endpoints.

·        Exclude approved initialization, autoscaling, monitoring, backup, cloud-agent, orchestration, deployment, and workload-identity access patterns.

·        Correlate metadata or identity access with unusual external communication or access to sensitive cloud-service families.

·        Require the same canonical workload across the primary sequence.

·        Treat account, subscription, project, and region matches as enrichment only.

·        Use request path, method, user agent, and source process only when proxy, service-mesh, gateway, endpoint-enriched, or application-layer telemetry provides those fields.

·        Increase confidence when optional cloud-audit telemetry confirms secret retrieval, token access, role use, snapshot activity, storage access, or security-control changes.

·        Preserve the network sequence as a valid alert when cloud-audit telemetry is unavailable.

·        Without cloud-audit confirmation, describe the result as anomalous access to a sensitive cloud-service family.

·        Treat metadata access without anomalous follow-on behavior as hunt or supporting evidence only.

Required Telemetry

·        NDR, DNS, proxy, firewall, and network-flow telemetry.

·        Cloud metadata, managed-identity, workload-identity, service-account token, and token-broker endpoint definitions.

·        Canonical asset-crosswalk data for Linux hosts, cloud instances, Kubernetes nodes, container hosts, workload identities, and source hosts.

·        Cloud identity, secret-management, storage, snapshot, repository, deployment, and infrastructure-management endpoint classifications.

·        Approved metadata and workload-identity access baselines.

·        Destination rarity and reputation.

·        Conditional request-path, method, user-agent, and source-process fields where available.

·        Optional cloud-audit and identity enrichment.

Engineering Implementation Instructions

·        Resolve source, host, instance, node, container-host, and workload-identity identifiers to one canonical workload ID before filtering.

·        Do not use raw COALESCE() selection as the final correlation identity.

·        Maintain provider-specific metadata and workload-identity endpoint definitions.

·        Validate whether link-local metadata traffic is visible to the NDR platform.

·        Distinguish baseline flow fields from conditional HTTP, proxy, service-mesh, gateway, application, or endpoint-enriched fields.

·        Do not require request path, request method, user agent, or source process unless the environment collects them.

·        Baseline workloads that legitimately access metadata, identity, token, secret, or cloud-management services.

·        Require anomalous follow-on activity rather than alerting on metadata access alone.

·        Use the same canonical workload ID as the mandatory primary-sequence key.

·        Treat cloud account, subscription, project, and region only as supporting context.

·        Suppress approved initialization, autoscaling, deployment, backup, monitoring, orchestration, and cloud-agent activity.

·        Enrich the completed network sequence with cloud-audit telemetry where available.

·        Do not make cloud-audit telemetry a prerequisite for the underlying NDR alert.

·        Describe unconfirmed service access as access to a sensitive cloud-service family rather than confirmed secret retrieval, role assumption, or control modification.

DRI Assessment

The rule is behaviorally durable because it detects access to and possible use of cloud or workload trust paths rather than a specific vulnerability. Detection strength depends on metadata visibility, canonical workload mapping, correct baseline exclusions, and strict same-workload correlation.

DRI

8.6

TCR Assessment

Operational confidence is moderate to strong where metadata traffic and canonical source-workload identity are visible. Full-telemetry confidence increases when optional cloud-audit, endpoint process, Kubernetes, container, identity, and vulnerable-state telemetry confirms the follow-on action.

Operational TCR

8.1

Full-Telemetry TCR

9.0

Limitations

·        Many cloud workloads legitimately access metadata and identity services.

·        Link-local metadata traffic may not traverse monitored network sensors.

·        Service meshes, proxies, gateways, NAT, and overlays may obscure the originating workload.

·        Asset-crosswalk gaps may prevent correlation between metadata access, follow-on traffic, and cloud-audit activity.

·        Approved automation may access sensitive cloud-service families.

·        Network telemetry alone may identify a destination service but not the specific API action.

·        The rule cannot independently prove credential retrieval, root access, role assumption, secret access, or cloud-control-plane compromise.

·        Provider-specific endpoint mappings require continuing maintenance.

Detection Query Pattern

Use this pattern as an implementation guide for NDR and Network Behavioral Analytics platforms that support canonical workload identity resolution, cloud metadata identification, approved metadata-access baselines, sensitive cloud-service classification, conditional application-layer fields, optional cloud-audit enrichment, and strict same-workload sequence logic.

LET CLOUD_CONNECTED_LINUX_CANONICAL_WORKLOADS =

ENV_AWS_LINUX_CANONICAL_IDS

OR ENV_AZURE_LINUX_CANONICAL_IDS

OR ENV_GCP_LINUX_CANONICAL_IDS

OR ENV_KUBERNETES_WORKER_NODE_CANONICAL_IDS

OR ENV_CONTAINER_HOST_CANONICAL_IDS

OR ENV_CLOUD_CI_RUNNER_CANONICAL_IDS

OR ENV_CLOUD_BUILD_SYSTEM_CANONICAL_IDS

OR ENV_CLOUD_PRIVILEGED_AUTOMATION_CANONICAL_IDS

OR ENV_CLOUD_PRODUCTION_LINUX_CANONICAL_IDS

LET CLOUD_METADATA_OR_IDENTITY_ENDPOINTS =

ENV_AWS_INSTANCE_METADATA_ENDPOINTS

OR ENV_AWS_CONTAINER_CREDENTIAL_ENDPOINTS

OR ENV_AZURE_INSTANCE_METADATA_ENDPOINTS

OR ENV_AZURE_MANAGED_IDENTITY_ENDPOINTS

OR ENV_GCP_METADATA_ENDPOINTS

OR ENV_GCP_SERVICE_ACCOUNT_TOKEN_ENDPOINTS

OR ENV_KUBERNETES_SERVICE_ACCOUNT_ENDPOINTS

OR ENV_WORKLOAD_IDENTITY_ENDPOINTS

OR ENV_LOCAL_TOKEN_BROKER_ENDPOINTS

LET APPROVED_METADATA_ACCESS_PATTERNS =

ENV_APPROVED_BOOTSTRAP_METADATA_ACCESS

OR ENV_APPROVED_CLOUD_AGENT_METADATA_ACCESS

OR ENV_APPROVED_ORCHESTRATION_METADATA_ACCESS

OR ENV_APPROVED_MONITORING_METADATA_ACCESS

OR ENV_APPROVED_BACKUP_METADATA_ACCESS

OR ENV_APPROVED_DEPLOYMENT_METADATA_ACCESS

OR ENV_APPROVED_WORKLOAD_IDENTITY_ACCESS

OR ENV_APPROVED_AUTOSCALING_METADATA_ACCESS

LET SENSITIVE_CLOUD_SERVICE_FAMILIES =

ENV_CLOUD_IDENTITY_SERVICE_FAMILY

OR ENV_CLOUD_TOKEN_SERVICE_FAMILY

OR ENV_CLOUD_SECRET_MANAGEMENT_SERVICE_FAMILY

OR ENV_CLOUD_STORAGE_SERVICE_FAMILY

OR ENV_CLOUD_SNAPSHOT_SERVICE_FAMILY

OR ENV_CLOUD_IAM_SERVICE_FAMILY

OR ENV_CLOUD_SECURITY_CONTROL_SERVICE_FAMILY

OR ENV_CODE_REPOSITORY_SERVICE_FAMILY

OR ENV_ARTIFACT_REPOSITORY_SERVICE_FAMILY

OR ENV_PACKAGE_REGISTRY_SERVICE_FAMILY

OR ENV_DEPLOYMENT_PLATFORM_SERVICE_FAMILY

OR ENV_INFRASTRUCTURE_MANAGEMENT_SERVICE_FAMILY

LET normalized_metadata_access_events =

network_proxy_gateway_service_mesh_endpoint_or_flow_events

EVAL normalized_workload_identity =

COALESCE(

workload_identity_id,

source_workload_identity

)

EVAL canonical_source_workload =

RESOLVE_CANONICAL_WORKLOAD_ID(

source_asset_id,

cloud_instance_id,

kubernetes_node_id,

container_host_id,

ci_runner_id,

normalized_workload_identity,

source_host_id,

source_ip

)

EVAL metadata_or_identity_endpoint =

COALESCE(

destination_endpoint,

destination_ip,

destination_service

)

EVAL metadata_access_pattern =

access_pattern

EVAL metadata_request_path =

request_path

EVAL metadata_request_method =

request_method

EVAL metadata_user_agent =

user_agent

WHERE canonical_source_workload IN CLOUD_CONNECTED_LINUX_CANONICAL_WORKLOADS

AND canonical_source_workload IS NOT NULL

AND metadata_or_identity_endpoint IN CLOUD_METADATA_OR_IDENTITY_ENDPOINTS

AND metadata_access_pattern NOT IN APPROVED_METADATA_ACCESS_PATTERNS

LET suspicious_metadata_or_identity_access =

normalized_metadata_access_events

WHERE (

normalized_workload_identity NOT IN ENV_EXPECTED_WORKLOAD_IDENTITIES

OR workload_role NOT IN ENV_EXPECTED_METADATA_ACCESS_ROLES

OR request_cadence IN (

"rapid_enumeration",

"repeated_token_request",

"unusual_retry"

)

OR metadata_access_first_seen_status IN ("new", "rare")

OR (

application_layer_fields_available = true

AND (

metadata_request_path MATCHES_ANY ENV_SENSITIVE_METADATA_OR_TOKEN_PATHS

OR metadata_request_method NOT IN ENV_EXPECTED_METADATA_REQUEST_METHODS

OR metadata_user_agent NOT IN ENV_EXPECTED_METADATA_USER_AGENTS

OR source_process_first_seen_status IN ("new", "rare", "unknown")

)

)

)

LET normalized_follow_on_network_activity =

dns_proxy_firewall_ndr_gateway_or_flow_events

EVAL normalized_follow_on_workload_identity =

COALESCE(

workload_identity_id,

source_workload_identity

)

EVAL canonical_follow_on_workload =

RESOLVE_CANONICAL_WORKLOAD_ID(

source_asset_id,

cloud_instance_id,

kubernetes_node_id,

container_host_id,

ci_runner_id,

normalized_follow_on_workload_identity,

source_host_id,

source_ip

)

EVAL normalized_destination =

COALESCE(

destination_domain,

destination_ip,

destination_service

)

EVAL normalized_destination_service_family =

COALESCE(

destination_service_family,

MAP_SERVICE_NAME_TO_FAMILY(destination_service),

MAP_DESTINATION_TO_CLOUD_SERVICE_FAMILY(

destination_domain,

destination_ip

)

)

WHERE canonical_follow_on_workload IN CLOUD_CONNECTED_LINUX_CANONICAL_WORKLOADS

AND canonical_follow_on_workload IS NOT NULL

AND normalized_destination IS NOT NULL

LET anomalous_follow_on_network_activity =

normalized_follow_on_network_activity

WHERE (

normalized_destination_service_family IN SENSITIVE_CLOUD_SERVICE_FAMILIES

OR destination_first_seen_status IN ("new", "rare")

OR destination_reputation IN ("unknown", "suspicious", "malicious")

OR network_behavior IN (

"rare_external_connection",

"callback_like",

"tool_retrieval_like",

"tunneling_like",

"unexpected_cloud_service_access",

"unexpected_repository_access",

"unexpected_deployment_service_access"

)

)

LET metadata_to_follow_on_sequence =

SEQUENCE suspicious_metadata_or_identity_access

THEN anomalous_follow_on_network_activity

BY canonical_source_workload = canonical_follow_on_workload

WITHIN ENV_METADATA_ACCESS_TO_FOLLOW_ON_ACTIVITY_WINDOW

LET optional_cloud_audit_context =

cloud_audit_or_identity_events

EVAL normalized_cloud_audit_workload_identity =

COALESCE(

workload_identity_id,

source_workload_identity,

principal_identity_id

)

EVAL canonical_cloud_audit_workload =

RESOLVE_CANONICAL_WORKLOAD_ID(

source_asset_id,

cloud_instance_id,

kubernetes_node_id,

container_host_id,

ci_runner_id,

normalized_cloud_audit_workload_identity,

source_host_id,

source_ip

)

EVAL confirmed_cloud_action =

cloud_action

WHERE canonical_cloud_audit_workload IS NOT NULL

AND confirmed_cloud_action IN (

"secret_retrieval",

"token_service_access",

"role_use",

"snapshot_activity",

"storage_access",

"security_control_change"

)

LET enriched_metadata_to_follow_on_sequence =

ENRICH metadata_to_follow_on_sequence

WITH OPTIONAL optional_cloud_audit_context

WHERE canonical_source_workload = canonical_cloud_audit_workload

WITHIN ENV_NETWORK_TO_CLOUD_AUDIT_ENRICHMENT_WINDOW

OUTPUT enriched_metadata_to_follow_on_sequence

canonical_source_workload,

source_asset_id,

source_host,

source_host_id,

source_ip,

source_asset_role,

normalized_workload_identity,

cloud_provider,

cloud_account,

subscription,

project,

cloud_instance_id,

kubernetes_cluster,

kubernetes_node_id,

container_host_id,

ci_runner_id,

metadata_or_identity_endpoint,

metadata_access_first_seen_status,

metadata_request_path,

metadata_request_method,

metadata_user_agent,

metadata_access_pattern,

application_layer_fields_available,

normalized_destination,

normalized_destination_service_family,

destination_first_seen_status,

destination_reputation,

network_behavior,

cloud_audit_enrichment_present,

confirmed_cloud_action,

first_seen,

last_seen,

time_delta

Rule

Abnormal East-West Expansion From Linux Workloads

Rule Format

NDR or Network Behavioral Analytics anomaly and behavioral-correlation pattern using canonical Linux workload identity resolution, role-aware peer baselines, trust-sensitive service classification, destination-port-to-service mapping, fan-out analysis, rate-of-change analysis, approved-management exceptions, and optional source-context enrichment.

Detection Purpose

Detect Linux workloads that begin communicating with an unusual number or class of internal systems, administrative services, orchestration platforms, repositories, databases, storage systems, backup platforms, identity services, Kubernetes resources, container infrastructure, CI/CD systems, or management interfaces.

The rule identifies anomalous lateral movement, trust expansion, service discovery, and infrastructure access that may follow host compromise or privilege escalation.

Detection Logic

·        Resolve all source identifiers through a canonical workload crosswalk before filtering or correlation.

·        Establish expected internal destination, service, port, and peer-group baselines for each Linux workload role.

·        Normalize destination ports, protocols, service names, and asset roles into a consistent destination-service family.

·        Detect sudden increases in unique destinations, unique ports, administrative protocols, management interfaces, or trust-sensitive service families.

·        Prioritize SSH fan-out, scan-like activity, service enumeration, Kubernetes API access, kubelet access, container runtime access, repository access, package-registry access, backup access, storage access, database access, identity-service access, deployment-platform access, and infrastructure-management activity.

·        Require deviation from the workload’s historical peer and service profile.

·        Require role-aware minimum thresholds for fan-out, unique destinations, unique ports, rate change, scan attempts, or protected-service access.

·        Exclude approved orchestration, configuration management, vulnerability scanning, monitoring, backup, deployment, incident response, and administrative workflows.

·        Alert independently on sufficiently strong east-west expansion.

·        Increase severity when the expansion aligns with unusual inbound activity, rare egress, metadata access, identity anomalies, container behavior, endpoint anomalies, or security-control degradation.

·        Do not claim successful privilege escalation solely from network expansion.

Required Telemetry

·        East-west NDR telemetry.

·        Internal firewall and flow telemetry.

·        DNS and proxy telemetry where relevant.

·        Canonical source and destination asset identities.

·        Source and destination roles.

·        Internal service, protocol, and port classification.

·        Destination-port-to-service-family mapping.

·        Kubernetes, container, cloud, CI/CD, repository, storage, backup, database, identity, and management-service mappings.

·        Approved peer-group and administrative-path baselines.

·        Unique-destination, unique-port, fan-out, scan, rate-of-change, and protected-service metrics.

·        Maintenance, deployment, vulnerability-scanning, backup, and incident-response exceptions.

·        Optional endpoint, identity, cloud, container, Kubernetes, or CI/CD context.

Engineering Implementation Instructions

·        Resolve all source identifiers to one canonical workload ID before filtering.

·        Do not use raw COALESCE() identity selection as the final correlation key.

·        Build role-specific east-west communication and peer-group baselines.

·        Separate expected application dependencies from administrative, management, and trust-sensitive paths.

·        Normalize service name, destination role, protocol, and port through an environment-maintained service-family map.

·        Do not compare raw numeric destination ports directly with named service collections.

·        Maintain service classifications for SSH, Kubernetes APIs, kubelet, container runtimes, databases, storage, backup, identity, repositories, package registries, CI/CD, orchestration, monitoring, deployment, and infrastructure management.

·        Use role-aware rate-of-change, unique-destination, unique-port, scan, fan-out, and protected-service thresholds.

·        Tune vulnerability scanners, configuration management, orchestration, backup, monitoring, asset discovery, deployment, and incident-response systems.

·        Preserve canonical source attribution across overlays, NAT, service meshes, cloud networks, and shared infrastructure.

·        Escalate access from application servers, container hosts, Kubernetes nodes, CI runners, and production workloads into administrative or trust-sensitive infrastructure.

·        Use supporting context as optional severity enrichment rather than a mandatory sequence prerequisite.

·        Run in hunt mode until identity mappings, normal peer groups, protected services, and rate-of-change thresholds are validated.

·        Present the alert as anomalous internal expansion from a Linux workload.

DRI Assessment

The rule detects durable post-compromise expansion behavior and remains resilient to changes in exploit implementation. Role-aware baselining, protected-service classification, independent anomaly logic, canonical workload resolution, and optional contextual enrichment provide strong operational value.

DRI

8.8

TCR Assessment

Operational confidence depends on complete east-west visibility, canonical source attribution, accurate asset roles, service classification, and expected-peer baselines. Full-telemetry confidence improves with endpoint, identity, Kubernetes, container, cloud, CI/CD, and preceding-access context.

Operational TCR

8.4

Full-Telemetry TCR

9.2

Limitations

·        Orchestration, configuration management, vulnerability scanning, backup, monitoring, deployment, and incident-response systems can generate similar expansion behavior.

·        Incomplete east-west visibility may miss activity across cloud accounts, clusters, regions, overlays, VPNs, or segmented networks.

·        Shared services, proxies, service meshes, and gateways may obscure the true source.

·        Asset-crosswalk gaps may prevent events from being joined to the correct canonical workload.

·        Newly deployed or reconfigured applications may legitimately contact previously unseen internal services.

·        The rule detects anomalous expansion but does not prove the originating privilege-escalation mechanism.

·        Accurate canonical identity, role, protected-service, expected-peer, service-family, and approved-path mapping is mandatory for production deployment.

Detection Query Pattern

Use this pattern as an implementation guide for NDR and Network Behavioral Analytics platforms that support canonical Linux workload identity resolution, role-aware peer baselines, destination-port-to-service mapping, protected-service classification, fan-out analysis, rate-of-change analysis, approved automation context, optional supporting-context enrichment, and standalone anomaly logic.

LET MONITORED_LINUX_CANONICAL_WORKLOADS =

ENV_LINUX_APPLICATION_SERVER_CANONICAL_IDS

OR ENV_CLOUD_LINUX_CANONICAL_IDS

OR ENV_KUBERNETES_WORKER_NODE_CANONICAL_IDS

OR ENV_CONTAINER_HOST_CANONICAL_IDS

OR ENV_CI_RUNNER_CANONICAL_IDS

OR ENV_BUILD_SYSTEM_CANONICAL_IDS

OR ENV_DEVELOPER_LINUX_CANONICAL_IDS

OR ENV_PRIVILEGED_AUTOMATION_CANONICAL_IDS

OR ENV_PRODUCTION_LINUX_CANONICAL_IDS

OR ENV_HIGH_VALUE_OPERATIONAL_LINUX_CANONICAL_IDS

LET TRUST_SENSITIVE_INTERNAL_SERVICE_FAMILIES =

ENV_SSH_SERVICE_FAMILY

OR ENV_ADMINISTRATIVE_INTERFACE_FAMILIES

OR ENV_KUBERNETES_API_SERVICE_FAMILY

OR ENV_KUBELET_SERVICE_FAMILY

OR ENV_CONTAINER_RUNTIME_SERVICE_FAMILIES

OR ENV_IDENTITY_SERVICE_FAMILIES

OR ENV_DATABASE_SERVICE_FAMILIES

OR ENV_STORAGE_SERVICE_FAMILIES

OR ENV_BACKUP_SERVICE_FAMILIES

OR ENV_CODE_REPOSITORY_SERVICE_FAMILIES

OR ENV_ARTIFACT_REPOSITORY_SERVICE_FAMILIES

OR ENV_PACKAGE_REGISTRY_SERVICE_FAMILIES

OR ENV_CI_CD_PLATFORM_SERVICE_FAMILIES

OR ENV_DEPLOYMENT_PLATFORM_SERVICE_FAMILIES

OR ENV_ORCHESTRATION_SERVICE_FAMILIES

OR ENV_MONITORING_MANAGEMENT_SERVICE_FAMILIES

OR ENV_INFRASTRUCTURE_MANAGEMENT_SERVICE_FAMILIES

OR ENV_CLOUD_MANAGEMENT_SERVICE_FAMILIES

LET APPROVED_EAST_WEST_EXCEPTIONS =

ENV_APPROVED_APPLICATION_DEPENDENCIES

OR ENV_APPROVED_ADMINISTRATIVE_PATHS

OR ENV_APPROVED_CONFIGURATION_MANAGEMENT_PATHS

OR ENV_APPROVED_ORCHESTRATION_PATHS

OR ENV_APPROVED_VULNERABILITY_SCANNERS

OR ENV_APPROVED_BACKUP_PATHS

OR ENV_APPROVED_MONITORING_PATHS

OR ENV_APPROVED_DEPLOYMENT_PATHS

OR ENV_APPROVED_INCIDENT_RESPONSE_PATHS

OR ENV_APPROVED_RED_TEAM_PATHS

LET APPROVED_EAST_WEST_CONTEXT_EXCEPTIONS =

ENV_APPROVED_MAINTENANCE_WINDOWS

OR ENV_APPROVED_DEPLOYMENT_WINDOWS

OR ENV_APPROVED_PATCH_WINDOWS

OR ENV_APPROVED_BACKUP_WINDOWS

OR ENV_APPROVED_VULNERABILITY_SCAN_WINDOWS

OR ENV_APPROVED_INCIDENT_RESPONSE_WINDOWS

OR ENV_APPROVED_RED_TEAM_WINDOWS

LET normalized_internal_activity =

internal_ndr_firewall_dns_or_flow_events

EVAL canonical_source_workload =

RESOLVE_CANONICAL_WORKLOAD_ID(

source_asset_id,

cloud_instance_id,

kubernetes_node_id,

container_host_id,

ci_runner_id,

workload_identity_id,

source_host_id,

source_ip

)

EVAL canonical_destination_asset =

RESOLVE_CANONICAL_ASSET_ID(

destination_asset_id,

destination_host_id,

destination_ip

)

EVAL normalized_destination_service_family =

COALESCE(

destination_service_family,

MAP_SERVICE_NAME_TO_FAMILY(destination_service),

MAP_PORT_PROTOCOL_TO_SERVICE_FAMILY(

destination_port,

destination_protocol

),

MAP_DESTINATION_ROLE_TO_SERVICE_FAMILY(destination_role)

)

WHERE canonical_source_workload IN MONITORED_LINUX_CANONICAL_WORKLOADS

AND canonical_source_workload IS NOT NULL

AND normalized_destination_service_family IS NOT NULL

AND event_time NOT IN APPROVED_EAST_WEST_CONTEXT_EXCEPTIONS

LET abnormal_internal_expansion =

normalized_internal_activity

WHERE normalized_destination_service_family

IN TRUST_SENSITIVE_INTERNAL_SERVICE_FAMILIES

AND communication_path NOT IN APPROVED_EAST_WEST_EXCEPTIONS

AND (

destination_first_seen_status IN ("new", "rare")

OR destination_peer_group

NOT IN ENV_EXPECTED_PEER_GROUPS_BY_SOURCE_ROLE

OR normalized_destination_service_family

NOT IN ENV_EXPECTED_SERVICE_FAMILIES_BY_SOURCE_ROLE

OR internal_behavior IN (

"ssh_fan_out",

"internal_scan_like",

"service_enumeration_like",

"administrative_interface_access",

"kubernetes_api_access",

"kubelet_access",

"container_runtime_access",

"unexpected_database_access",

"unexpected_storage_access",

"unexpected_backup_access",

"unexpected_identity_service_access",

"unexpected_repository_access",

"unexpected_package_registry_access",

"unexpected_deployment_access",

"unexpected_infrastructure_management_access"

)

)

GROUP BY

canonical_source_workload,

destination_peer_group,

normalized_destination_service_family

WHERE (

unique_destination_count

>= ENV_ROLE_AWARE_UNIQUE_DESTINATION_THRESHOLD

OR unique_destination_port_count

>= ENV_ROLE_AWARE_UNIQUE_PORT_THRESHOLD

OR connection_rate_change

>= ENV_ROLE_AWARE_CONNECTION_RATE_CHANGE_THRESHOLD

OR protected_service_count

>= ENV_ROLE_AWARE_PROTECTED_SERVICE_THRESHOLD

OR scan_attempt_count

>= ENV_MINIMUM_SCAN_ATTEMPT_THRESHOLD

OR fan_out_count

>= ENV_MINIMUM_FAN_OUT_THRESHOLD

)

LET supporting_source_context =

network_endpoint_identity_cloud_container_kubernetes_or_ci_events

EVAL canonical_context_workload =

RESOLVE_CANONICAL_WORKLOAD_ID(

source_asset_id,

cloud_instance_id,

kubernetes_node_id,

container_host_id,

ci_runner_id,

workload_identity_id,

source_host_id,

source_ip

)

EVAL supporting_source_behavior =

source_behavior

WHERE canonical_context_workload IN MONITORED_LINUX_CANONICAL_WORKLOADS

AND supporting_source_behavior IN (

"unusual_external_access",

"suspicious_ssh_access",

"rare_external_connection",

"metadata_or_identity_access",

"new_identity_use",

"container_originated_anomaly",

"kubernetes_node_anomaly",

"security_control_degradation",

"unexpected_root_process",

"role_profile_change"

)

LET enriched_abnormal_internal_expansion =

ENRICH abnormal_internal_expansion

WITH OPTIONAL supporting_source_context

WHERE canonical_source_workload = canonical_context_workload

WITHIN ENV_OPTIONAL_CONTEXT_TO_INTERNAL_EXPANSION_WINDOW

OUTPUT enriched_abnormal_internal_expansion

canonical_source_workload,

canonical_destination_asset,

source_asset_id,

source_host,

source_host_id,

source_ip,

source_asset_role,

source_business_criticality,

cloud_account,

cloud_instance_id,

kubernetes_cluster,

kubernetes_node_id,

container_host_id,

ci_runner_id,

workload_identity_id,

supporting_context_present,

supporting_source_behavior,

destination_asset_id,

destination_host,

destination_host_id,

destination_ip,

destination_port,

destination_protocol,

normalized_destination_service_family,

destination_asset_role,

destination_peer_group,

destination_first_seen_status,

internal_behavior,

unique_destination_count,

unique_destination_port_count,

protected_service_count,

scan_attempt_count,

fan_out_count,

connection_rate_change,

first_seen,

last_seen

SentinelOne

Detection Viability Assessment

SentinelOne can provide strong behavior-driven coverage for Linux foothold-to-root activity when Deep Visibility or STAR logic exposes endpoint tags, process creation, parent-process lineage, command-line data, real-user and effective-user context, executable and working-directory paths, file activity, security-agent events, network connections, container or Kubernetes context, and approved administrative exceptions.

Three rule opportunities survive validation:

·        Suspicious exploit staging and execution from writable or transient Linux paths.

·        Abnormal low-privilege-to-root execution transition.

·        Suspicious root-level access to sensitive resources, persistence locations, or security controls.

Each rule remains independently evaluable. Rule 1 detects suspicious preparation and execution but does not claim successful privilege escalation. Rule 2 provides the strongest SentinelOne privilege-transition coverage when user and process-lineage fields are reliable. Rule 3 detects high-risk root activity without requiring Rule 2 to fire first.

Cloud-control-plane, Kubernetes API, repository, CI/CD, NDR, vulnerability-state, and multi-endpoint correlation should occur through Singularity Data Lake, XDR, or downstream SIEM workflows where those data sources are available.

Rule

Suspicious Linux Exploit Staging and Execution From Writable Paths

Rule Format

SentinelOne Deep Visibility or STAR sequence pattern using Linux endpoint tags, process telemetry, file telemetry, normalized user identity, normalized file and executable paths, compilation activity, permission changes, short-lived artifact behavior, approved workflow exceptions, bounded-time file-to-process correlation, and normalized sequence outputs.

Detection Purpose

Detect suspicious creation, compilation, permission modification, execution, and rapid deletion of scripts, ELF binaries, source files, compiled objects, or unfamiliar executables from writable, transient, user-controlled, build, workspace, mounted, or container-layer paths.

The rule identifies behavior consistent with local exploit preparation or execution by a constrained user, service account, application account, CI runner, container process, or other non-administrative context. It does not claim that privilege escalation succeeded.

Detection Logic

·        Scope the rule to Linux endpoints with validated process and file telemetry.

·        Normalize process, real-user, effective-user, UID, and effective-UID fields before classifying activity as non-root or non-administrative.

·        Normalize file and executable paths before correlation.

·        Identify creation, writing, modification, or rename activity affecting executable, script, source, object, archive, or unfamiliar files in writable or transient paths.

·        Correlate the staged file with execution of the same normalized path, file hash, or file identity on the same endpoint.

·        Detect permission-change-to-execute behavior separately from general create-or-modify-to-execute behavior.

·        Detect create-execute-delete behavior by directly joining the staged-file, execution, and deletion events.

·        Permit validated cross-user execution only when strong file-hash or file-identity matching establishes the artifact relationship.

·        Normalize all three sequence branches into a common result schema before combining them.

·        Prioritize shells, scripting interpreters, compilers, linkers, build tools, download tools, archive tools, permission-modification tools, or unfamiliar local executables.

·        Exclude approved build, package-management, deployment, orchestration, vulnerability-validation, incident-response, development, and administrative workflows.

·        Treat exploit names, hashes, strings, repository names, and CVE identifiers as optional enrichment only.

Required Telemetry

·        SentinelOne Linux process telemetry.

·        File creation, write, modification, rename, permission, ownership, execution, and deletion telemetry.

·        Endpoint identifier, endpoint tags, operating system, workload role, and business criticality.

·        Process identifier, Storyline identifier, process name, process path, image hash, parent process, command line, and working directory.

·        Process user, real user, effective user, UID, and effective UID.

·        File path, normalized file path, file name, file type, extension, hash, file identity where available, and event time.

·        Container, Kubernetes node, CI-runner, build-system, or cloud-workload tags where available.

·        Approved users, processes, tools, paths, workflows, and maintenance windows.

Engineering Implementation Instructions

·        Validate file-event and process-event availability on deployed Linux agent versions.

·        Normalize users and UIDs before determining whether the actor is root, approved administrative, or constrained.

·        Require affirmative non-root evidence rather than treating missing identity fields as non-root.

·        Normalize file and process-image paths before joining events.

·        Prefer file hash or file identity where available.

·        Use normalized path, endpoint, user, and bounded time when stronger artifact identity is unavailable.

·        Keep create-or-modify-to-execute, permission-change-to-execute, and create-execute-delete sequences independently evaluable.

·        Exclude permission and ownership events from the general create-or-modify sequence.

·        Apply cross-user execution only when enabled and supported by non-null, matching file hash or file identity.

·        Project each sequence branch into the same output schema before combining results.

·        Use shorter windows on stable production servers and role-aware windows on CI or build systems.

·        Maintain separate exceptions for build systems, package managers, deployment platforms, vulnerability validation, incident response, and approved development activity.

·        Treat writable-path activity as context, not proof, unless joined to execution or short-lived artifact behavior.

·        Deploy in hunt mode before promoting to STAR alerting.

·        Describe the result as suspected exploit staging or suspicious local execution.

DRI Assessment

The rule targets durable exploit-staging behavior rather than a specific CVE, exploit name, or kernel primitive. Variant resilience is strong, but writable-path compilation and execution can be legitimate on development, build, and CI systems and therefore requires workload-aware tuning.

DRI

8.5

TCR Assessment

Operational confidence depends on reliable file-to-process correlation, normalized user identity, path normalization, sequence-output consistency, and approved workflow exceptions. Full-telemetry confidence improves with effective-user fields, vulnerable-state enrichment, container or Kubernetes context, and subsequent privilege-transition evidence.

Operational TCR

8.3

Full-Telemetry TCR

8.9

Limitations

·        Development systems, CI runners, build systems, package managers, deployment tools, and vulnerability scanners may generate similar behavior.

·        File telemetry may not capture every short-lived artifact.

·        In-memory compilation, execution without a persistent file, or use of existing trusted binaries may reduce visibility.

·        File-path reuse can create false joins when hash or file identity is unavailable.

·        Process ancestry may be incomplete across shells, service managers, containers, namespaces, or rapid process termination.

·        Cross-user execution requires strong artifact identity and environment-specific validation.

·        The rule does not prove successful privilege escalation.

Detection Query Pattern

Use this pattern as an implementation guide for SentinelOne Deep Visibility or STAR logic that supports Linux endpoint tags, process telemetry, file telemetry, user normalization, file-path and process-path normalization, compilation detection, permission-change detection, short-lived artifact correlation, approved workflow exceptions, normalized branch outputs, and bounded-time sequence logic. Vulnerability-state, cloud-control-plane, Kubernetes API, NDR, repository, CI/CD, and multi-host correlation should occur in the SIEM, XDR, or downstream investigation workflow.

LET MONITORED_LINUX_ENDPOINTS =

EndpointTags CONTAINS ANY (

"ENV_INTERNET_FACING_LINUX_WORKLOADS",

"ENV_CLOUD_LINUX_INSTANCES",

"ENV_KUBERNETES_WORKER_NODES",

"ENV_CONTAINER_HOSTS",

"ENV_CI_RUNNERS",

"ENV_BUILD_SYSTEMS",

"ENV_DEVELOPER_LINUX_SYSTEMS",

"ENV_PRIVILEGED_AUTOMATION_HOSTS",

"ENV_PRODUCTION_LINUX_SERVERS",

"ENV_HIGH_VALUE_OPERATIONAL_LINUX_ASSETS"

)

LET APPROVED_STAGING_CONTEXT =

UserName IN ENV_APPROVED_LINUX_ADMIN_USERS

OR UserName IN ENV_APPROVED_BUILD_USERS

OR UserName IN ENV_APPROVED_CI_USERS

OR UserName IN ENV_APPROVED_DEPLOYMENT_USERS

OR UserName IN ENV_APPROVED_VULNERABILITY_VALIDATION_USERS

OR UserName IN ENV_APPROVED_INCIDENT_RESPONSE_USERS

OR ProcessName IN ENV_APPROVED_PACKAGE_MANAGERS

OR ProcessName IN ENV_APPROVED_BUILD_TOOLS

OR ProcessName IN ENV_APPROVED_DEPLOYMENT_TOOLS

OR ProcessName IN ENV_APPROVED_CONFIGURATION_MANAGEMENT_TOOLS

OR ProcessName IN ENV_APPROVED_VULNERABILITY_VALIDATION_TOOLS

OR CommandLine MATCHES ANY ENV_APPROVED_BUILD_COMMAND_PATTERNS

OR CommandLine MATCHES ANY ENV_APPROVED_DEPLOYMENT_COMMAND_PATTERNS

OR CommandLine MATCHES ANY ENV_APPROVED_PACKAGE_MANAGEMENT_PATTERNS

OR EventTime IN ENV_APPROVED_BUILD_WINDOWS

OR EventTime IN ENV_APPROVED_DEPLOYMENT_WINDOWS

OR EventTime IN ENV_APPROVED_PATCH_WINDOWS

OR EventTime IN ENV_APPROVED_MAINTENANCE_WINDOWS

OR EventTime IN ENV_APPROVED_VULNERABILITY_VALIDATION_WINDOWS

OR EventTime IN ENV_APPROVED_INCIDENT_RESPONSE_WINDOWS

LET GENERAL_STAGED_FILE_EVENT =

FROM FileEvents

EVAL NormalizedUserContext =

NORMALIZE_USER_CONTEXT(

ProcessUser,

RealUser,

EffectiveUser,

ProcessUid,

EffectiveUid

)

EVAL NormalizedFilePath =

NORMALIZE_LINUX_PATH(FilePath)

WHERE MONITORED_LINUX_ENDPOINTS = true

AND APPROVED_STAGING_CONTEXT != true

AND NormalizedUserContext.identity_state = "known"

AND NormalizedUserContext.effective_root = false

AND NormalizedUserContext.approved_administrator = false

AND FilePath STARTS_WITH ANY (

ENV_LINUX_TEMP_PATH_PREFIXES,

ENV_LINUX_SHARED_MEMORY_PATH_PREFIXES,

ENV_LINUX_USER_HOME_PATH_PREFIXES,

ENV_LINUX_APPLICATION_WORKSPACE_PATH_PREFIXES,

ENV_LINUX_CI_WORKSPACE_PATH_PREFIXES,

ENV_LINUX_BUILD_PATH_PREFIXES,

ENV_LINUX_RUNNER_PATH_PREFIXES,

ENV_LINUX_MOUNTED_VOLUME_PATH_PREFIXES,

ENV_LINUX_CONTAINER_WRITABLE_LAYER_PATH_PREFIXES

)

AND EventType IN (

"file_created",

"file_written",

"file_modified",

"file_renamed"

)

AND (

FileExtension IN ENV_EXECUTABLE_SCRIPT_SOURCE_OR_OBJECT_EXTENSIONS

OR FileType IN (

"elf",

"script",

"source_code",

"compiled_object",

"archive",

"unknown_executable"

)

OR FileName MATCHES ANY ENV_SUSPICIOUS_TEMPORARY_FILE_PATTERNS

)

LET PERMISSION_OR_OWNERSHIP_CHANGE_EVENT =

FROM FileEvents

EVAL NormalizedUserContext =

NORMALIZE_USER_CONTEXT(

ProcessUser,

RealUser,

EffectiveUser,

ProcessUid,

EffectiveUid

)

EVAL NormalizedFilePath =

NORMALIZE_LINUX_PATH(FilePath)

WHERE MONITORED_LINUX_ENDPOINTS = true

AND APPROVED_STAGING_CONTEXT != true

AND NormalizedUserContext.identity_state = "known"

AND NormalizedUserContext.effective_root = false

AND NormalizedUserContext.approved_administrator = false

AND FilePath STARTS_WITH ANY (

ENV_LINUX_TEMP_PATH_PREFIXES,

ENV_LINUX_SHARED_MEMORY_PATH_PREFIXES,

ENV_LINUX_USER_HOME_PATH_PREFIXES,

ENV_LINUX_APPLICATION_WORKSPACE_PATH_PREFIXES,

ENV_LINUX_CI_WORKSPACE_PATH_PREFIXES,

ENV_LINUX_BUILD_PATH_PREFIXES,

ENV_LINUX_RUNNER_PATH_PREFIXES,

ENV_LINUX_MOUNTED_VOLUME_PATH_PREFIXES,

ENV_LINUX_CONTAINER_WRITABLE_LAYER_PATH_PREFIXES

)

AND EventType IN (

"permission_modified",

"ownership_modified"

)

AND (

FileExtension IN ENV_EXECUTABLE_SCRIPT_SOURCE_OR_OBJECT_EXTENSIONS

OR FileType IN (

"elf",

"script",

"compiled_object",

"unknown_executable"

)

OR FileName MATCHES ANY ENV_SUSPICIOUS_TEMPORARY_FILE_PATTERNS

)

LET WRITABLE_OR_TRANSIENT_EXECUTION =

FROM ProcessEvents

EVAL NormalizedUserContext =

NORMALIZE_USER_CONTEXT(

ProcessUser,

RealUser,

EffectiveUser,

ProcessUid,

EffectiveUid

)

EVAL NormalizedProcessPath =

NORMALIZE_LINUX_PATH(ProcessPath)

WHERE MONITORED_LINUX_ENDPOINTS = true

AND APPROVED_STAGING_CONTEXT != true

AND NormalizedUserContext.identity_state = "known"

AND NormalizedUserContext.effective_root = false

AND NormalizedUserContext.approved_administrator = false

AND (

ProcessPath STARTS_WITH ANY (

ENV_LINUX_TEMP_PATH_PREFIXES,

ENV_LINUX_SHARED_MEMORY_PATH_PREFIXES,

ENV_LINUX_USER_HOME_PATH_PREFIXES,

ENV_LINUX_APPLICATION_WORKSPACE_PATH_PREFIXES,

ENV_LINUX_CI_WORKSPACE_PATH_PREFIXES,

ENV_LINUX_BUILD_PATH_PREFIXES,

ENV_LINUX_RUNNER_PATH_PREFIXES,

ENV_LINUX_MOUNTED_VOLUME_PATH_PREFIXES,

ENV_LINUX_CONTAINER_WRITABLE_LAYER_PATH_PREFIXES

)

OR CurrentDirectory STARTS_WITH ANY (

ENV_LINUX_TEMP_PATH_PREFIXES,

ENV_LINUX_SHARED_MEMORY_PATH_PREFIXES,

ENV_LINUX_USER_HOME_PATH_PREFIXES,

ENV_LINUX_APPLICATION_WORKSPACE_PATH_PREFIXES,

ENV_LINUX_CI_WORKSPACE_PATH_PREFIXES,

ENV_LINUX_BUILD_PATH_PREFIXES,

ENV_LINUX_RUNNER_PATH_PREFIXES,

ENV_LINUX_MOUNTED_VOLUME_PATH_PREFIXES,

ENV_LINUX_CONTAINER_WRITABLE_LAYER_PATH_PREFIXES

)

)

AND (

ProcessName IN ENV_SHELL_INTERPRETERS

OR ProcessName IN ENV_SCRIPTING_INTERPRETERS

OR ProcessName IN ENV_COMPILERS

OR ProcessName IN ENV_LINKERS

OR ProcessName IN ENV_BUILD_TOOLS

OR ProcessPath MATCHES ANY ENV_UNFAMILIAR_LOCAL_EXECUTABLE_PATTERNS

OR CommandLine MATCHES ANY (

ENV_LINUX_COMPILATION_COMMAND_PATTERNS,

ENV_LINUX_LINKING_COMMAND_PATTERNS,

ENV_LINUX_TEMPORARY_EXECUTION_PATTERNS,

ENV_LINUX_LOCAL_PAYLOAD_EXECUTION_PATTERNS

)

)

LET WRITABLE_OR_TRANSIENT_DELETE =

FROM FileEvents

EVAL NormalizedDeletionPath =

NORMALIZE_LINUX_PATH(FilePath)

EVAL NormalizedDeletionUserContext =

NORMALIZE_USER_CONTEXT(

ProcessUser,

RealUser,

EffectiveUser,

ProcessUid,

EffectiveUid

)

WHERE MONITORED_LINUX_ENDPOINTS = true

AND EventType = "file_deleted"

AND FilePath STARTS_WITH ANY (

ENV_LINUX_TEMP_PATH_PREFIXES,

ENV_LINUX_SHARED_MEMORY_PATH_PREFIXES,

ENV_LINUX_USER_HOME_PATH_PREFIXES,

ENV_LINUX_APPLICATION_WORKSPACE_PATH_PREFIXES,

ENV_LINUX_CI_WORKSPACE_PATH_PREFIXES,

ENV_LINUX_BUILD_PATH_PREFIXES,

ENV_LINUX_RUNNER_PATH_PREFIXES,

ENV_LINUX_MOUNTED_VOLUME_PATH_PREFIXES,

ENV_LINUX_CONTAINER_WRITABLE_LAYER_PATH_PREFIXES

)

LET create_or_modify_to_execute_sequence =

SEQUENCE GENERAL_STAGED_FILE_EVENT AS file_event

THEN WRITABLE_OR_TRANSIENT_EXECUTION AS execution_event

BY EndpointId

WHERE (

file_event.NormalizedFilePath =

execution_event.NormalizedProcessPath

OR (

file_event.FileHash IS NOT NULL

AND execution_event.ProcessImageHash IS NOT NULL

AND file_event.FileHash =

execution_event.ProcessImageHash

)

OR (

file_event.FileIdentity IS NOT NULL

AND execution_event.ProcessFileIdentity IS NOT NULL

AND file_event.FileIdentity =

execution_event.ProcessFileIdentity

)

)

AND (

file_event.NormalizedUserContext =

execution_event.NormalizedUserContext

OR (

ENV_ALLOW_VALIDATED_CROSS_USER_EXECUTION = true

AND (

(

file_event.FileHash IS NOT NULL

AND execution_event.ProcessImageHash IS NOT NULL

AND file_event.FileHash =

execution_event.ProcessImageHash

)

OR (

file_event.FileIdentity IS NOT NULL

AND execution_event.ProcessFileIdentity IS NOT NULL

AND file_event.FileIdentity =

execution_event.ProcessFileIdentity

)

)

)

)

WITHIN ENV_MAXIMUM_FILE_CREATE_TO_EXECUTE_INTERVAL

LET permission_change_to_execute_sequence =

SEQUENCE PERMISSION_OR_OWNERSHIP_CHANGE_EVENT AS permission_event

THEN WRITABLE_OR_TRANSIENT_EXECUTION AS execution_event

BY EndpointId

WHERE (

permission_event.NormalizedFilePath =

execution_event.NormalizedProcessPath

OR (

permission_event.FileHash IS NOT NULL

AND execution_event.ProcessImageHash IS NOT NULL

AND permission_event.FileHash =

execution_event.ProcessImageHash

)

OR (

permission_event.FileIdentity IS NOT NULL

AND execution_event.ProcessFileIdentity IS NOT NULL

AND permission_event.FileIdentity =

execution_event.ProcessFileIdentity

)

)

AND (

permission_event.NormalizedUserContext =

execution_event.NormalizedUserContext

OR (

ENV_ALLOW_VALIDATED_CROSS_USER_EXECUTION = true

AND (

(

permission_event.FileHash IS NOT NULL

AND execution_event.ProcessImageHash IS NOT NULL

AND permission_event.FileHash =

execution_event.ProcessImageHash

)

OR (

permission_event.FileIdentity IS NOT NULL

AND execution_event.ProcessFileIdentity IS NOT NULL

AND permission_event.FileIdentity =

execution_event.ProcessFileIdentity

)

)

)

)

WITHIN ENV_MAXIMUM_PERMISSION_CHANGE_TO_EXECUTE_INTERVAL

LET create_execute_delete_sequence =

SEQUENCE GENERAL_STAGED_FILE_EVENT AS file_event

THEN WRITABLE_OR_TRANSIENT_EXECUTION AS execution_event

THEN WRITABLE_OR_TRANSIENT_DELETE AS deletion_event

BY EndpointId

WHERE (

(

file_event.NormalizedFilePath =

execution_event.NormalizedProcessPath

AND file_event.NormalizedFilePath =

deletion_event.NormalizedDeletionPath

)

OR (

file_event.FileHash IS NOT NULL

AND execution_event.ProcessImageHash IS NOT NULL

AND deletion_event.FileHash IS NOT NULL

AND file_event.FileHash =

execution_event.ProcessImageHash

AND file_event.FileHash =

deletion_event.FileHash

)

OR (

file_event.FileIdentity IS NOT NULL

AND execution_event.ProcessFileIdentity IS NOT NULL

AND deletion_event.FileIdentity IS NOT NULL

AND file_event.FileIdentity =

execution_event.ProcessFileIdentity

AND file_event.FileIdentity =

deletion_event.FileIdentity

)

)

AND (

(

file_event.NormalizedUserContext =

execution_event.NormalizedUserContext

AND execution_event.NormalizedUserContext =

deletion_event.NormalizedDeletionUserContext

)

OR (

ENV_ALLOW_VALIDATED_CROSS_USER_EXECUTION = true

AND (

(

file_event.FileHash IS NOT NULL

AND execution_event.ProcessImageHash IS NOT NULL

AND file_event.FileHash =

execution_event.ProcessImageHash

)

OR (

file_event.FileIdentity IS NOT NULL

AND execution_event.ProcessFileIdentity IS NOT NULL

AND file_event.FileIdentity =

execution_event.ProcessFileIdentity

)

)

)

)

WITHIN ENV_MAXIMUM_SHORT_LIVED_ARTIFACT_INTERVAL

LET normalized_create_or_modify_sequence =

create_or_modify_to_execute_sequence

EVAL SequenceType =

"create_or_modify_to_execute"

EVAL SourceFilePath =

file_event.FilePath

EVAL SourceNormalizedFilePath =

file_event.NormalizedFilePath

EVAL SourceFileName =

file_event.FileName

EVAL SourceFileExtension =

file_event.FileExtension

EVAL SourceFileType =

file_event.FileType

EVAL SourceFileHash =

file_event.FileHash

EVAL SourceFileIdentity =

file_event.FileIdentity

EVAL SourceFileEventType =

file_event.EventType

EVAL SourceFileEventTime =

file_event.EventTime

EVAL SourceUserContext =

file_event.NormalizedUserContext

EVAL ExecutionProcessId =

execution_event.ProcessId

EVAL ExecutionProcessName =

execution_event.ProcessName

EVAL ExecutionProcessPath =

execution_event.ProcessPath

EVAL ExecutionNormalizedProcessPath =

execution_event.NormalizedProcessPath

EVAL ExecutionProcessImageHash =

execution_event.ProcessImageHash

EVAL ExecutionProcessFileIdentity =

execution_event.ProcessFileIdentity

EVAL ExecutionParentProcessName =

execution_event.ParentProcessName

EVAL ExecutionParentProcessPath =

execution_event.ParentProcessPath

EVAL ExecutionCommandLine =

execution_event.CommandLine

EVAL ExecutionCurrentDirectory =

execution_event.CurrentDirectory

EVAL ExecutionEventTime =

execution_event.EventTime

EVAL DeletionEventPresent =

false

EVAL DeletionFilePath =

NULL

EVAL DeletionNormalizedPath =

NULL

EVAL DeletionEventTime =

NULL

EVAL TimeBetweenExecutionAndDeletion =

NULL

LET normalized_permission_sequence =

permission_change_to_execute_sequence

EVAL SequenceType =

"permission_or_ownership_change_to_execute"

EVAL SourceFilePath =

permission_event.FilePath

EVAL SourceNormalizedFilePath =

permission_event.NormalizedFilePath

EVAL SourceFileName =

permission_event.FileName

EVAL SourceFileExtension =

permission_event.FileExtension

EVAL SourceFileType =

permission_event.FileType

EVAL SourceFileHash =

permission_event.FileHash

EVAL SourceFileIdentity =

permission_event.FileIdentity

EVAL SourceFileEventType =

permission_event.EventType

EVAL SourceFileEventTime =

permission_event.EventTime

EVAL SourceUserContext =

permission_event.NormalizedUserContext

EVAL ExecutionProcessId =

execution_event.ProcessId

EVAL ExecutionProcessName =

execution_event.ProcessName

EVAL ExecutionProcessPath =

execution_event.ProcessPath

EVAL ExecutionNormalizedProcessPath =

execution_event.NormalizedProcessPath

EVAL ExecutionProcessImageHash =

execution_event.ProcessImageHash

EVAL ExecutionProcessFileIdentity =

execution_event.ProcessFileIdentity

EVAL ExecutionParentProcessName =

execution_event.ParentProcessName

EVAL ExecutionParentProcessPath =

execution_event.ParentProcessPath

EVAL ExecutionCommandLine =

execution_event.CommandLine

EVAL ExecutionCurrentDirectory =

execution_event.CurrentDirectory

EVAL ExecutionEventTime =

execution_event.EventTime

EVAL DeletionEventPresent =

false

EVAL DeletionFilePath =

NULL

EVAL DeletionNormalizedPath =

NULL

EVAL DeletionEventTime =

NULL

EVAL TimeBetweenExecutionAndDeletion =

NULL

LET normalized_short_lived_sequence =

create_execute_delete_sequence

EVAL SequenceType =

"create_execute_delete"

EVAL SourceFilePath =

file_event.FilePath

EVAL SourceNormalizedFilePath =

file_event.NormalizedFilePath

EVAL SourceFileName =

file_event.FileName

EVAL SourceFileExtension =

file_event.FileExtension

EVAL SourceFileType =

file_event.FileType

EVAL SourceFileHash =

file_event.FileHash

EVAL SourceFileIdentity =

file_event.FileIdentity

EVAL SourceFileEventType =

file_event.EventType

EVAL SourceFileEventTime =

file_event.EventTime

EVAL SourceUserContext =

file_event.NormalizedUserContext

EVAL ExecutionProcessId =

execution_event.ProcessId

EVAL ExecutionProcessName =

execution_event.ProcessName

EVAL ExecutionProcessPath =

execution_event.ProcessPath

EVAL ExecutionNormalizedProcessPath =

execution_event.NormalizedProcessPath

EVAL ExecutionProcessImageHash =

execution_event.ProcessImageHash

EVAL ExecutionProcessFileIdentity =

execution_event.ProcessFileIdentity

EVAL ExecutionParentProcessName =

execution_event.ParentProcessName

EVAL ExecutionParentProcessPath =

execution_event.ParentProcessPath

EVAL ExecutionCommandLine =

execution_event.CommandLine

EVAL ExecutionCurrentDirectory =

execution_event.CurrentDirectory

EVAL ExecutionEventTime =

execution_event.EventTime

EVAL DeletionEventPresent =

true

EVAL DeletionFilePath =

deletion_event.FilePath

EVAL DeletionNormalizedPath =

deletion_event.NormalizedDeletionPath

EVAL DeletionEventTime =

deletion_event.EventTime

LET combined_staging_sequences =

FROM normalized_create_or_modify_sequence

OR normalized_permission_sequence

OR normalized_short_lived_sequence

OUTPUT combined_staging_sequences

EndpointName,

EndpointId,

EndpointTags,

StorylineId,

SequenceType,

SourceUserContext,

SourceFilePath,

SourceNormalizedFilePath,

SourceFileName,

SourceFileExtension,

SourceFileType,

SourceFileHash,

SourceFileIdentity,

SourceFileEventType,

SourceFileEventTime,

ExecutionProcessId,

ExecutionProcessName,

ExecutionProcessPath,

ExecutionNormalizedProcessPath,

ExecutionProcessImageHash,

ExecutionProcessFileIdentity,

ExecutionParentProcessName,

ExecutionParentProcessPath,

ExecutionCommandLine,

ExecutionCurrentDirectory,

ExecutionEventTime,

DeletionEventPresent,

DeletionFilePath,

DeletionNormalizedPath,

DeletionEventTime,

SequenceStartTime,

SequenceEndTime,

TimeBetweenFileAndExecution,

TimeBetweenExecutionAndDeletion

Rule

Abnormal Low-Privilege-to-Root Process Transition

Rule Format

SentinelOne Deep Visibility or STAR sequence pattern using Linux process telemetry, Storyline or process-tree correlation, normalized user context, UID and effective-UID fields, parent-process context, approved privilege-management exceptions, and bounded-time correlation.

Detection Purpose

Detect a suspicious non-root or constrained process chain that results in a root-owned shell, interpreter, privileged utility, service process, or unfamiliar executable without an approved sudo, privilege-management, package-management, orchestration, deployment, or administrative transition.

This rule targets the durable privilege-boundary outcome rather than a particular Linux kernel vulnerability, exploit primitive, proof-of-concept implementation, or privileged binary.

Detection Logic

·        Normalize user, real-user, effective-user, UID, and effective-UID fields independently for source and root events.

·        Require affirmative evidence that the source process is non-root.

·        Require affirmative evidence that the resulting process is effective root.

·        Keep source-event selection and root-event selection independent.

·        Evaluate direct parent-child, non-null Storyline, process-tree, executable, working-directory, and time relationships inside the sequence correlation.

·        Apply approved-transition exceptions as an explicit Boolean evaluation on the completed sequence.

·        Scope every exception field to either the source event or the root event.

·        Prioritize root shells, scripting engines, unfamiliar executables, privileged utilities, or service processes reached from suspicious non-root activity.

·        Do not alert when source identity, root identity, or process relationship evidence is unknown.

Required Telemetry

·        SentinelOne Linux process creation telemetry.

·        Process identifiers and parent-process identifiers.

·        Storyline or process-tree context.

·        Source and root process user, real-user, effective-user, UID, and effective UID.

·        Process path, parent path, command line, and working directory.

·        Endpoint identifier, endpoint tags, workload role, and business criticality.

·        Approved privilege-management users, tools, commands, workflows, and maintenance windows.

·        Optional file, SUID, namespace, mount, authentication, container, and security-agent telemetry.

Engineering Implementation Instructions

·        Normalize source and root identities separately.

·        Require known, affirmative non-root evidence for the source event.

·        Require known, affirmative effective-root evidence for the outcome event.

·        Do not classify missing or contradictory identity data as non-root or root.

·        Keep all cross-event relationships inside the sequence join.

·        Require both Storyline identifiers to be present before treating equality as a valid relationship.

·        Scope approved exceptions to source-user, root-user, source process, root process, source command, root command, and sequence time.

·        Evaluate approved-transition status on the completed sequence.

·        Prefer Storyline, direct parent-child, or process-tree relationships over time-only correlation.

·        Where direct ancestry is unavailable, require the same endpoint, a short interval, and additional executable, working-directory, or privilege-interaction context.

·        Tune container hosts and Kubernetes nodes separately.

·        Deploy in hunt mode until identity and process-lineage fidelity are validated.

DRI Assessment

This is the strongest SentinelOne rule for the report because it detects the core operational result of successful local privilege escalation. It is highly resilient to changes in CVE, exploit code, staging path, kernel subsystem, and privileged utility when identity and process-lineage telemetry are reliable.

DRI

9.1

TCR Assessment

Operational confidence depends heavily on normalized source and root identity, UID and effective-UID fidelity, and process-lineage integrity. Full-telemetry confidence increases with staging, privileged-binary interaction, vulnerable-state, authentication, container, Kubernetes, and subsequent root-activity evidence.

Operational TCR

8.6

Full-Telemetry TCR

9.4

Limitations

·        Some SentinelOne Linux deployments may not expose all user-transition fields consistently.

·        Service managers, schedulers, package managers, container runtimes, orchestration systems, and administrative tools legitimately create root-owned processes.

·        Process ancestry can be lost across service managers, namespaces, containers, short-lived processes, or telemetry gaps.

·        Attackers may inject into an existing root process without creating a new process.

·        Environments without reliable source-user, effective-user, and process-lineage context should not deploy the rule as a high-confidence alert.

Detection Query Pattern

Use this pattern as an implementation guide for SentinelOne Deep Visibility or STAR logic that supports Linux process telemetry, Storyline or process-tree correlation, normalized user fields, UID and effective-UID fields, endpoint tags, path mapping, approved privilege-management exceptions, explicitly scoped sequence fields, and bounded-time sequence logic.

LET MONITORED_LINUX_ENDPOINTS =

EndpointTags CONTAINS ANY (

"ENV_INTERNET_FACING_LINUX_WORKLOADS",

"ENV_CLOUD_LINUX_INSTANCES",

"ENV_KUBERNETES_WORKER_NODES",

"ENV_CONTAINER_HOSTS",

"ENV_CI_RUNNERS",

"ENV_BUILD_SYSTEMS",

"ENV_PRIVILEGED_AUTOMATION_HOSTS",

"ENV_PRODUCTION_LINUX_SERVERS",

"ENV_HIGH_VALUE_OPERATIONAL_LINUX_ASSETS"

)

LET LOW_PRIVILEGE_SOURCE_PROCESS =

FROM ProcessEvents

EVAL SourceIdentity =

NORMALIZE_USER_CONTEXT(

ProcessUser,

RealUser,

EffectiveUser,

ProcessUid,

EffectiveUid

)

WHERE EventType = "process_creation"

AND MONITORED_LINUX_ENDPOINTS = true

AND SourceIdentity.identity_state = "known"

AND SourceIdentity.effective_root = false

AND SourceIdentity.approved_administrator = false

AND (

ProcessPath STARTS_WITH ANY (

ENV_LINUX_TEMP_PATH_PREFIXES,

ENV_LINUX_SHARED_MEMORY_PATH_PREFIXES,

ENV_LINUX_USER_HOME_PATH_PREFIXES,

ENV_LINUX_APPLICATION_WORKSPACE_PATH_PREFIXES,

ENV_LINUX_CI_WORKSPACE_PATH_PREFIXES,

ENV_LINUX_BUILD_PATH_PREFIXES,

ENV_LINUX_RUNNER_PATH_PREFIXES,

ENV_LINUX_MOUNTED_VOLUME_PATH_PREFIXES,

ENV_LINUX_CONTAINER_WRITABLE_LAYER_PATH_PREFIXES

)

OR CurrentDirectory STARTS_WITH ANY (

ENV_LINUX_TEMP_PATH_PREFIXES,

ENV_LINUX_SHARED_MEMORY_PATH_PREFIXES,

ENV_LINUX_USER_HOME_PATH_PREFIXES,

ENV_LINUX_APPLICATION_WORKSPACE_PATH_PREFIXES,

ENV_LINUX_CI_WORKSPACE_PATH_PREFIXES,

ENV_LINUX_BUILD_PATH_PREFIXES,

ENV_LINUX_RUNNER_PATH_PREFIXES,

ENV_LINUX_MOUNTED_VOLUME_PATH_PREFIXES,

ENV_LINUX_CONTAINER_WRITABLE_LAYER_PATH_PREFIXES

)

OR ProcessName IN ENV_SHELL_INTERPRETERS

OR ProcessName IN ENV_SCRIPTING_INTERPRETERS

OR ProcessName IN ENV_COMPILERS

OR ProcessName IN ENV_BUILD_TOOLS

OR ProcessName IN ENV_PERMISSION_MODIFICATION_TOOLS

OR CommandLine MATCHES ANY ENV_SUSPICIOUS_LOCAL_EXECUTION_PATTERNS

OR ParentProcessName IN ENV_APPLICATION_SERVICE_PROCESSES

OR ParentProcessName IN ENV_WEB_SERVICE_PROCESSES

OR ParentProcessName IN ENV_CONTAINER_OR_CI_PROCESSES

)

LET ROOT_OUTCOME_PROCESS =

FROM ProcessEvents

EVAL RootIdentity =

NORMALIZE_USER_CONTEXT(

ProcessUser,

RealUser,

EffectiveUser,

ProcessUid,

EffectiveUid

)

WHERE EventType = "process_creation"

AND MONITORED_LINUX_ENDPOINTS = true

AND RootIdentity.identity_state = "known"

AND RootIdentity.effective_root = true

AND (

ProcessName IN ENV_SHELL_INTERPRETERS

OR ProcessName IN ENV_SCRIPTING_INTERPRETERS

OR ProcessName IN ENV_PRIVILEGED_UTILITIES

OR ProcessName IN ENV_SERVICE_MANAGEMENT_TOOLS

OR ProcessPath MATCHES ANY ENV_UNFAMILIAR_ROOT_EXECUTABLE_PATTERNS

OR CommandLine MATCHES ANY ENV_SUSPICIOUS_ROOT_COMMAND_PATTERNS

)

LET abnormal_low_to_root_sequence =

SEQUENCE LOW_PRIVILEGE_SOURCE_PROCESS AS source_event

THEN ROOT_OUTCOME_PROCESS AS root_event

BY EndpointId

WHERE (

(

source_event.StorylineId IS NOT NULL

AND root_event.StorylineId IS NOT NULL

AND source_event.StorylineId =

root_event.StorylineId

)

OR (

root_event.ParentProcessId IS NOT NULL

AND source_event.ProcessId IS NOT NULL

AND root_event.ParentProcessId =

source_event.ProcessId

)

OR SameSourceProcessTree(

source_event,

root_event

) = true

OR (

SameEndpoint(

source_event,

root_event

) = true

AND SameExecutableOrWorkingDirectoryContext(

source_event,

root_event

) = true

AND TimeBetween(

source_event.EventTime,

root_event.EventTime

) <= ENV_MAXIMUM_LOW_TO_ROOT_TRANSITION_INTERVAL

)

)

WITHIN ENV_MAXIMUM_LOW_TO_ROOT_TRANSITION_INTERVAL

LET evaluated_low_to_root_sequence =

abnormal_low_to_root_sequence

EVAL approved_transition =

(

source_event.ProcessUser IN ENV_APPROVED_LINUX_ADMIN_USERS

OR source_event.RealUser IN ENV_APPROVED_LINUX_ADMIN_USERS

OR source_event.ProcessName IN ENV_APPROVED_PRIVILEGE_MANAGEMENT_TOOLS

OR root_event.ProcessUser IN ENV_APPROVED_LINUX_ADMIN_USERS

OR root_event.RealUser IN ENV_APPROVED_LINUX_ADMIN_USERS

OR root_event.ParentProcessName IN ENV_APPROVED_PRIVILEGE_MANAGEMENT_TOOLS

OR root_event.ParentProcessName IN ENV_APPROVED_PACKAGE_MANAGERS

OR root_event.ParentProcessName IN ENV_APPROVED_CONFIGURATION_MANAGEMENT_TOOLS

OR root_event.ParentProcessName IN ENV_APPROVED_ORCHESTRATION_TOOLS

OR root_event.ParentProcessName IN ENV_APPROVED_DEPLOYMENT_TOOLS

OR root_event.ParentProcessName IN ENV_APPROVED_BACKUP_TOOLS

OR root_event.ParentProcessName IN ENV_APPROVED_INCIDENT_RESPONSE_TOOLS

OR source_event.CommandLine MATCHES ANY ENV_APPROVED_SUDO_COMMAND_PATTERNS

OR source_event.CommandLine MATCHES ANY ENV_APPROVED_PRIVILEGE_TRANSITION_PATTERNS

OR root_event.CommandLine MATCHES ANY ENV_APPROVED_PRIVILEGE_TRANSITION_PATTERNS

OR root_event.CommandLine MATCHES ANY ENV_APPROVED_PACKAGE_MANAGEMENT_PATTERNS

OR root_event.CommandLine MATCHES ANY ENV_APPROVED_DEPLOYMENT_COMMAND_PATTERNS

OR source_event.EventTime IN ENV_APPROVED_MAINTENANCE_WINDOWS

OR root_event.EventTime IN ENV_APPROVED_MAINTENANCE_WINDOWS

OR root_event.EventTime IN ENV_APPROVED_PATCH_WINDOWS

OR root_event.EventTime IN ENV_APPROVED_DEPLOYMENT_WINDOWS

OR root_event.EventTime IN ENV_APPROVED_INCIDENT_RESPONSE_WINDOWS

OR root_event.EventTime IN ENV_APPROVED_RED_TEAM_WINDOWS

)

FROM evaluated_low_to_root_sequence

WHERE approved_transition != true

OUTPUT

EndpointName,

EndpointId,

EndpointTags,

SequenceId,

approved_transition,

source_event.StorylineId,

source_event.ProcessId,

source_event.ProcessUser,

source_event.RealUser,

source_event.EffectiveUser,

source_event.ProcessUid,

source_event.EffectiveUid,

source_event.ProcessName,

source_event.ProcessPath,

source_event.ParentProcessName,

source_event.CommandLine,

source_event.CurrentDirectory,

source_event.EventTime,

root_event.StorylineId,

root_event.ProcessId,

root_event.ProcessUser,

root_event.RealUser,

root_event.EffectiveUser,

root_event.ProcessUid,

root_event.EffectiveUid,

root_event.ProcessName,

root_event.ProcessPath,

root_event.ParentProcessId,

root_event.ParentProcessName,

root_event.ParentProcessUser,

root_event.CommandLine,

root_event.CurrentDirectory,

root_event.EventTime,

SequenceRelationshipType,

SequenceStartTime,

SequenceEndTime,

TimeBetweenProcesses

Rule

Suspicious Root-Level Sensitive Resource Access or Security-Control Modification

Rule Format

SentinelOne Deep Visibility or STAR endpoint-correlation pattern using confirmed root context, Linux process telemetry, file telemetry, sensitive-path mapping, persistence-path mapping, security-agent telemetry, command-line telemetry, approved administrative exceptions, and optional network enrichment.

Detection Purpose

Detect suspicious root-level access to credentials, SSH material, service secrets, workload identities, Kubernetes tokens, kubelet resources, container runtime sockets, cloud credentials, CI/CD credentials, repository credentials, signing material, persistence locations, audit controls, logging controls, or security-agent resources.

The rule identifies high-risk activity performed by a confirmed effective-root process or, for selected agent-health events, a telemetry event that directly confirms security-control degradation when actor attribution is unavailable.

Detection Logic

·        Require confirmed effective-root context for sensitive-file, persistence, audit, logging, and configuration activity.

·        Prioritize credential stores, SSH material, cloud credentials, workload identities, Kubernetes tokens, runtime sockets, CI/CD material, repository credentials, and signing keys.

·        Detect root-level creation, writing, modification, copying, archiving, deletion, permission changes, or ownership changes affecting persistence or security-control paths.

·        Prioritize suspicious root processes originating from writable paths, unfamiliar executables, scripting engines, application-service parents, container processes, CI jobs, or abnormal parentage.

·        Allow selected agent-health events to alert without actor root fields only when the event directly confirms that a protected agent or telemetry service was stopped, disabled, or reconfigured.

·        Do not allow non-root sensitive-resource activity to satisfy the primary rule.

·        Exclude approved administration, backup, monitoring, certificate management, secret rotation, package management, deployment, incident response, security operations, and maintenance activity.

·        Describe the observed behavior precisely and do not infer credential theft or persistence beyond the event evidence.

Required Telemetry

·        SentinelOne Linux process telemetry.

·        Normalized root identity.

·        File open, read, create, write, modify, copy, rename, archive, delete, permission, and ownership events where available.

·        Sensitive-resource, persistence, audit, logging, security-agent, cloud-agent, Kubernetes, container, CI/CD, repository, and signing-material path mappings.

·        Security-agent and telemetry health events.

·        Process ancestry or Storyline context.

·        Approved users, tools, paths, workflows, and maintenance windows.

·        Optional network connection telemetry.

Engineering Implementation Instructions

·        Normalize effective-user and UID fields before establishing root context.

·        Require known effective-root identity for all process-attributed file and configuration activity.

·        Do not treat missing identity data as root.

·        Separate confirmed root-attributed activity from agent-health events that may lack actor attribution.

·        Limit unattributed agent-health alerts to events that directly confirm security-control degradation.

·        Distinguish confirmed file reads from command-line references to file paths.

·        Maintain sensitive-resource and persistence or security-control path sets separately.

·        Increase priority when root activity originates from writable paths, unfamiliar binaries, application services, containers, CI jobs, or suspicious Storylines.

·        Maintain approved workflow exceptions.

·        Deploy in hunt mode until root identity, file-event fidelity, path coverage, and administrative exceptions are validated.

DRI Assessment

The rule detects durable post-root objectives across multiple privilege-escalation families. It provides strong investigative and response value but is not unique to local privilege escalation and therefore depends on confirmed root context, resource classification, process lineage, and administrative tuning.

DRI

8.8

TCR Assessment

Operational confidence depends on normalized root identity, file-event fidelity, process lineage, sensitive-path mapping, and approved workflow exceptions. Full-telemetry confidence increases with privilege-transition, staging, security-agent health, container, Kubernetes, and network evidence.

Operational TCR

8.4

Full-Telemetry TCR

9.2

Limitations

·        Linux file-read visibility may vary by SentinelOne agent version and policy.

·        Backup, monitoring, configuration management, certificate rotation, secret management, deployment, and incident response may generate similar activity.

·        Command-line references to sensitive paths do not prove that a file was accessed.

·        Root-owned services may legitimately access credentials, sockets, tokens, configuration, and security controls.

·        Actor attribution may be unavailable for some agent-health events.

·        The rule does not prove that root access resulted from local privilege escalation.

Detection Query Pattern

Use this pattern as an implementation guide for SentinelOne Deep Visibility or STAR logic that supports Linux endpoint tags, normalized root identity, process telemetry, parent-process telemetry, Storyline context, file telemetry, sensitive-path mapping, persistence-path mapping, security-control telemetry, approved workflow exceptions, and optional network enrichment.

LET MONITORED_LINUX_ENDPOINTS =

EndpointTags CONTAINS ANY (

"ENV_INTERNET_FACING_LINUX_WORKLOADS",

"ENV_CLOUD_LINUX_INSTANCES",

"ENV_KUBERNETES_WORKER_NODES",

"ENV_CONTAINER_HOSTS",

"ENV_CI_RUNNERS",

"ENV_BUILD_SYSTEMS",

"ENV_PRIVILEGED_AUTOMATION_HOSTS",

"ENV_IDENTITY_ADJACENT_LINUX_SYSTEMS",

"ENV_PRODUCTION_LINUX_SERVERS",

"ENV_HIGH_VALUE_OPERATIONAL_LINUX_ASSETS"

)

LET LINUX_SENSITIVE_RESOURCE_PATHS =

FilePath STARTS_WITH ANY (

ENV_LINUX_CREDENTIAL_STORE_PATH_PREFIXES,

ENV_LINUX_SSH_MATERIAL_PATH_PREFIXES,

ENV_LINUX_SERVICE_SECRET_PATH_PREFIXES,

ENV_LINUX_APPLICATION_SECRET_PATH_PREFIXES,

ENV_LINUX_CLOUD_CREDENTIAL_PATH_PREFIXES,

ENV_LINUX_WORKLOAD_IDENTITY_PATH_PREFIXES,

ENV_KUBERNETES_SERVICE_ACCOUNT_TOKEN_PATH_PREFIXES,

ENV_KUBELET_RESOURCE_PATH_PREFIXES,

ENV_CONTAINER_RUNTIME_SOCKET_PATH_PREFIXES,

ENV_HOST_MOUNTED_SECRET_PATH_PREFIXES,

ENV_CI_CD_CREDENTIAL_PATH_PREFIXES,

ENV_REPOSITORY_CREDENTIAL_PATH_PREFIXES,

ENV_SIGNING_MATERIAL_PATH_PREFIXES

)

LET LINUX_PERSISTENCE_OR_CONTROL_PATHS =

FilePath STARTS_WITH ANY (

ENV_CRON_PATH_PREFIXES,

ENV_SYSTEMD_PATH_PREFIXES,

ENV_INIT_SCRIPT_PATH_PREFIXES,

ENV_SHELL_PROFILE_PATH_PREFIXES,

ENV_SSH_AUTHORIZED_KEY_PATH_PREFIXES,

ENV_SUDOERS_PATH_PREFIXES,

ENV_USER_AND_GROUP_CONFIGURATION_PATH_PREFIXES,

ENV_AUTHENTICATION_CONFIGURATION_PATH_PREFIXES,

ENV_AUDIT_CONFIGURATION_PATH_PREFIXES,

ENV_LOGGING_CONFIGURATION_PATH_PREFIXES,

ENV_SECURITY_AGENT_PATH_PREFIXES,

ENV_TELEMETRY_FORWARDER_PATH_PREFIXES,

ENV_CLOUD_AGENT_PATH_PREFIXES,

ENV_WORKLOAD_PROTECTION_AGENT_PATH_PREFIXES

)

LET ROOT_ATTRIBUTED_SENSITIVE_RESOURCE_ACTIVITY =

FROM FileEvents OR ProcessEvents

EVAL NormalizedRootContext =

NORMALIZE_USER_CONTEXT(

ProcessUser,

RealUser,

EffectiveUser,

ProcessUid,

EffectiveUid

)

WHERE MONITORED_LINUX_ENDPOINTS = true

AND NormalizedRootContext.identity_state = "known"

AND NormalizedRootContext.effective_root = true

AND (

LINUX_SENSITIVE_RESOURCE_PATHS = true

OR LINUX_PERSISTENCE_OR_CONTROL_PATHS = true

)

AND EventType IN (

"file_opened",

"file_read",

"file_created",

"file_written",

"file_modified",

"file_copied",

"file_renamed",

"file_archived",

"file_deleted",

"permission_modified",

"ownership_modified"

)

AND (

ProcessPath STARTS_WITH ANY (

ENV_LINUX_TEMP_PATH_PREFIXES,

ENV_LINUX_SHARED_MEMORY_PATH_PREFIXES,

ENV_LINUX_USER_HOME_PATH_PREFIXES,

ENV_LINUX_APPLICATION_WORKSPACE_PATH_PREFIXES,

ENV_LINUX_CI_WORKSPACE_PATH_PREFIXES,

ENV_LINUX_BUILD_PATH_PREFIXES,

ENV_LINUX_CONTAINER_WRITABLE_LAYER_PATH_PREFIXES

)

OR ProcessName IN ENV_SHELL_INTERPRETERS

OR ProcessName IN ENV_SCRIPTING_INTERPRETERS

OR ProcessName IN ENV_ARCHIVE_TOOLS

OR ProcessName IN ENV_TRANSFER_TOOLS

OR ProcessName IN ENV_CREDENTIAL_ACCESS_TOOLS

OR ProcessName IN ENV_SECURITY_CONTROL_MANIPULATION_TOOLS

OR ProcessPath MATCHES ANY ENV_UNFAMILIAR_ROOT_EXECUTABLE_PATTERNS

OR ParentProcessName IN ENV_APPLICATION_SERVICE_PROCESSES

OR ParentProcessName IN ENV_WEB_SERVICE_PROCESSES

OR ParentProcessName IN ENV_CONTAINER_OR_CI_PROCESSES

OR ParentEffectiveUid != 0

OR ParentEffectiveUser != "root"

OR CommandLine MATCHES ANY (

ENV_LINUX_CREDENTIAL_ACCESS_COMMAND_PATTERNS,

ENV_LINUX_SECRET_ACCESS_COMMAND_PATTERNS,

ENV_LINUX_PERSISTENCE_COMMAND_PATTERNS,

ENV_LINUX_AUDIT_MODIFICATION_PATTERNS,

ENV_LINUX_LOGGING_MODIFICATION_PATTERNS,

ENV_LINUX_SECURITY_CONTROL_MODIFICATION_PATTERNS,

ENV_LINUX_ARCHIVE_OR_EXFILTRATION_PATTERNS

)

OR (

LINUX_SENSITIVE_RESOURCE_PATHS = true

AND EventType IN (

"file_read",

"file_copied",

"file_archived",

"permission_modified",

"ownership_modified"

)

)

OR (

LINUX_PERSISTENCE_OR_CONTROL_PATHS = true

AND EventType IN (

"file_created",

"file_written",

"file_modified",

"file_deleted",

"permission_modified",

"ownership_modified"

)

)

)

LET CONFIRMED_SECURITY_CONTROL_DEGRADATION =

FROM AgentEvents

WHERE MONITORED_LINUX_ENDPOINTS = true

AND EventType IN (

"agent_stopped",

"agent_disabled",

"service_stopped",

"service_disabled",

"configuration_modified",

"log_deleted",

"audit_policy_modified",

"telemetry_forwarding_modified"

)

AND (

TargetProcessName IN ENV_SECURITY_AGENT_PROCESSES

OR TargetServiceName IN ENV_SECURITY_MONITORING_SERVICES

OR FilePath STARTS_WITH ANY (

ENV_SECURITY_AGENT_PATH_PREFIXES,

ENV_AUDIT_CONFIGURATION_PATH_PREFIXES,

ENV_LOGGING_CONFIGURATION_PATH_PREFIXES,

ENV_TELEMETRY_FORWARDER_PATH_PREFIXES

)

)

AND EventOutcome IN (

"confirmed",

"successful",

"state_changed"

)

LET combined_root_or_control_activity =

FROM ROOT_ATTRIBUTED_SENSITIVE_RESOURCE_ACTIVITY

OR CONFIRMED_SECURITY_CONTROL_DEGRADATION

LET evaluated_root_or_control_activity =

combined_root_or_control_activity

EVAL approved_root_resource_activity =

(

ProcessUser IN ENV_APPROVED_LINUX_ADMIN_USERS

OR RealUser IN ENV_APPROVED_LINUX_ADMIN_USERS

OR ProcessUser IN ENV_APPROVED_BACKUP_USERS

OR ProcessUser IN ENV_APPROVED_SECURITY_USERS

OR ProcessUser IN ENV_APPROVED_SECRET_MANAGEMENT_USERS

OR ProcessUser IN ENV_APPROVED_CERTIFICATE_MANAGEMENT_USERS

OR ProcessName IN ENV_APPROVED_BACKUP_TOOLS

OR ProcessName IN ENV_APPROVED_CONFIGURATION_MANAGEMENT_TOOLS

OR ProcessName IN ENV_APPROVED_SECRET_MANAGEMENT_TOOLS

OR ProcessName IN ENV_APPROVED_CERTIFICATE_MANAGEMENT_TOOLS

OR ProcessName IN ENV_APPROVED_MONITORING_TOOLS

OR ProcessName IN ENV_APPROVED_SECURITY_TOOLS

OR ProcessName IN ENV_APPROVED_PACKAGE_MANAGERS

OR ProcessName IN ENV_APPROVED_DEPLOYMENT_TOOLS

OR CommandLine MATCHES ANY ENV_APPROVED_BACKUP_COMMAND_PATTERNS

OR CommandLine MATCHES ANY ENV_APPROVED_SECRET_ROTATION_PATTERNS

OR CommandLine MATCHES ANY ENV_APPROVED_CERTIFICATE_COMMAND_PATTERNS

OR CommandLine MATCHES ANY ENV_APPROVED_CONFIGURATION_COMMAND_PATTERNS

OR EventTime IN ENV_APPROVED_BACKUP_WINDOWS

OR EventTime IN ENV_APPROVED_SECRET_ROTATION_WINDOWS

OR EventTime IN ENV_APPROVED_CERTIFICATE_ROTATION_WINDOWS

OR EventTime IN ENV_APPROVED_MAINTENANCE_WINDOWS

OR EventTime IN ENV_APPROVED_DEPLOYMENT_WINDOWS

OR EventTime IN ENV_APPROVED_INCIDENT_RESPONSE_WINDOWS

OR EventTime IN ENV_APPROVED_RED_TEAM_WINDOWS

)

FROM evaluated_root_or_control_activity

WHERE approved_root_resource_activity != true

OUTPUT

EndpointName,

EndpointId,

EndpointTags,

StorylineId,

EventSourceType,

approved_root_resource_activity,

UserName,

ProcessUser,

RealUser,

EffectiveUser,

ProcessUid,

EffectiveUid,

NormalizedRootContext,

ProcessName,

ProcessPath,

ParentProcessName,

ParentProcessPath,

ParentProcessUser,

ParentEffectiveUser,

CommandLine,

CurrentDirectory,

FilePath,

FileName,

FileExtension,

FileHash,

EventType,

EventOutcome,

EventTime,

TargetProcessName,

TargetServiceName,

DestinationHost,

DestinationIp,

DestinationPort,

DestinationDomain,

DestinationFirstSeenStatus,

DestinationReputation,

NetworkAction

Splunk

Detection Viability Assessment

Splunk can provide strong behavior-driven coverage for Linux foothold-to-root activity when process, file, audit, identity, workload, cloud, Kubernetes, container, and security-control telemetry are normalized into consistent host, user, process, path, event-time, and workload fields.

Three rule opportunities survive validation:

·        Suspicious Linux execution from writable or transient paths.

·        Suspicious root process from non-administrative or writable-path parent context.

·        Suspicious root-level sensitive-resource access or security-control modification.

Each rule remains independently evaluable. Vulnerability state, preceding staging, cloud context, Kubernetes context, container-host context, and subsequent activity may increase confidence but are not required for the primary behavior to alert. No rule depends on another CyberDax rule firing first.

Rule

Suspicious Linux Execution From Writable or Transient Paths

Rule Format

Splunk behavioral search pattern using normalized Linux process telemetry, affirmative non-root identity, writable-path classification, suspicious process-context mapping, workload enrichment, and approved workflow exceptions.

Detection Purpose

Detect suspicious execution of scripts, interpreters, compilers, linkers, build tools, permission-modification tools, or unfamiliar executables from writable, transient, user-controlled, build, workspace, mounted, or container-layer paths.

The rule identifies behavior consistent with exploit staging or suspicious local execution by a constrained user, service account, application account, CI runner, container process, or other non-administrative context. It does not claim that privilege escalation succeeded.

Detection Logic

·        Normalize host, operating system, process, parent-process, command-line, working-directory, user, UID, and workload fields.

·        Scope the rule to Linux systems with validated process telemetry.

·        Require affirmative known non-root effective identity.

·        Identify process execution from temporary, shared-memory, home-directory, workspace, build, runner, mounted-volume, or container-writable paths.

·        Prioritize shells, scripting interpreters, compilers, linkers, build tools, permission-modification tools, and unfamiliar local executables.

·        Require an environment-maintained suspicious-process classification rather than relying only on writable-path presence.

·        Exclude approved package-management, build, CI/CD, deployment, orchestration, configuration-management, vulnerability-validation, incident-response, and administrative activity.

·        Increase severity for internet-facing systems, critical production workloads, Kubernetes nodes, container hosts, CI runners, privileged automation hosts, and high-value Linux assets.

·        Treat vulnerability state, exploit names, CVE identifiers, filenames, hashes, and proof-of-concept strings as optional enrichment only.

Required Telemetry

·        Linux process creation or execution telemetry.

·        Process name, executable path, command line, parent process, and working directory.

·        Effective user and effective UID.

·        Process user, real user, and process UID where available for investigation.

·        Hostname, endpoint identifier, operating system, and workload role.

·        Cloud, Kubernetes, container-host, CI-runner, and build-system context where available.

·        Asset criticality and exposure classification.

·        Approved user, process, path, command, workflow, and maintenance exceptions.

Engineering Implementation Instructions

·        Validate indexes, sourcetypes, CIM mappings, field aliases, macro expansion, lookup names, and wildcard lookup configuration before deployment.

·        Normalize Linux paths and effective identity before filtering.

·        Require a populated effective-user or effective-UID field before classifying an event as non-root.

·        Maintain separate writable-path and suspicious-process-context lookups.

·        Configure path and command-pattern lookup fields for wildcard matching where pattern matching is required.

·        Include interpreter, compiler, linker, build-tool, permission-tool, executable-pattern, and command-pattern classifications in the suspicious-process-context lookup.

·        Tune developer systems, CI runners, build systems, container hosts, package managers, and deployment platforms separately.

·        Normalize every lookup miss to an explicit false value before filtering.

·        Use role-aware severity rather than making vulnerable-state enrichment mandatory.

·        Deploy in hunt mode before enabling production alerting.

·        Present the event as suspicious writable-path execution or exploit staging.

DRI Assessment

The rule detects durable exploit-staging behavior rather than exploit-specific artifacts. It remains useful across multiple Linux privilege-escalation families, but writable-path execution is not unique to exploitation and requires workload-aware classification and tuning.

DRI

8.4

TCR Assessment

Operational confidence depends on process telemetry quality, effective-identity normalization, path fidelity, suspicious-process classification, approved workflow exceptions, and workload enrichment. Full-telemetry confidence improves with file activity, process lineage, vulnerable-state context, container or Kubernetes context, and subsequent privilege-boundary activity.

Operational TCR

8.1

Full-Telemetry TCR

8.8

Limitations

·        CI runners, development systems, build servers, package managers, deployment tools, and administrative automation may generate similar behavior.

·        Effective-user or effective-UID visibility may be incomplete.

·        Existing trusted binaries can be abused without executing from writable paths.

·        In-memory execution may not expose a persistent executable path.

·        Incorrect path or process classifications may reduce fidelity.

·        The rule does not prove successful privilege escalation.

Detection Query Pattern

Use this pattern as an implementation guide for Splunk environments that support normalized Linux process telemetry, affirmative effective identity, workload enrichment, writable-path classification, suspicious-process-context mapping, approved workflow exceptions, and role-aware severity. Customer-specific macros and lookups must expand into valid SPL and must be validated before deployment.

`linux_process_events`

| eval normalized_time=coalesce(_time,event_time,EventTime,timestamp)

| eval normalized_host=coalesce(hostname,host,dest,dvc,device_name)

| eval normalized_endpoint=coalesce(endpoint_id,agent_id,device_id,host_id,cloud_instance_id,kubernetes_node_id,container_host_id,ci_runner_id,normalized_host)

| eval normalized_os=lower(coalesce(os,host_os,operating_system,platform))

| eval normalized_process_name=lower(coalesce(process_name,process,ImageName,exe_name))

| eval normalized_process_path=lower(coalesce(process_path,process_exec,Image,exe))

| eval normalized_parent_process_name=lower(coalesce(parent_process_name,parent_process,ParentImageName,parent_name))

| eval normalized_parent_process_path=lower(coalesce(parent_process_path,ParentImage,parent_exec))

| eval normalized_command_line=lower(coalesce(process_command_line,command_line,CommandLine,cmdline))

| eval normalized_current_directory=lower(coalesce(current_directory,working_directory,cwd))

| eval normalized_process_user=lower(coalesce(process_user,user,UserName))

| eval normalized_real_user=lower(coalesce(real_user,src_user,login_user))

| eval normalized_effective_user=lower(coalesce(effective_user,dest_user,euser))

| eval normalized_process_uid=tostring(coalesce(process_uid,uid))

| eval normalized_effective_uid=tostring(coalesce(effective_uid,euid))

| lookup ENV_LINUX_MONITORED_ASSETS normalized_endpoint OUTPUT linux_asset_match asset_role workload_type exposure_class asset_criticality

| lookup ENV_LINUX_WRITABLE_PATHS normalized_process_path OUTPUT writable_process_path process_path_family

| lookup ENV_LINUX_WRITABLE_PATHS normalized_current_directory OUTPUT writable_working_directory working_directory_family

| lookup ENV_LINUX_SUSPICIOUS_PROCESS_CONTEXT normalized_process_name normalized_process_path normalized_command_line OUTPUT suspicious_process_context process_context_family

| lookup ENV_APPROVED_LINUX_STAGING_ACTIVITY normalized_endpoint normalized_process_user normalized_process_name normalized_process_path normalized_command_line normalized_time OUTPUT approved_activity

| eval linux_asset_match=coalesce(linux_asset_match,"false")

| eval writable_process_path=coalesce(writable_process_path,"false")

| eval writable_working_directory=coalesce(writable_working_directory,"false")

| eval suspicious_process_context=coalesce(suspicious_process_context,"false")

| eval approved_activity=coalesce(approved_activity,"false")

| eval effective_identity_known=if(isnotnull(normalized_effective_uid) OR isnotnull(normalized_effective_user),"true","false")

| eval effective_root=if(normalized_effective_uid="0" OR normalized_effective_user="root","true","false")

| where linux_asset_match="true"

| where normalized_os="linux" OR workload_type IN ("linux_server","linux_cloud_workload","kubernetes_node","container_host","ci_runner","build_system","privileged_automation")

| where effective_identity_known="true"

| where effective_root!="true"

| where writable_process_path="true" OR writable_working_directory="true"

| where suspicious_process_context="true"

| where approved_activity!="true"

| eval priority=case(

    asset_criticality IN ("critical","high") AND exposure_class="internet_facing","high",

    workload_type IN ("kubernetes_node","container_host","ci_runner","build_system","privileged_automation"),"high",

    asset_criticality IN ("critical","high"),"medium",

    true(),"triage"

)

| eval event_kind="suspicious_linux_execution_from_writable_or_transient_path"

| table normalized_time normalized_endpoint normalized_host normalized_process_user normalized_real_user normalized_effective_user normalized_process_uid normalized_effective_uid normalized_parent_process_name normalized_parent_process_path normalized_process_name normalized_process_path normalized_current_directory normalized_command_line process_path_family working_directory_family process_context_family asset_role workload_type exposure_class asset_criticality priority event_kind

Rule

Suspicious Root Process From Non-Administrative or Writable-Path Parent Context

Rule Format

Splunk behavioral search pattern using normalized Linux process telemetry, affirmative effective-root identity, validated parent identity, writable-parent-path classification, suspicious parent and root-process classifications, approved privilege-management exceptions, and workload enrichment.

Detection Purpose

Detect a root-owned process whose immediate parent identity, parent executable path, parent process classification, or execution context indicates a suspicious non-administrative, writable-path, scripting, application-service, CI, container, or other constrained origin.

The rule detects suspicious root-process creation with credible parent context. It does not claim a fully reconstructed low-privilege-to-root sequence unless the contributing telemetry directly preserves that relationship.

Detection Logic

·        Normalize root process, parent process, effective identity, and parent identity fields.

·        Require affirmative known effective-root identity for the resulting process.

·        Use validated parent effective-user or parent effective-UID fields to identify a directly observed non-root parent.

·        Reject direct non-root parent classification when any available validated parent-identity field indicates root.

·        Identify parent executables originating from writable or transient paths.

·        Identify parent processes associated with scripting, compilation, download, application-service, web-service, container, CI, or other suspicious execution contexts.

·        Require the root process to match a suspicious root-outcome classification.

·        Treat session, login, or source-user context as investigative enrichment rather than direct parent proof.

·        Exclude approved sudo, su, doas, pkexec, package-management, service-management, configuration-management, orchestration, deployment, backup, incident-response, and maintenance workflows.

·        Increase priority when direct non-root parent evidence exists or the affected workload is critical, exposed, privileged, or trust-sensitive.

·        Treat vulnerability state and preceding staging as optional enrichment.

Required Telemetry

·        Linux process creation or execution telemetry.

·        Effective user and effective UID for the root process.

·        Parent effective user or parent effective UID where available.

·        Process and parent-process identifiers where available.

·        Process name, process path, parent process name, parent process path, command line, and working directory.

·        Asset role, workload type, exposure class, and asset criticality.

·        Approved privilege-management users, tools, commands, workflows, and maintenance windows.

Engineering Implementation Instructions

·        Validate effective-root and parent-identity field mappings before deployment.

·        Do not treat process-user, login-user, source-user, or session-user fields as effective-root evidence unless the customer explicitly validates their semantics.

·        Require suspicious parentage in addition to root process creation.

·        Use parent effective-user or parent effective-UID fields as direct non-root parent evidence only when those fields are populated and validated.

·        Reject direct non-root parent classification when either validated parent field identifies root.

·        Treat source-user and login-user fields as supporting context only.

·        Maintain separate writable-parent-path, suspicious-parent-context, suspicious-root-outcome, and approved-transition lookups.

·        Configure path and command-pattern lookup fields for wildcard matching where required.

·        Normalize all lookup misses to explicit false values.

·        Tune service managers, schedulers, package managers, container runtimes, orchestration platforms, backup platforms, and administrative automation.

·        Deploy in hunt mode until effective identity and parent-process fidelity are validated.

·        Present the event as suspicious root-process creation from non-administrative or writable-path parent context.

DRI Assessment

The rule detects a durable post-boundary execution pattern using effective-root identity and suspicious parent context. It remains resilient to exploit implementation changes but does not reconstruct the complete privilege-transition sequence when only a single root-process event is available.

DRI

8.6

TCR Assessment

Operational confidence depends on effective-root identity, parent-process fidelity, parent-identity availability, parent-context classification, approved administrative exceptions, and workload enrichment. Full-telemetry confidence improves with direct process identifiers, Storyline or process-tree context, staging activity, authentication evidence, vulnerable-state data, and subsequent root activity.

Operational TCR

8.2

Full-Telemetry TCR

8.9

Limitations

·        Parent effective-user and parent effective-UID fields may be unavailable or inconsistently populated.

·        Service managers, schedulers, package managers, orchestration tools, and approved administrative workflows legitimately create root-owned processes.

·        Process ancestry may be incomplete across containers, namespaces, shells, service managers, or telemetry gaps.

·        A non-root session or login user does not prove that the immediate parent process was non-root.

·        Attackers may inject into an existing root process without creating a new process.

·        The rule does not identify the exact privilege-escalation mechanism.

Detection Query Pattern

Use this pattern as an implementation guide for Splunk environments that support normalized Linux process telemetry, affirmative effective-root identity, validated parent identity, writable-parent-path classification, suspicious parent and root-process mappings, approved privilege-transition exceptions, and workload enrichment.

`linux_process_events`

| eval normalized_time=coalesce(_time,event_time,EventTime,timestamp)

| eval normalized_host=coalesce(hostname,host,dest,dvc,device_name)

| eval normalized_endpoint=coalesce(endpoint_id,agent_id,device_id,host_id,cloud_instance_id,kubernetes_node_id,container_host_id,ci_runner_id,normalized_host)

| eval normalized_os=lower(coalesce(os,host_os,operating_system,platform))

| eval normalized_process_id=tostring(coalesce(process_id,pid,ProcessId))

| eval normalized_parent_process_id=tostring(coalesce(parent_process_id,ppid,ParentProcessId))

| eval normalized_process_name=lower(coalesce(process_name,process,ImageName,exe_name))

| eval normalized_process_path=lower(coalesce(process_path,process_exec,Image,exe))

| eval normalized_parent_process_name=lower(coalesce(parent_process_name,parent_process,ParentImageName,parent_name))

| eval normalized_parent_process_path=lower(coalesce(parent_process_path,ParentImage,parent_exec))

| eval normalized_command_line=lower(coalesce(process_command_line,command_line,CommandLine,cmdline))

| eval normalized_current_directory=lower(coalesce(current_directory,working_directory,cwd))

| eval normalized_effective_user=lower(coalesce(effective_user,dest_user,euser))

| eval normalized_effective_uid=tostring(coalesce(effective_uid,euid))

| eval normalized_parent_effective_user=lower(coalesce(parent_effective_user,parent_euser))

| eval normalized_parent_effective_uid=tostring(coalesce(parent_effective_uid,parent_euid))

| eval normalized_source_user=lower(coalesce(src_user,real_user,login_user))

| lookup ENV_LINUX_MONITORED_ASSETS normalized_endpoint OUTPUT linux_asset_match asset_role workload_type exposure_class asset_criticality

| lookup ENV_LINUX_WRITABLE_PATHS normalized_parent_process_path OUTPUT writable_parent_path parent_path_family

| lookup ENV_LINUX_SUSPICIOUS_PARENT_CONTEXT normalized_parent_process_name normalized_parent_process_path OUTPUT suspicious_parent_context parent_context_family

| lookup ENV_LINUX_SUSPICIOUS_ROOT_OUTCOMES normalized_process_name normalized_process_path normalized_command_line OUTPUT suspicious_root_outcome root_outcome_family

| lookup ENV_APPROVED_LINUX_PRIVILEGE_TRANSITIONS normalized_endpoint normalized_parent_process_name normalized_process_name normalized_command_line normalized_time OUTPUT approved_transition

| eval linux_asset_match=coalesce(linux_asset_match,"false")

| eval writable_parent_path=coalesce(writable_parent_path,"false")

| eval suspicious_parent_context=coalesce(suspicious_parent_context,"false")

| eval suspicious_root_outcome=coalesce(suspicious_root_outcome,"false")

| eval approved_transition=coalesce(approved_transition,"false")

| eval root_identity_known=if(isnotnull(normalized_effective_uid) OR isnotnull(normalized_effective_user),"true","false")

| eval effective_root=if(normalized_effective_uid="0" OR normalized_effective_user="root","true","false")

| eval parent_uid_non_root=if(

    isnotnull(normalized_parent_effective_uid)

    AND normalized_parent_effective_uid!="0",

    "true",

    "false"

)

| eval parent_user_non_root=if(

    isnotnull(normalized_parent_effective_user)

    AND normalized_parent_effective_user!="root",

    "true",

    "false"

)

| eval parent_root_contradiction=if(

    normalized_parent_effective_uid="0"

    OR normalized_parent_effective_user="root",

    "true",

    "false"

)

| eval direct_non_root_parent=if(

    parent_root_contradiction!="true"

    AND (

        parent_uid_non_root="true"

        OR parent_user_non_root="true"

    ),

    "true",

    "false"

)

| where linux_asset_match="true"

| where normalized_os="linux" OR workload_type IN ("linux_server","linux_cloud_workload","kubernetes_node","container_host","ci_runner","build_system","privileged_automation")

| where root_identity_known="true"

| where effective_root="true"

| where direct_non_root_parent="true" OR writable_parent_path="true" OR suspicious_parent_context="true"

| where suspicious_root_outcome="true"

| where approved_transition!="true"

| eval confidence_basis=case(

    direct_non_root_parent="true","direct_non_root_parent_identity",

    writable_parent_path="true","writable_parent_path_context",

    suspicious_parent_context="true","suspicious_parent_process_context"

)

| eval priority=case(

    direct_non_root_parent="true" AND asset_criticality IN ("critical","high"),"high",

    direct_non_root_parent="true","high",

    workload_type IN ("kubernetes_node","container_host","ci_runner","privileged_automation","identity_adjacent_system"),"high",

    asset_criticality IN ("critical","high"),"high",

    true(),"medium"

)

| eval event_kind="suspicious_root_process_from_non_administrative_or_writable_parent_context"

| table normalized_time normalized_endpoint normalized_host normalized_process_id normalized_parent_process_id normalized_source_user normalized_parent_effective_user normalized_parent_effective_uid normalized_parent_process_name normalized_parent_process_path normalized_effective_user normalized_effective_uid normalized_process_name normalized_process_path normalized_current_directory normalized_command_line parent_path_family parent_context_family root_outcome_family direct_non_root_parent confidence_basis asset_role workload_type exposure_class asset_criticality priority event_kind

Rule

Suspicious Root-Level Sensitive Resource Access or Security-Control Modification

Rule Format

Splunk multi-source endpoint search pattern using normalized effective-root identity, process and file telemetry, sensitive-resource classification, persistence and security-control path mapping, directly confirmed control-degradation events, branch-specific approved exceptions, and workload enrichment.

Detection Purpose

Detect suspicious root-level access to credentials, SSH material, workload identities, Kubernetes tokens, container runtime sockets, cloud credentials, CI/CD secrets, repository credentials, signing material, persistence locations, audit controls, logging controls, or security-agent resources.

The rule also detects directly confirmed security-control degradation when actor identity is unavailable but the event establishes that a protected agent, audit function, logging function, or telemetry-forwarding control was stopped, disabled, or modified.

Detection Logic

·        Normalize effective identity, process, file, control-health, workload, and event-outcome fields.

·        Require affirmative known effective-root identity for process-attributed command and file activity.

·        Identify root-level file reads, copies, archives, permission changes, ownership changes, writes, modifications, and deletions affecting sensitive resources or control paths.

·        Identify suspicious root commands associated with credential access, persistence, audit modification, logging modification, security-control degradation, cloud metadata access, or container and Kubernetes resource access.

·        Require command classification through an environment-maintained lookup.

·        Treat directly confirmed protected-agent or telemetry-control degradation as a separate valid event population.

·        Require a confirmed successful state change for actor-unattributed control-degradation events.

·        Apply root-activity exceptions to process and file branches.

·        Apply endpoint-, target-, service-, event-type-, and maintenance-aware control exceptions to control-degradation events.

·        Do not allow non-root file or command activity to satisfy a root-attributed branch.

·        Exclude approved administration, backup, monitoring, certificate management, secret rotation, package management, configuration management, deployment, incident response, and maintenance activity.

·        Increase priority for Kubernetes nodes, container hosts, CI runners, cloud workloads, identity-adjacent systems, privileged automation, and critical production assets.

·        Describe the alert according to the observed behavior rather than inferring credential theft, persistence, or local privilege escalation.

Required Telemetry

·        Linux process telemetry.

·        Linux file open, read, create, write, modify, copy, archive, delete, permission, and ownership telemetry where available.

·        Effective user and effective UID for process-attributed activity.

·        Process path, parent process, command line, and working directory.

·        Sensitive-resource, persistence, audit, logging, security-agent, telemetry-forwarder, Kubernetes, container, CI/CD, repository, and signing-material path mappings.

·        Security-agent, audit, logging, and service-health events.

·        Confirmed event outcome or state-change data for control-degradation events.

·        Asset role, workload type, exposure class, and asset criticality.

·        Approved users, processes, commands, tools, paths, targets, services, event types, and maintenance windows.

Engineering Implementation Instructions

·        Require affirmative known effective-root identity for all process-attributed command and file activity.

·        Do not treat process-user, login-user, source-user, or missing identity fields as effective-root evidence.

·        Keep process-command, file-event, and confirmed control-degradation populations independently valid.

·        Normalize all branches into the same field schema before combining them.

·        Distinguish confirmed file access from command lines that merely reference a path.

·        Maintain sensitive-resource, persistence or control-path, suspicious-command, protected-process, and protected-service mappings separately.

·        Maintain separate root-activity and security-control exception lookups.

·        Configure command and path lookup fields for wildcard matching where required.

·        Normalize every lookup miss before event classification or filtering.

·        Apply branch-specific approved exceptions only after a valid event population has been established.

·        Ensure control exceptions can evaluate actor-unattributed events through endpoint, target process, target service, event type, and maintenance context.

·        Validate file-read visibility and security-control outcome fidelity before enabling high-severity alerting.

·        Deploy in hunt mode until effective-root identity, file-event fidelity, control-health telemetry, and administrative exceptions are validated.

DRI Assessment

The rule detects durable post-root objectives and directly confirmed control-degradation behavior across multiple privilege-escalation families. Its strength depends on confirmed effective-root context, file-event fidelity, command and resource classification, control-health telemetry, and administrative tuning.

DRI

8.6

TCR Assessment

Operational confidence depends on normalized effective-root identity, process and file telemetry, sensitive-resource mappings, control-health telemetry, event-outcome fidelity, and branch-specific approved workflow exceptions. Full-telemetry confidence improves with preceding privilege-transition, staging, network, cloud, Kubernetes, container, and identity evidence.

Operational TCR

8.2

Full-Telemetry TCR

8.9

Limitations

·        Linux file-read visibility varies by telemetry source and policy.

·        Root-owned services may legitimately access protected files, credentials, tokens, sockets, and configuration.

·        Backup, monitoring, secret rotation, certificate management, configuration management, deployment, and incident-response activity may overlap.

·        Command-line references do not prove file access.

·        Actor attribution may be unavailable for some control-health events.

·        Control-health event outcomes may differ across products and require normalization.

·        The rule does not prove that root access resulted from local privilege escalation.

Detection Query Pattern

Use this pattern as an implementation guide for Splunk environments that support normalized Linux process, file, and security-control telemetry; affirmative effective-root identity; sensitive-resource, command, and control-path mappings; branch-specific approved exceptions; confirmed outcome data; and workload enrichment. The macros must be replaced with validated customer-specific searches when they are not already implemented.

`linux_process_events`

| eval normalized_time=coalesce(_time,event_time,EventTime,timestamp)

| eval normalized_host=coalesce(hostname,host,dest,dvc,device_name)

| eval normalized_endpoint=coalesce(endpoint_id,agent_id,device_id,host_id,cloud_instance_id,kubernetes_node_id,container_host_id,ci_runner_id,normalized_host)

| eval normalized_os=lower(coalesce(os,host_os,operating_system,platform))

| eval normalized_event_type=lower(coalesce(event_type,EventType,action,operation,signature))

| eval normalized_event_outcome=lower(coalesce(event_outcome,outcome,result,status))

| eval normalized_process_name=lower(coalesce(process_name,process,ImageName,exe_name))

| eval normalized_process_path=lower(coalesce(process_path,process_exec,Image,exe))

| eval normalized_parent_process_name=lower(coalesce(parent_process_name,parent_process,ParentImageName,parent_name))

| eval normalized_command_line=lower(coalesce(process_command_line,command_line,CommandLine,cmdline))

| eval normalized_effective_user=lower(coalesce(effective_user,dest_user,euser))

| eval normalized_effective_uid=tostring(coalesce(effective_uid,euid))

| eval normalized_file_path=null()

| eval normalized_target_process=null()

| eval normalized_target_service=null()

| eval telemetry_branch="process_command"

| append [

    search `linux_file_events`

    | eval normalized_time=coalesce(_time,event_time,EventTime,timestamp)

    | eval normalized_host=coalesce(hostname,host,dest,dvc,device_name)

    | eval normalized_endpoint=coalesce(endpoint_id,agent_id,device_id,host_id,cloud_instance_id,kubernetes_node_id,container_host_id,ci_runner_id,normalized_host)

    | eval normalized_os=lower(coalesce(os,host_os,operating_system,platform))

    | eval normalized_event_type=lower(coalesce(event_type,EventType,action,operation,signature,file_action))

    | eval normalized_event_outcome=lower(coalesce(event_outcome,outcome,result,status))

    | eval normalized_process_name=lower(coalesce(process_name,process,ImageName,exe_name))

    | eval normalized_process_path=lower(coalesce(process_path,process_exec,Image,exe))

    | eval normalized_parent_process_name=lower(coalesce(parent_process_name,parent_process,ParentImageName,parent_name))

    | eval normalized_command_line=lower(coalesce(process_command_line,command_line,CommandLine,cmdline))

    | eval normalized_effective_user=lower(coalesce(effective_user,dest_user,euser))

    | eval normalized_effective_uid=tostring(coalesce(effective_uid,euid))

    | eval normalized_file_path=lower(coalesce(file_path,target_path,TargetFilename,path))

    | eval normalized_target_process=null()

    | eval normalized_target_service=null()

    | eval telemetry_branch="file_event"

]

| append [

    search `linux_security_control_events`

    | eval normalized_time=coalesce(_time,event_time,EventTime,timestamp)

    | eval normalized_host=coalesce(hostname,host,dest,dvc,device_name)

    | eval normalized_endpoint=coalesce(endpoint_id,agent_id,device_id,host_id,cloud_instance_id,kubernetes_node_id,container_host_id,ci_runner_id,normalized_host)

    | eval normalized_os=lower(coalesce(os,host_os,operating_system,platform))

    | eval normalized_event_type=lower(coalesce(event_type,EventType,action,operation,signature))

    | eval normalized_event_outcome=lower(coalesce(event_outcome,outcome,result,status))

    | eval normalized_process_name=lower(coalesce(process_name,process,ImageName,exe_name))

    | eval normalized_process_path=lower(coalesce(process_path,process_exec,Image,exe))

    | eval normalized_parent_process_name=lower(coalesce(parent_process_name,parent_process,ParentImageName,parent_name))

    | eval normalized_command_line=lower(coalesce(process_command_line,command_line,CommandLine,cmdline))

    | eval normalized_effective_user=lower(coalesce(effective_user,dest_user,euser))

    | eval normalized_effective_uid=tostring(coalesce(effective_uid,euid))

    | eval normalized_file_path=lower(coalesce(file_path,target_path,TargetFilename,path))

    | eval normalized_target_process=lower(coalesce(target_process_name,target_process,TargetProcess))

    | eval normalized_target_service=lower(coalesce(target_service_name,service_name,unit_name))

    | eval telemetry_branch="control_event"

]

| lookup ENV_LINUX_MONITORED_ASSETS normalized_endpoint OUTPUT linux_asset_match asset_role workload_type exposure_class asset_criticality

| lookup ENV_LINUX_SENSITIVE_RESOURCE_PATHS normalized_file_path OUTPUT sensitive_resource_match sensitive_resource_family

| lookup ENV_LINUX_PERSISTENCE_AND_CONTROL_PATHS normalized_file_path OUTPUT persistence_or_control_match persistence_or_control_family

| lookup ENV_LINUX_SENSITIVE_RESOURCE_OR_CONTROL_COMMANDS normalized_command_line OUTPUT suspicious_root_command command_family

| lookup ENV_SECURITY_AGENT_PROCESSES normalized_target_process OUTPUT protected_process_match

| lookup ENV_SECURITY_MONITORING_SERVICES normalized_target_service OUTPUT protected_service_match

| lookup ENV_APPROVED_ROOT_ACTIVITY normalized_endpoint normalized_effective_user normalized_process_name normalized_command_line normalized_file_path normalized_time OUTPUT approved_root_activity

| lookup ENV_APPROVED_SECURITY_CONTROL_ACTIVITY normalized_endpoint normalized_target_process normalized_target_service normalized_event_type normalized_time OUTPUT approved_control_activity

| eval linux_asset_match=coalesce(linux_asset_match,"false")

| eval sensitive_resource_match=coalesce(sensitive_resource_match,"false")

| eval persistence_or_control_match=coalesce(persistence_or_control_match,"false")

| eval suspicious_root_command=coalesce(suspicious_root_command,"false")

| eval protected_process_match=coalesce(protected_process_match,"false")

| eval protected_service_match=coalesce(protected_service_match,"false")

| eval approved_root_activity=coalesce(approved_root_activity,"false")

| eval approved_control_activity=coalesce(approved_control_activity,"false")

| eval root_identity_known=if(isnotnull(normalized_effective_uid) OR isnotnull(normalized_effective_user),"true","false")

| eval effective_root=if(normalized_effective_uid="0" OR normalized_effective_user="root","true","false")

| eval root_file_activity=if(

    telemetry_branch="file_event"

    AND root_identity_known="true"

    AND effective_root="true"

    AND (sensitive_resource_match="true" OR persistence_or_control_match="true")

    AND normalized_event_type IN ("file_opened","file_read","file_created","file_written","file_modified","file_copied","file_renamed","file_archived","file_deleted","permission_modified","ownership_modified"),

    "true",

    "false"

)

| eval root_command_activity=if(

    telemetry_branch="process_command"

    AND root_identity_known="true"

    AND effective_root="true"

    AND suspicious_root_command="true",

    "true",

    "false"

)

| eval confirmed_control_degradation=if(

    telemetry_branch="control_event"

    AND normalized_event_type IN ("agent_stopped","agent_disabled","service_stopped","service_disabled","configuration_modified","log_deleted","audit_policy_modified","telemetry_forwarding_modified")

    AND (protected_process_match="true" OR protected_service_match="true" OR persistence_or_control_match="true")

    AND normalized_event_outcome IN ("confirmed","successful","succeeded","state_changed"),

    "true",

    "false"

)

| eval approved_event=case(

    telemetry_branch="control_event",approved_control_activity,

    true(),approved_root_activity

)

| where linux_asset_match="true"

| where normalized_os="linux" OR workload_type IN ("linux_server","linux_cloud_workload","kubernetes_node","container_host","ci_runner","build_system","privileged_automation","identity_adjacent_system")

| where root_file_activity="true" OR root_command_activity="true" OR confirmed_control_degradation="true"

| where approved_event!="true"

| eval event_kind=case(

    root_file_activity="true" AND sensitive_resource_match="true","suspicious_root_sensitive_resource_activity",

    root_file_activity="true" AND persistence_or_control_match="true","suspicious_root_persistence_or_control_modification",

    root_command_activity="true","suspicious_root_command_activity",

    confirmed_control_degradation="true","confirmed_security_control_degradation"

)

| eval priority=case(

    confirmed_control_degradation="true","high",

    asset_criticality IN ("critical","high"),"high",

    workload_type IN ("kubernetes_node","container_host","ci_runner","identity_adjacent_system","privileged_automation"),"high",

    true(),"medium"

)

| eval event_kind=coalesce(event_kind,"suspicious_root_or_control_activity")

| table normalized_time normalized_endpoint normalized_host telemetry_branch normalized_effective_user normalized_effective_uid normalized_process_name normalized_process_path normalized_parent_process_name normalized_command_line normalized_file_path sensitive_resource_family persistence_or_control_family command_family normalized_event_type normalized_event_outcome normalized_target_process normalized_target_service root_file_activity root_command_activity confirmed_control_degradation approved_event asset_role workload_type exposure_class asset_criticality priority event_kind

Elastic

Detection Viability Assessment

Elastic can provide strong behavior-driven coverage for Linux foothold-to-root activity when Linux process, file, effective-identity, process-lineage, workload, and control-health telemetry are normalized into consistent ECS or locally enriched fields.

Three rule opportunities survive validation:

·        Suspicious Linux execution from writable or transient paths.

·        Abnormal low-privilege-to-root process transition.

·        Suspicious root-level sensitive-resource access or security-control modification.

The first rule provides independent exploit-staging coverage. The second uses a directly linked parent-to-child EQL sequence rather than loose same-host timing. The third detects independently valid post-root process, file, and control-degradation behavior. Vulnerability state, cloud context, Kubernetes context, container-host context, preceding staging, and subsequent activity may increase confidence but are not mandatory alert conditions. Together, these rule opportunities provide independent coverage for exploit staging, abnormal privilege transition, and suspicious post-root activity without depending on a specific CVE, exploit implementation, or kernel primitive.

Rule

Suspicious Linux Execution From Writable or Transient Paths

Rule Format

Elastic EQL process detection pattern using affirmative non-root effective identity, writable-path classification, suspicious process-context matching, asset enrichment, and approved workflow exceptions.

Detection Purpose

Detect suspicious execution of scripts, interpreters, compilers, linkers, build tools, permission-modification tools, or unfamiliar executables from writable, transient, user-controlled, build, workspace, mounted, or container-layer paths.

The rule identifies behavior consistent with exploit staging or suspicious local execution by a constrained user, service account, application account, CI runner, container process, or other non-administrative context. It does not claim that privilege escalation succeeded.

Detection Logic

·        Require a Linux process-start event.

·        Require affirmative known non-root effective identity.

·        Identify execution from temporary, shared-memory, home-directory, workspace, build, runner, mounted-volume, or container-writable paths.

·        Require a suspicious interpreter, shell, compiler, linker, build tool, permission tool, executable pattern, or command pattern.

·        Exclude approved package-management, CI/CD, deployment, orchestration, configuration-management, vulnerability-validation, incident-response, and administrative workflows.

·        Increase severity through asset criticality, internet exposure, Kubernetes, container-host, CI-runner, build-system, or privileged-automation context.

·        Treat vulnerable-state information, exploit names, CVE identifiers, filenames, hashes, and proof-of-concept strings as optional enrichment only.

Required Telemetry

·        Linux process-start events.

·        Effective user or effective UID.

·        Process name, executable path, command line, working directory, and parent-process context.

·        Host or endpoint identity.

·        Workload role, exposure class, and asset criticality.

·        Kubernetes, container-host, CI-runner, build-system, and cloud context where available.

·        Approved process, path, user, command, workflow, and maintenance exceptions.

Engineering Implementation Instructions

·        Validate data streams, index patterns, ECS mappings, field aliases, transforms, enrichment policies, and exception-list names before deployment.

·        Map the neutral fields below to customer-specific Elastic fields.

·        Require affirmative effective-identity evidence; do not classify missing identity as non-root.

·        Maintain writable-path, suspicious-process, executable-pattern, and command-pattern value lists or enrichments.

·        Tune developer systems, CI runners, build systems, container hosts, package managers, and deployment platforms separately.

·        Apply approved exceptions only after the suspicious event population has been established.

·        Use asset and vulnerability enrichment for severity and triage, not as mandatory detection gates.

·        Deploy in hunt mode until identity, path, and workflow baselines are validated.

·        Present the event as suspicious writable-path execution or exploit staging.

DRI Assessment

The rule detects durable exploit-staging behavior rather than exploit-specific artifacts. It remains useful across multiple Linux privilege-escalation families, but writable-path execution is not unique to exploitation and requires workload-aware tuning.

DRI

8.4

TCR Assessment

Operational confidence depends on process telemetry quality, effective-identity normalization, executable-path fidelity, suspicious-process classification, approved workflow exceptions, and workload enrichment. Full-telemetry confidence improves with file activity, process lineage, vulnerable-state context, container or Kubernetes context, and subsequent privilege-boundary behavior.

Operational TCR

8.1

Full-Telemetry TCR

8.8

Limitations

·        CI runners, development systems, build servers, package managers, deployment tools, and administrative automation may generate similar behavior.

·        Effective-user or effective-UID fields may be unavailable or inconsistently mapped.

·        Trusted binaries may be abused without executing from writable paths.

·        In-memory execution may not expose a persistent executable path.

·        Incorrect path or process classifications may reduce fidelity.

·        The rule does not prove successful privilege escalation.

Detection Query Pattern

Use this pattern as an implementation guide for Elastic environments that support Linux process telemetry, affirmative effective identity, writable-path matching, suspicious process-context matching, workload enrichment, approved workflow context, and role-aware severity. Customer-specific data streams, index names, field names, ECS mappings, transforms, enrichment policies, value lists, exception lists, and local enriched field names should be implemented locally. The field names below are neutral implementation placeholders and must be mapped to the customer’s Elastic schema.

process where

event.category == "process" and

event.type == "start" and

host.os.type == "linux" and

identity.effective.known == true and

identity.effective.is_root != true and

exception.approved_linux_staging_activity != true and

(

process.executable : ENV_LINUX_WRITABLE_OR_TRANSIENT_PATHS or

process.working_directory : ENV_LINUX_WRITABLE_OR_TRANSIENT_PATHS

) and

(

process.name in ENV_LINUX_SUSPICIOUS_INTERPRETERS_SHELLS_AND_BUILD_TOOLS or

process.executable : ENV_LINUX_SUSPICIOUS_EXECUTABLE_PATTERNS or

process.command_line : ENV_LINUX_SUSPICIOUS_STAGING_COMMAND_PATTERNS

) and

(

asset.linux.monitored == true or

workload.type in ("linux_server", "linux_cloud_workload", "kubernetes_node", "container_host", "ci_runner", "build_system", "privileged_automation")

)

Rule

Abnormal Low-Privilege-to-Root Process Transition

Rule Format

Elastic EQL parent-to-child sequence pattern using affirmative non-root source identity, direct process-entity linkage, affirmative effective-root child identity, suspicious root-outcome matching, workload enrichment, and approved privilege-transition exceptions.

Detection Purpose

Detect a directly linked transition from a non-root Linux process operating in a suspicious execution context to a root-owned child process within a short time window.

The rule targets the privilege-boundary outcome most relevant to local Linux privilege escalation. It does not rely on loose same-host timing or infer a transition solely from unrelated root activity.

Detection Logic

·        Require a Linux process-start event with affirmative known non-root effective identity.

·        Require suspicious writable-path, interpreter, shell, application-service, web-service, CI, container, download-tool, compiler, or build-tool context.

·        Link the source process entity directly to the root process parent entity.

·        Require the resulting child process to have affirmative effective-root identity.

·        Require the root child to match a suspicious shell, interpreter, privileged utility, service-control utility, unfamiliar executable, or root-command pattern.

·        Exclude approved sudo, su, doas, pkexec, package-management, service-management, configuration-management, orchestration, deployment, backup, incident-response, and maintenance workflows.

·        Increase confidence for critical, internet-facing, Kubernetes, container-host, CI-runner, build-system, privileged-automation, or identity-adjacent workloads.

·        Treat vulnerable-state information and subsequent post-root activity as optional enrichment.

Required Telemetry

·        Linux process-start events.

·        Stable process entity identifier.

·        Stable parent process entity identifier.

·        Effective user or effective UID for both sequence stages.

·        Process name, executable path, command line, and working directory.

·        Host identity.

·        Asset role, workload type, exposure class, and criticality.

·        Approved privilege-transition and administrative workflow context.

Engineering Implementation Instructions

·        Validate EQL sequence support and process-entity fidelity before deployment.

·        Require a populated and stable host identifier across both sequence stages.

·        Require the first-stage process entity identifier to map directly to the second-stage parent entity identifier.

·        Do not substitute a same-host sequence when direct parent-child linkage is unavailable.

·        Require affirmative non-root identity in the first stage and affirmative effective-root identity in the second stage.

·        Maintain suspicious source-context and suspicious root-outcome value lists or enrichments separately.

·        Tune approved privilege-management, package-management, service-management, scheduler, orchestration, backup, and administrative workflows.

·        Use source-user, login-user, or session-user context for investigation only unless its semantics are validated.

·        Deploy in hunt mode until process lineage and identity mappings are verified.

·        Present the alert as an abnormal directly linked privilege transition.

DRI Assessment

The rule detects the durable privilege-boundary outcome through direct parent-to-child linkage and affirmative identity evidence. It remains resilient to changes in exploit code, staging filenames, delivery mechanism, and kernel primitive.

DRI

9.0

TCR Assessment

Operational confidence depends on stable process-entity identifiers, parent-entity fidelity, effective-user mapping, sequence integrity, approved administrative exceptions, and workload enrichment. Full-telemetry confidence improves with preceding staging, authentication evidence, vulnerable-state context, sensitive-resource activity, and subsequent root behavior.

Operational TCR

8.4

Full-Telemetry TCR

9.2

Limitations

·        Process entity or parent entity identifiers may be unavailable or inconsistently populated.

·        Container namespaces, service managers, shells, schedulers, or telemetry gaps may interrupt lineage.

·        Approved administrative and automation workflows may produce legitimate non-root-to-root transitions.

·        Injection into an existing root process may not create the required child process.

·        The rule does not identify the specific privilege-escalation mechanism.

·        Environments without reliable direct lineage should not deploy a weakened same-host substitute as this rule.

Detection Query Pattern

Use this pattern as an implementation guide for Elastic environments that support Linux process-start telemetry, stable process and parent entity identifiers, affirmative effective identity, suspicious source-context matching, suspicious root-outcome matching, workload enrichment, approved privilege-transition context, and bounded EQL sequence logic. Customer-specific data streams, index names, field names, ECS mappings, transforms, enrichment policies, value lists, exception lists, and local enriched field names should be implemented locally. The field names below are neutral implementation placeholders and must be mapped to the customer’s Elastic schema.

sequence by host.id with maxspan=5m

  [process where

    event.category == "process" and

    event.type == "start" and

    host.os.type == "linux" and

    identity.effective.known == true and

    identity.effective.is_root != true and

    process.entity_id != null and

    exception.approved_linux_privilege_transition != true and

    (

      process.executable : ENV_LINUX_WRITABLE_OR_TRANSIENT_PATHS or

      process.working_directory : ENV_LINUX_WRITABLE_OR_TRANSIENT_PATHS or

      process.name in ENV_LINUX_SUSPICIOUS_SOURCE_PROCESSES or

      process.command_line : ENV_LINUX_SUSPICIOUS_SOURCE_COMMAND_PATTERNS or

      workload.execution_context in ("application_service", "web_service", "ci_runner", "container_process", "build_process", "unknown_local_binary")

    )

  ] by process.entity_id

  [process where

    event.category == "process" and

    event.type == "start" and

    host.os.type == "linux" and

    identity.effective.known == true and

    identity.effective.is_root == true and

    process.parent.entity_id != null and

    exception.approved_linux_privilege_transition != true and

    (

      process.name in ENV_LINUX_SUSPICIOUS_ROOT_PROCESSES or

      process.executable : ENV_LINUX_SUSPICIOUS_ROOT_EXECUTABLE_PATTERNS or

      process.command_line : ENV_LINUX_SUSPICIOUS_ROOT_COMMAND_PATTERNS

    ) and

    (

      asset.linux.monitored == true or

      workload.type in ("linux_server", "linux_cloud_workload", "kubernetes_node", "container_host", "ci_runner", "build_system", "privileged_automation", "identity_adjacent_system")

    )

  ] by process.parent.entity_id

Rule

Suspicious Root-Level Sensitive Resource Access or Security-Control Modification

Rule Format

Elastic multi-category EQL pattern using affirmative effective-root identity for process and file activity, sensitive-resource and control-path matching, directly confirmed security-control degradation, branch-specific approved exceptions, and workload enrichment.

Detection Purpose

Detect suspicious root-level access to credentials, SSH material, workload identities, Kubernetes tokens, container-runtime sockets, cloud credentials, CI/CD secrets, repository credentials, signing material, persistence paths, audit controls, logging controls, or security-agent resources.

The rule also detects directly confirmed security-control degradation when actor identity is unavailable but telemetry establishes that a protected agent, audit function, logging function, or telemetry-forwarding control was stopped, disabled, deleted, or modified.

Detection Logic

·        Require Linux telemetry.

·        Treat process-command, file-event, and confirmed control-degradation branches as independently valid event populations.

·        Require affirmative effective-root identity for process-command and file-event branches.

·        Identify root commands associated with credential access, persistence, audit modification, logging modification, security-control degradation, metadata access, container-runtime access, or Kubernetes material access.

·        Identify root file activity involving sensitive-resource, persistence, audit, logging, credential, token, socket, repository, signing, or security-control paths.

·        Require directly confirmed protected-process, protected-service, or protected-control state change for actor-unattributed control events.

·        Apply root-activity exceptions to process and file branches.

·        Apply endpoint-, target-, service-, event-type-, and maintenance-aware exceptions to control-degradation events.

·        Increase priority for critical production systems, Kubernetes nodes, container hosts, CI runners, cloud workloads, privileged automation, and identity-adjacent systems.

·        Describe the alert according to observed activity rather than inferring credential theft, persistence, or exploitation.

Required Telemetry

·        Linux process-start telemetry.

·        Linux file open, read, create, write, modify, rename, delete, permission, and ownership telemetry where available.

·        Effective user or effective UID for process and file branches.

·        Process name, executable path, command line, parent process, and working directory.

·        File path and file action.

·        Security-agent, audit, logging, telemetry-forwarder, and service-health events.

·        Protected-process, protected-service, sensitive-resource, persistence, and control-path classifications.

·        Confirmed event outcome or state-change status for control events.

·        Asset role, workload type, exposure class, and criticality.

·        Branch-specific approved exceptions.

Engineering Implementation Instructions

·        Validate Elastic process, file, and control-health data coverage before deployment.

·        Validate whether the selected rule type supports all required event categories and fields.

·        Deploy the branches as separate rules when tenant data views, mappings, or rule-type constraints prevent reliable combined evaluation.

·        Require affirmative effective-root identity for process and file branches.

·        Do not require actor identity for directly confirmed control-degradation events.

·        Maintain sensitive-resource, persistence or control-path, suspicious-command, protected-process, and protected-service mappings separately.

·        Maintain separate approved root-activity and approved security-control exception lists.

·        Apply branch-specific exceptions only after the corresponding event population is valid.

·        Validate file-read visibility before enabling high-severity file-access alerts.

·        Validate control-health outcome normalization before enabling actor-unattributed control alerts.

·        Deploy in hunt mode until identity, file-event, outcome, and administrative baselines are validated.

DRI Assessment

The rule detects durable post-root objectives and directly confirmed control-degradation behavior across multiple privilege-escalation families. It is resistant to exploit renaming and implementation changes because it focuses on privileged outcomes and follow-on activity.

DRI

8.7

TCR Assessment

Operational confidence depends on effective-root identity, file-event coverage, sensitive-resource mapping, command classification, control-health telemetry, event-outcome fidelity, and branch-specific exceptions. Full-telemetry confidence improves with preceding privilege transition, staging, network, cloud, Kubernetes, container, and identity evidence.

Operational TCR

8.2

Full-Telemetry TCR

9.0

Limitations

·        Linux file-read visibility varies by Elastic integration, endpoint policy, and audit configuration.

·        Root-owned services may legitimately access protected files, tokens, sockets, credentials, and configuration.

·        Backup, monitoring, secret rotation, certificate management, configuration management, deployment, and incident-response activity may overlap.

·        Command-line references do not prove file access.

·        Actor attribution may be unavailable for control-health events.

·        Control-event names and outcomes require local normalization.

·        The rule does not prove that root access resulted from local privilege escalation.

Detection Query Pattern

Use this pattern as an implementation guide for Elastic environments that support Linux process, file, security-agent, service-health, audit, logging, and telemetry-control events; affirmative effective identity; sensitive-resource matching; persistence and control-path matching; suspicious-command matching; protected-process and protected-service classification; branch-specific approved exceptions; event-outcome normalization; workload enrichment; and local severity logic. Customer-specific data streams, index names, field names, ECS mappings, transforms, enrichment policies, value lists, exception lists, and local enriched field names should be implemented locally. The field names below are neutral implementation placeholders and must be mapped to the customer’s Elastic schema.

any where

host.os.type == "linux" and

asset.linux.monitored == true and

(

  (

    event.category == "process" and

    event.type == "start" and

    identity.effective.known == true and

    identity.effective.is_root == true and

    exception.approved_root_activity != true and

    (

      process.command_line : ENV_LINUX_SENSITIVE_RESOURCE_OR_CONTROL_COMMAND_PATTERNS or

      process.name in ENV_LINUX_SUSPICIOUS_ROOT_PROCESSES or

      process.executable : ENV_LINUX_SUSPICIOUS_ROOT_EXECUTABLE_PATTERNS

    )

  ) or

  (

    event.category == "file" and

    event.type in ("access", "creation", "change", "deletion") and

    identity.effective.known == true and

    identity.effective.is_root == true and

    exception.approved_root_activity != true and

    file.action in ("opened", "read", "created", "written", "modified", "copied", "renamed", "archived", "deleted", "permission_modified", "ownership_modified") and

    (

      file.path : ENV_LINUX_SENSITIVE_RESOURCE_PATHS or

      file.path : ENV_LINUX_PERSISTENCE_AND_CONTROL_PATHS

    )

  ) or

  (

    event.category in ("configuration", "host", "process") and

    control.change.confirmed == true and

    exception.approved_security_control_activity != true and

    control.action in ("agent_stopped", "agent_disabled", "service_stopped", "service_disabled", "configuration_modified", "log_deleted", "audit_policy_modified", "telemetry_forwarding_modified") and

    control.outcome in ("confirmed", "successful", "succeeded", "state_changed") and

    (

      control.target_process in ENV_SECURITY_AGENT_PROCESSES or

      control.target_service in ENV_SECURITY_MONITORING_SERVICES or

      control.target_path : ENV_LINUX_PERSISTENCE_AND_CONTROL_PATHS

    )

  )

) and

(

  asset.criticality in ("high", "critical") or

  workload.type in ("linux_server", "linux_cloud_workload", "kubernetes_node", "container_host", "ci_runner", "build_system", "privileged_automation", "identity_adjacent_system")

)

QRadar

Detection Viability Assessment

QRadar is highly viable for this behavior family because the strongest observable pattern is not a single exploit string, CVE identifier, proof-of-concept artifact, filename, hash, or kernel primitive. The strongest detection path is abnormal root-process activity originating from low-privilege, writable-path, scripted, application, service-account, CI/CD, container, or other constrained execution context, followed by suspicious post-root behavior involving credential stores, SSH material, persistence configuration, security-control degradation, cloud metadata, Kubernetes trust material, container-runtime sockets, or other high-value Linux resources. QRadar is especially valuable where Linux process, file, audit, identity, vulnerability, asset-role, cloud, Kubernetes, and container-host telemetry can be normalized through validated DSM mappings and custom properties, because it can correlate effective-user and UID context, parent-process behavior, sensitive-resource access, approved-activity exclusions, workload exposure, and asset criticality.

Rule

Abnormal Low-Privilege-to-Root Transition on Linux Assets

Rule Format

QRadar AQL and CRE correlation rule pattern.

Detection Purpose

·        Detect suspicious transition from low-privilege or non-administrative execution to root-owned process activity on exposed or high-value Linux systems.

·        Target the privilege-boundary outcome most relevant to Linux local privilege escalation.

·        Avoid broad root-process alerting by requiring suspicious parentage, writable-path context, host exposure context, or approved-activity exclusions.

·        Detect the durable foothold-to-root behavior without relying on a specific CVE, exploit name, proof-of-concept artifact, hash, filename, or kernel primitive.

Detection Logic

·        Identify root-owned or effective-root process activity where the parent process originates from a writable, transient, user-controlled, build, runner, mounted, or other suspicious execution path.

·        Identify root-owned or effective-root process activity where the parent process is a scripting engine, interactive shell, compiler, build utility, transfer utility, or network utility associated with constrained execution or exploit staging.

·        Exclude common package-management and service-management processes that routinely generate legitimate root activity.

·        Exclude hosts included in approved Linux administration or approved Linux automation reference sets.

·        Require the host to be included in the Linux privilege-escalation exposure set or the high-value Linux workload set.

·        Increase investigative priority for cloud Linux instances, Kubernetes nodes, container hosts, CI runners, internet-facing workloads, identity-adjacent systems, privileged automation systems, and high-value production workloads.

·        Treat the result as an abnormal root-process outcome, not proof of a specific exploit.

Required Telemetry

·        Linux process creation telemetry from EDR, Linux audit, Sysmon for Linux, osquery, or an equivalent endpoint source.

·        Process name.

·        Process path.

·        Process command line.

·        Parent process name.

·        Parent process path.

·        Username.

·        Effective username.

·        UID.

·        Effective UID.

·        Hostname.

·        Host operating system.

·        Asset role.

·        Exposure state.

·        Cloud context.

·        Kubernetes context.

·        Container-host context.

·        Linux privilege-escalation exposure reference set.

·        High-value Linux workload reference set.

·        Approved Linux administration reference set.

·        Approved Linux automation reference set.

Engineering Implementation Instructions

·        Validate QRadar DSM parsing and custom properties for process name, process path, process command line, parent process name, parent process path, username, effective username, UID, effective UID, hostname, host operating system, asset role, exposure state, cloud context, Kubernetes context, and container-host context.

·        Do not assume parent-user, effective-user, UID, or process-ancestry fields are populated unless the applicable log sources have been tested.

·        Map Linux_Privilege_Escalation_Exposure_Assets to vulnerability-management, exposure-management, kernel-state, host-hardening, or equivalent asset data.

·        Map High_Value_Linux_Workloads to production role, cloud role, Kubernetes role, container-host role, CI/CD role, identity adjacency, privileged automation, or business criticality.

·        Maintain Approved_Linux_Admin_Activity and Approved_Linux_Automation as narrowly scoped hostname-based reference sets.

·        Validate that hostname normalization is consistent across endpoint, vulnerability, asset, cloud, Kubernetes, and container-host data.

·        Review expected root activity from package managers, service-control utilities, configuration management, backup tools, vulnerability scanners, deployment automation, and maintenance workflows before enabling offense generation.

·        Test query performance across the intended ten-minute search window.

·        Deploy in hunt mode until field mappings, reference sets, expected administrative behavior, offense routing, and false-positive baselines are validated.

·        Preserve the query as a single independently evaluable QRadar rule.

DRI Assessment

The rule is anchored to abnormal root-process behavior and suspicious parentage rather than static exploit indicators. It remains useful when exploit code, staging filenames, command syntax, delivery mechanisms, or vulnerability families change. The score is constrained by QRadar’s dependence on normalized endpoint telemetry, parent-process fidelity, effective-user visibility, custom-property quality, and reference-set maintenance.

DRI

8.3

TCR Assessment

Operational confidence depends on Linux process telemetry quality, parent-child fidelity, effective-user visibility, UID visibility, custom-property parsing, reference-set quality, hostname normalization, and asset enrichment. Full-telemetry confidence improves when EDR, Linux audit, vulnerability, identity, cloud, Kubernetes, container-host, and CI/CD context are consistently normalized into QRadar.

Operational TCR

7.6

Full-Telemetry TCR

8.5

Limitations

·        Abnormal root-process creation may result from legitimate administration or other privilege-escalation methods.

·        The rule does not prove that local privilege escalation occurred.

·        Parent-process and effective-user context may not be consistently available across Linux log sources.

·        Hostname-based administration and automation exceptions can suppress malicious activity if they are too broad.

·        Exposure and high-value workload reference sets prioritize the rule but do not independently establish exploitation.

·        The rule may miss in-memory privilege escalation that does not create an observable root process.

·        AQL syntax, custom-property names, field types, reference sets, and DSM mappings must be validated in the target QRadar environment.

Detection Query Pattern

Use this pattern as an implementation-ready QRadar AQL search and map all property names, reference sets, DSM fields, asset profiles, search intervals, and CRE offense conditions to the target QRadar environment before deployment.

SELECT

  "starttime" AS event_time,

  "Hostname" AS host,

  "Username" AS user_name,

  "Effective Username" AS effective_user,

  "UID" AS uid,

  "Effective UID" AS effective_uid,

  "Process Name" AS process_name,

  "Process Path" AS process_path,

  "Process Command Line" AS process_command_line,

  "Parent Process Name" AS parent_process_name,

  "Parent Process Path" AS parent_process_path,

  "Asset Role" AS asset_role,

  "Exposure State" AS exposure_state,

  "Cloud Context" AS cloud_context,

  "Kubernetes Context" AS kubernetes_context,

  "Container Host Context" AS container_host_context

FROM events

WHERE

  "Host OS" ILIKE '%linux%'

  AND (

    "Effective Username" = 'root'

    OR "Username" = 'root'

    OR "Effective UID" = '0'

    OR "UID" = '0'

  )

  AND (

    "Parent Process Path" ILIKE '/tmp/%'

    OR "Parent Process Path" ILIKE '/var/tmp/%'

    OR "Parent Process Path" ILIKE '/dev/shm/%'

    OR "Parent Process Path" ILIKE '/home/%'

    OR "Parent Process Path" ILIKE '%/workspace/%'

    OR "Parent Process Path" ILIKE '%/workdir/%'

    OR "Parent Process Path" ILIKE '%/build/%'

    OR "Parent Process Path" ILIKE '%/runner/%'

    OR "Parent Process Path" ILIKE '/mnt/%'

    OR "Parent Process Name" IN (

      'python',

      'python3',

      'perl',

      'ruby',

      'bash',

      'sh',

      'dash',

      'zsh',

      'gcc',

      'cc',

      'make',

      'curl',

      'wget',

      'nc',

      'ncat',

      'socat'

    )

  )

  AND "Process Name" NOT IN (

    'apt',

    'apt-get',

    'yum',

    'dnf',

    'rpm',

    'dpkg',

    'systemctl',

    'service'

  )

  AND NOT REFERENCESETCONTAINS(

    'Approved_Linux_Admin_Activity',

    "Hostname"

  )

  AND NOT REFERENCESETCONTAINS(

    'Approved_Linux_Automation',

    "Hostname"

  )

  AND (

    REFERENCESETCONTAINS(

      'Linux_Privilege_Escalation_Exposure_Assets',

      "Hostname"

    )

    OR REFERENCESETCONTAINS(

      'High_Value_Linux_Workloads',

      "Hostname"

    )

  )

LAST 10 MINUTES

Rule

Suspicious Post-Root Activity on Linux Workloads

Rule Format

QRadar AQL and CRE correlation rule pattern.

Detection Purpose

·        Detect post-root activity on exposed or high-value Linux workloads after suspicious local execution, abnormal privilege transition, or another credible foothold signal.

·        Detect root-level credential access, persistence activity, security-control tampering, audit degradation, firewall modification, cloud metadata access, Kubernetes trust-material access, and container-runtime interaction.

·        Detect durable post-root behavior without requiring observation of the original exploit or privilege-transition event.

Detection Logic

·        Identify process or file events attributed to root or effective-root context.

·        Identify command-line activity associated with access to /etc/shadow or /etc/sudoers.

·        Identify command-line activity associated with SUID modification, immutable-file changes, service disabling, audit-rule removal, audit-service stopping, firewall flushing, or cloud metadata access.

·        Identify root-level file activity involving SSH material, Kubernetes paths, Kubernetes service-account tokens, Docker sockets, containerd sockets, CRI-Dockerd sockets, container data, or other trust-sensitive Linux resources.

·        Exclude approved Linux administration by hostname.

·        Exclude approved backup or monitoring tools and approved vulnerability scanners by process name.

·        Require the host to be included in the Linux privilege-escalation exposure set or high-value Linux workload set.

·        Increase confidence when the activity follows suspicious exploit staging, abnormal privilege transition, security-control degradation, credential access, or another confirmed foothold indicator.

·        Do not claim credential theft, persistence, cloud compromise, Kubernetes compromise, container escape, or successful exploitation beyond the observed activity.

Required Telemetry

·        Linux process creation telemetry.

·        Linux file-access or audit telemetry where the file-path branch is enabled.

·        Process name.

·        Process path.

·        Process command line.

·        File path.

·        File action.

·        Username.

·        Effective username.

·        UID.

·        Effective UID.

·        Hostname.

·        Host operating system.

·        Asset role.

·        Exposure state.

·        Cloud context.

·        Kubernetes context.

·        Container-host context.

·        Linux privilege-escalation exposure reference set.

·        High-value Linux workload reference set.

·        Approved Linux administration reference set.

·        Approved Linux backup and monitoring tools reference set.

·        Approved Linux vulnerability scanners reference set.

Engineering Implementation Instructions

·        Validate QRadar DSM parsing and custom properties for process name, process path, process command line, file path, file action, username, effective username, UID, effective UID, hostname, host operating system, asset role, exposure state, cloud context, Kubernetes context, and container-host context.

·        Validate Linux file-event coverage before enabling the file-path branch for production alerting.

·        Confirm that File Path and File Action represent an actual file event rather than a command-line reference or enrichment value.

·        If file telemetry is incomplete, deploy the process-command population first and retain the file-path population for hunting until coverage is validated.

·        Map Linux_Privilege_Escalation_Exposure_Assets to vulnerability-management, exposure-management, kernel-state, host-hardening, or equivalent asset data.

·        Maintain narrowly scoped reference sets for approved administration, backup and monitoring tools, and vulnerability scanners.

·        Validate hostname and process-name normalization before relying on reference-set suppression.

·        Review expected behavior from backup agents, monitoring tools, endpoint agents, vulnerability scanners, Kubernetes node operations, container management, configuration management, secret rotation, incident response, and authorized maintenance.

·        Prioritize offenses affecting cloud Linux instances, Kubernetes nodes, container hosts, CI runners, internet-facing workloads, identity-adjacent systems, privileged automation, or high-value production systems.

·        Correlate with prior suspicious staging or abnormal privilege transition before describing the activity as suspected foothold-to-root compromise.

·        Preserve sufficient retention for retrospective hunting across the relevant exposure period.

·        Test process and file populations separately before combining them in production.

·        Test query performance across the intended ten-minute search window.

·        Deploy in hunt mode until field mappings, file-event fidelity, reference sets, administrative baselines, offense routing, and false-positive behavior are validated.

DRI Assessment

The rule targets durable post-root objectives rather than exploit-specific artifacts. It remains useful across different Linux privilege-escalation vulnerabilities, exploit implementations, staging methods, and initial foothold paths. The score is constrained by overlap with legitimate administration, backup, monitoring, vulnerability scanning, Kubernetes operations, container operations, and security tooling.

DRI

8.2

TCR Assessment

Operational confidence depends on process-command telemetry, file-event coverage, effective-user visibility, UID visibility, custom-property parsing, enrichment quality, reference-set quality, hostname normalization, and retention. Full-telemetry confidence improves when EDR, Linux audit, vulnerability, cloud, Kubernetes, container-host, CI/CD, identity, and prior-transition context are consistently normalized into QRadar.

Operational TCR

7.5

Full-Telemetry TCR

8.4

Limitations

·        Post-root activity may result from compromise paths other than local privilege escalation.

·        The rule does not prove how root access was obtained.

·        File-event coverage may vary by Linux audit policy, EDR source, log source, and QRadar DSM mapping.

·        Command-line references do not prove that a sensitive resource was successfully accessed.

·        Backup agents, vulnerability scanners, monitoring tools, endpoint agents, Kubernetes operations, container operations, and approved administrators may generate overlapping activity.

·        Cloud metadata access can be legitimate for some workloads.

·        Hostname-based administrative exclusions and process-name tool exclusions can suppress malicious activity if they are too broad.

·        Exposure and high-value workload reference sets prioritize the activity but do not independently establish exploitation.

·        AQL syntax, custom-property names, reference sets, field types, and file-event mappings must be validated in the target QRadar environment.

Detection Query Pattern

Use this pattern as an implementation-ready QRadar AQL search and map all property names, reference sets, DSM fields, asset profiles, search intervals, and CRE offense conditions to the target QRadar environment before deployment.

SELECT

  "starttime" AS event_time,

  "Hostname" AS host,

  "Username" AS user_name,

  "Effective Username" AS effective_user,

  "UID" AS uid,

  "Effective UID" AS effective_uid,

  "Process Name" AS process_name,

  "Process Path" AS process_path,

  "Process Command Line" AS process_command_line,

  "File Path" AS file_path,

  "File Action" AS file_action,

  "Asset Role" AS asset_role,

  "Exposure State" AS exposure_state,

  "Cloud Context" AS cloud_context,

  "Kubernetes Context" AS kubernetes_context,

  "Container Host Context" AS container_host_context

FROM events

WHERE

  "Host OS" ILIKE '%linux%'

  AND (

    "Effective Username" = 'root'

    OR "Username" = 'root'

    OR "Effective UID" = '0'

    OR "UID" = '0'

  )

  AND (

    "Process Command Line" ILIKE '%cat /etc/shadow%'

    OR "Process Command Line" ILIKE '%cat /etc/sudoers%'

    OR "Process Command Line" ILIKE '%chmod +s%'

    OR "Process Command Line" ILIKE '%chattr%'

    OR "Process Command Line" ILIKE '%systemctl disable%'

    OR "Process Command Line" ILIKE '%auditctl -D%'

    OR "Process Command Line" ILIKE '%service auditd stop%'

    OR "Process Command Line" ILIKE '%iptables -F%'

    OR "Process Command Line" ILIKE '%curl 169.254.169.254%'

    OR "Process Command Line" ILIKE '%wget 169.254.169.254%'

    OR "File Path" IN (

      '/etc/shadow',

      '/etc/sudoers',

      '/var/run/docker.sock',

      '/run/containerd/containerd.sock',

      '/run/cri-dockerd.sock'

    )

    OR "File Path" ILIKE '/root/.ssh/%'

    OR "File Path" ILIKE '/var/lib/kubelet/%'

    OR "File Path" ILIKE '/var/run/secrets/kubernetes.io/%'

    OR "File Path" ILIKE '/etc/kubernetes/%'

    OR "File Path" ILIKE '/var/lib/containerd/%'

    OR "File Path" ILIKE '/var/lib/docker/%'

  )

  AND NOT REFERENCESETCONTAINS(

    'Approved_Linux_Admin_Activity',

    "Hostname"

  )

  AND NOT REFERENCESETCONTAINS(

    'Approved_Linux_Backup_Monitoring_Tools',

    "Process Name"

  )

  AND NOT REFERENCESETCONTAINS(

    'Approved_Linux_Vulnerability_Scanners',

    "Process Name"

  )

  AND (

    REFERENCESETCONTAINS(

      'Linux_Privilege_Escalation_Exposure_Assets',

      "Hostname"

    )

    OR REFERENCESETCONTAINS(

      'High_Value_Linux_Workloads',

      "Hostname"

    )

  )

LAST 10 MINUTES

Sigma

Detection Viability Assessment

SIGMA is viable as a portable event-rule template for this behavior family when Linux process-creation telemetry, Linux audit records, file-event telemetry, EDR events, Sysmon for Linux, osquery data, vulnerability context, asset-role data, cloud workload context, Kubernetes context, container-host context, CI/CD context, and approved administrative activity are locally normalized and enriched before rule evaluation. SIGMA is not the strongest system for raw multi-event sequence construction by itself because backend SIEMs vary in correlation, joins, windows, identity handling, process-lineage support, and file-event translation. Its best use is to express portable, backend-mappable detection logic for writable-path exploit staging, abnormal low-privilege-to-root process activity, and suspicious post-root interaction with credential stores, persistence mechanisms, audit controls, cloud metadata, Kubernetes trust material, container-runtime resources, and other high-value Linux workload assets.

Rule

Writable-Path Exploit Staging on Linux Workloads

Rule Format

Sigma rule pattern for Linux process-creation telemetry.

Detection Purpose

·        Detect suspicious non-root Linux process execution from writable, transient, user-controlled, build, CI/CD, mounted-volume, or container-writable paths.

·        Identify local exploit preparation or execution involving scripting engines, shells, compilers, build tools, scripts, or executable-like files.

·        Detect durable staging behavior without relying on a specific vulnerability, exploit name, proof-of-concept filename, hash, repository, or kernel primitive.

·        Treat the event as suspicious staging rather than proof that privilege escalation succeeded.

Detection Logic

·        Identify Linux process execution from /tmp, /var/tmp, /dev/shm, user-home directories, workspace paths, work directories, build directories, runner directories, mounted volumes, or equivalent writable locations.

·        Require an interpreter, shell, compiler, build utility, script, or executable-like file.

·        Exclude root-owned execution from the staging population.

·        Prioritize activity on internet-facing systems, cloud Linux instances, Kubernetes nodes, container hosts, CI runners, build systems, identity-adjacent infrastructure, privileged automation systems, and high-value production workloads.

·        Increase confidence when staging is followed by abnormal root-owned process activity, privileged binary interaction, sensitive-resource access, persistence, or security-control degradation.

·        Apply backend-specific exceptions for approved CI jobs, development workflows, package management, configuration management, vulnerability validation, backup, monitoring, deployment, incident response, and administrative automation.

Required Telemetry

·        Linux process-creation telemetry.

·        Process executable path.

·        Process command line.

·        Parent process executable path.

·        Parent process command line.

·        Process user or effective-user context.

·        Host identity.

·        Host operating system.

·        Optional exposure-state, cloud, Kubernetes, container-host, CI/CD, workload-role, and asset-criticality enrichment.

Engineering Implementation Instructions

·        Validate backend mappings for Image, CommandLine, ParentImage, ParentCommandLine, User, and equivalent effective-user fields.

·        Scope translated detections to Linux systems.

·        Confirm how the target backend represents root and non-root identity.

·        Preserve the path, interpreter, tool, executable-like, and root-exclusion conditions during translation.

·        Add narrowly scoped backend exceptions for approved CI jobs, build systems, package managers, configuration-management tools, deployment platforms, vulnerability scanners, backup agents, monitoring tools, incident-response tools, and administrative automation.

·        Tune developer systems, CI runners, build systems, container hosts, and Kubernetes nodes separately because legitimate temporary execution may be common.

·        Use exposure and workload enrichment for prioritization rather than as the only detection requirement.

·        Split the rule into backend-specific variants only when the target platform cannot reliably translate the required user or path operators.

·        Deploy in hunt mode until path mappings, user mappings, false-positive behavior, and exception logic are validated.

·        Do not describe an isolated match as confirmed privilege escalation.

DRI Assessment

The rule is anchored to exploit-staging behavior rather than brittle artifact indicators. It remains useful when exploit code is renamed, recompiled, embedded, reduced, or delivered through a different writable location. The score is constrained because staging activity is not unique to exploitation and translation quality varies across backends.

DRI

8.2

TCR Assessment

Operational confidence depends on process-creation coverage, executable-path fidelity, command-line capture, user mapping, translation quality, and approved-workflow tuning. Full-telemetry confidence improves when backend results are enriched with exposure state, Linux audit, cloud, Kubernetes, container-host, CI/CD, workload-role, and follow-on privilege-transition evidence.

Operational TCR

7.8

Full-Telemetry TCR

8.6

Limitations

·        Legitimate CI jobs, development activity, build processes, administrative scripts, package management, vulnerability validation, and temporary maintenance may generate similar activity.

·        Some backends may not populate User, ParentImage, or ParentCommandLine consistently.

·        Writable-path execution does not prove exploitation.

·        In-memory execution or use of an existing trusted binary may avoid the executable-like file conditions.

·        Translation fidelity depends on local field mappings and backend operator support.

·        Confirmation requires privilege-transition, privileged-binary, sensitive-resource, persistence, control-degradation, or other corroborating evidence.

Detection Query Pattern

Use this as a Sigma event-rule template. Map all fields and local enrichment fields to the target SIEM or EDR before deployment.

title: Writable-Path Exploit Staging on Linux Workloads

id: 9d4e0a8a-4c7d-4e9c-8f7b-314310000001

status: test

description: Detects suspicious non-root Linux process execution from writable or transient paths that may indicate local exploit staging.

references:

  - Internal CyberDax detection model for Linux foothold-to-root privilege escalation and cloud workload trust compromise

author: CyberDax

date: 2026-07-10

logsource:

  product: linux

  category: process_creation

detection:

  selection_path:

    Image|contains:

      - '/tmp/'

      - '/var/tmp/'

      - '/dev/shm/'

      - '/home/'

      - '/workspace/'

      - '/workdir/'

      - '/build/'

      - '/runner/'

      - '/mnt/'

  selection_interpreter_or_tool:

    Image|endswith:

      - '/python'

      - '/python3'

      - '/perl'

      - '/ruby'

      - '/bash'

      - '/sh'

      - '/dash'

      - '/zsh'

      - '/gcc'

      - '/cc'

      - '/make'

  selection_executable_like:

    Image|endswith:

      - '.sh'

      - '.py'

      - '.out'

      - '.bin'

      - '.elf'

  filter_root:

    User:

      - 'root'

      - '0'

  condition: selection_path and (selection_interpreter_or_tool or selection_executable_like) and not filter_root

fields:

  - UtcTime

  - Computer

  - User

  - Image

  - CommandLine

  - ParentImage

  - ParentCommandLine

falsepositives:

  - Approved CI jobs

  - Administrative automation

  - Package management

  - Configuration management

  - Vulnerability scanning

  - Backup or monitoring tools

level: medium

tags:

  - attack.privilege_escalation

  - attack.t1068

Rule

Abnormal Low-Privilege-to-Root Process Transition

Rule Format

Sigma rule pattern for Linux process-creation telemetry.

Detection Purpose

·        Detect root-owned Linux process activity where parentage or execution context indicates low-privilege staging, writable-path execution, scripting activity, application execution, CI/CD activity, container execution, or another constrained origin.

·        Target the privilege-boundary outcome associated with local Linux privilege escalation.

·        Avoid broad root-process alerting by requiring suspicious parent paths or suspicious parent-process families.

·        Detect the durable root-process outcome without relying on a particular vulnerability, privileged binary, exploit implementation, filename, hash, or kernel interface.

Detection Logic

·        Identify root-owned process creation.

·        Require parent-process execution from writable, transient, user-controlled, workspace, build, runner, mounted, or equivalent paths.

·        Alternatively require parentage from scripting engines, shells, compilers, build tools, transfer utilities, or network utilities associated with local staging or constrained execution.

·        Exclude common package-management and service-management process outcomes.

·        Apply backend-specific exceptions for approved administration, automation, configuration management, package management, service management, orchestration, deployment, backup, monitoring, vulnerability scanning, incident response, and maintenance.

·        Increase investigative priority for exposed or high-value Linux workloads.

·        Increase confidence when the event follows writable-path staging or is followed by sensitive-resource access, persistence, security-control degradation, metadata access, Kubernetes material access, or container-runtime interaction.

·        Treat the event as an abnormal root-process outcome rather than proof of a specific exploit.

Required Telemetry

·        Linux process-creation telemetry.

·        Process user or effective-user context.

·        Process executable path.

·        Process command line.

·        Parent process executable path.

·        Parent process command line.

·        Host identity.

·        Host operating system.

·        Optional UID, effective UID, process ancestry, workload role, exposure state, cloud, Kubernetes, container-host, CI/CD, and asset-criticality enrichment.

Engineering Implementation Instructions

·        Validate backend mappings for User, Image, CommandLine, ParentImage, and ParentCommandLine.

·        Validate whether User: root and User: 0 correctly represent root or effective-root execution in the target backend.

·        Split the rule into backend-specific variants where username, UID, effective-user, or effective-UID fields require separate handling.

·        Preserve the suspicious parent-path, parent-process, and administrative-process exclusions during translation.

·        Add approved administrative and automation exceptions in the target backend rather than weakening the core selection.

·        Avoid broad hostname allowlisting where user-, process-, command-, workflow-, or maintenance-specific exceptions are available.

·        Use exposure state and workload criticality for prioritization rather than as standalone evidence.

·        Tune Kubernetes nodes, container hosts, CI runners, build systems, package-management hosts, and privileged automation separately.

·        Validate that the translated backend does not treat missing user fields as root.

·        Deploy in hunt mode until parent-process fidelity, root-identity mapping, exception behavior, and alert volume are validated.

·        Correlate with staging or post-root evidence before describing the event as suspected foothold-to-root compromise.

DRI Assessment

The rule is anchored to privilege-transition behavior and suspicious parentage rather than static artifacts. It remains resilient when exploit code, staging path, vulnerable subsystem, or privileged utility changes. The score is constrained by backend translation differences and inconsistent effective-user or parent-process visibility.

DRI

8.5

TCR Assessment

Operational confidence depends on process telemetry, parent-process fidelity, root-identity mapping, field translation, and administrative baseline tuning. Full-telemetry confidence improves with Linux audit, EDR, exposure-state, cloud, Kubernetes, container-host, CI/CD, identity, staging, and post-root evidence.

Operational TCR

7.7

Full-Telemetry TCR

8.6

Limitations

·        Abnormal root-process activity can result from legitimate administration or other privilege-escalation methods.

·        Effective-user, UID, and parent-process fields may not translate consistently across backends.

·        Service managers, schedulers, package managers, orchestration systems, deployment platforms, backup tools, and configuration-management tools may generate overlapping behavior.

·        The rule may miss privilege escalation that injects into an existing root process without creating a new process.

·        Parent-process fidelity may be reduced across containers, namespaces, service managers, and short-lived processes.

·        Backend validation and administrative baseline tuning are required before production deployment.

Detection Query Pattern

Use this as a Sigma event-rule template. Map all fields and local enrichment fields to the target SIEM or EDR before deployment.

title: Abnormal Low-Privilege-to-Root Process Transition

id: c473df2b-ff45-47af-9b46-314310000002

status: test

description: Detects root-owned Linux process activity with suspicious parentage from writable paths, scripting engines, transfer utilities, network utilities, or other user-controlled execution contexts.

references:

  - Internal CyberDax detection model for Linux foothold-to-root privilege escalation and cloud workload trust compromise

author: CyberDax

date: 2026-07-10

logsource:

  product: linux

  category: process_creation

detection:

  selection_root_user:

    User:

      - 'root'

      - '0'

  selection_parent_path:

    ParentImage|contains:

      - '/tmp/'

      - '/var/tmp/'

      - '/dev/shm/'

      - '/home/'

      - '/workspace/'

      - '/workdir/'

      - '/build/'

      - '/runner/'

      - '/mnt/'

  selection_parent_process:

    ParentImage|endswith:

      - '/python'

      - '/python3'

      - '/perl'

      - '/ruby'

      - '/bash'

      - '/sh'

      - '/dash'

      - '/zsh'

      - '/gcc'

      - '/cc'

      - '/make'

      - '/curl'

      - '/wget'

      - '/nc'

      - '/ncat'

      - '/socat'

  filter_admin_process:

    Image|endswith:

      - '/apt'

      - '/apt-get'

      - '/yum'

      - '/dnf'

      - '/rpm'

      - '/dpkg'

      - '/systemctl'

      - '/service'

  condition: selection_root_user and (selection_parent_path or selection_parent_process) and not filter_admin_process

fields:

  - UtcTime

  - Computer

  - User

  - Image

  - CommandLine

  - ParentImage

  - ParentCommandLine

falsepositives:

  - Approved administrator activity

  - Package management

  - Service management

  - Configuration management

  - Backup or monitoring tools

level: high

tags:

  - attack.privilege_escalation

  - attack.t1068

Rule

Suspicious Post-Root Activity on Linux Workloads

Rule Format

Sigma rule pattern for Linux process and file telemetry requiring backend validation.

Detection Purpose

·        Detect root-level Linux activity involving credential stores, SSH material, persistence commands, audit or security-control modification, cloud metadata, Kubernetes trust material, container-runtime sockets, container data, or other sensitive workload resources.

·        Identify durable post-root behavior that may follow Linux local privilege escalation.

·        Provide independently useful detection when exploit staging or the privilege-transition event was not observed.

·        Avoid reliance on a specific vulnerability, exploit primitive, proof-of-concept string, filename, hash, or kernel subsystem.

Detection Logic

·        Identify Linux process or file activity attributed to root.

·        Identify command-line activity involving /etc/shadow, /etc/sudoers, SUID modification, immutable-file modification, service disabling, audit-rule deletion, audit-service stopping, firewall flushing, or cloud metadata access.

·        Identify file activity involving sensitive Linux credentials, root SSH material, Docker sockets, containerd sockets, CRI-Dockerd sockets, kubelet paths, Kubernetes service-account tokens, Kubernetes configuration, containerd data, or Docker data.

·        Apply backend-specific exceptions for approved administrators, backup tools, vulnerability scanners, monitoring tools, endpoint security tooling, Kubernetes node operations, configuration management, secret rotation, deployment, incident response, and maintenance.

·        Increase investigative priority for exposed or high-value Linux workloads.

·        Increase confidence when the behavior follows writable-path staging, an abnormal root-process outcome, privileged-binary interaction, security-agent degradation, or another credible foothold signal.

·        Do not claim credential theft, persistence, control degradation, Kubernetes compromise, container compromise, cloud compromise, or successful exploitation beyond the observed event.

Required Telemetry

·        Linux process-creation telemetry.

·        Linux file-event or audit telemetry where the file-path population is enabled.

·        Process user or effective-user context.

·        Process executable path.

·        Process command line.

·        Parent process executable path.

·        Target filename or equivalent file-path field.

·        Host identity.

·        Host operating system.

·        Optional UID, effective UID, file action, workload role, exposure state, cloud, Kubernetes, container-host, CI/CD, and asset-criticality enrichment.

Engineering Implementation Instructions

·        Validate backend mappings for User, Image, CommandLine, ParentImage, and TargetFilename.

·        Confirm that TargetFilename represents an actual file event rather than a command-line reference or enrichment field.

·        Validate root-identity mapping before enabling production alerting.

·        If the backend cannot combine process and file telemetry reliably, split selection_process_commands and selection_sensitive_files into separate translated implementations.

·        Preserve the command and path conditions during translation.

·        Add narrowly scoped exceptions for approved administrators, backup tools, vulnerability scanners, monitoring agents, endpoint security tools, Kubernetes operations, container operations, configuration management, deployment, secret rotation, certificate rotation, incident response, and maintenance.

·        Use workload exposure and criticality for prioritization rather than as standalone compromise evidence.

·        Treat command-line references as behavioral indicators and not proof that the referenced file was successfully accessed.

·        Validate file-read, file-write, permission, ownership, rename, and delete coverage separately where the backend supports those actions.

·        Deploy in hunt mode until user mapping, file-event fidelity, administrative baselines, and exception behavior are validated.

·        Correlate with prior staging or abnormal privilege transition before describing the activity as suspected foothold-to-root compromise.

DRI Assessment

The rule targets durable post-root objectives commonly performed after obtaining privileged Linux access. It remains resilient to changes in exploit implementation because it does not depend on the initial vulnerability, proof-of-concept artifact, or kernel primitive. The score is constrained by overlap with legitimate administration, backup, monitoring, security tooling, and Kubernetes operations.

DRI

8.3

TCR Assessment

Operational confidence depends on backend process and file telemetry, root-user mapping, field translation, sensitive-path coverage, approved-workflow tuning, and retention. Full-telemetry confidence improves when backend results include EDR, Linux audit, exposure state, cloud, Kubernetes, container-host, CI/CD, identity, and prior-transition context.

Operational TCR

7.5

Full-Telemetry TCR

8.5

Limitations

·        Post-root behavior may result from compromise paths other than local privilege escalation.

·        File telemetry support varies significantly across Sigma backends.

·        Combined process and file logic may need to be separated during translation.

·        Command-line references do not prove that a sensitive file or resource was accessed.

·        Backup agents, vulnerability scanners, monitoring tools, endpoint security tools, Kubernetes operations, container operations, and approved administrators may generate overlapping activity.

·        Root-owned services may legitimately access credentials, tokens, sockets, configuration, and control resources.

·        The rule does not prove how root access was obtained.

Detection Query Pattern

Use this as a Sigma event-rule template. Map all fields and local enrichment fields to the target SIEM or EDR before deployment.

title: Suspicious Post-Root Activity on Linux Workloads

id: 2fd2d7b0-7984-44f4-a935-314310000003

status: test

description: Detects root-level Linux activity involving sensitive credential files, persistence commands, audit tampering, cloud metadata access, Kubernetes material, or container-runtime resources.

references:

  - Internal CyberDax detection model for Linux foothold-to-root privilege escalation and cloud workload trust compromise

author: CyberDax

date: 2026-07-10

logsource:

  product: linux

detection:

  selection_root_user:

    User:

      - 'root'

      - '0'

  selection_process_commands:

    CommandLine|contains:

      - 'cat /etc/shadow'

      - 'cat /etc/sudoers'

      - 'chmod +s'

      - 'chattr'

      - 'systemctl disable'

      - 'auditctl -D'

      - 'service auditd stop'

      - 'iptables -F'

      - 'curl 169.254.169.254'

      - 'wget 169.254.169.254'

  selection_sensitive_files:

    TargetFilename|contains:

      - '/etc/shadow'

      - '/etc/sudoers'

      - '/root/.ssh/'

      - '/var/run/docker.sock'

      - '/run/containerd/containerd.sock'

      - '/run/cri-dockerd.sock'

      - '/var/lib/kubelet/'

      - '/var/run/secrets/kubernetes.io/'

      - '/etc/kubernetes/'

      - '/var/lib/containerd/'

      - '/var/lib/docker/'

  condition: selection_root_user and (selection_process_commands or selection_sensitive_files)

fields:

  - UtcTime

  - Computer

  - User

  - Image

  - CommandLine

  - ParentImage

  - TargetFilename

falsepositives:

  - Approved administrator activity

  - Backup tools

  - Vulnerability scanners

  - Monitoring tools

  - Endpoint security tooling

  - Kubernetes node operations

level: high

tags:

  - attack.privilege_escalation

  - attack.credential_access

  - attack.persistence

  - attack.defense_evasion

  - attack.t1068

YARA

YARA Coverage Disposition

YARA has zero deployable rules for this EXP report.

YARA is not viable as a primary S25 detection system because the report’s detection model is behavioral, sequence-based, privilege-transition driven, process-context based, Linux audit and endpoint-telemetry driven, sensitive-resource access based, control-degradation based, persistence based, and cloud-workload trust-context based rather than static-file, malware-signature, or artifact-matching based.

YARA may provide limited supporting value only if a confirmed malicious exploit file, compiled payload, script artifact, loader, dropper, shared object, kernel-module artifact, container-layer artifact, archive artifact, memory artifact, persistence implant, credential-theft tool, cloud-token harvesting artifact, Kubernetes trust-material collection utility, container-runtime abuse tool, or reusable malware-family artifact is recovered and independently validated.

Final YARA Outcome

No YARA rules survive.

AWS

Detection Viability Assessment

AWS is conditionally viable for this behavior family when the affected Linux server, EC2 instance, EKS worker node, container host, CI runner, build system, internet-facing workload, identity-adjacent system, privileged automation host, or high-value production workload is deployed in AWS or when AWS telemetry can be correlated with Linux host behavior observed elsewhere. AWS telemetry should not be treated as primary proof of local privilege escalation by itself unless it is joined to suspicious writable-path execution, abnormal low-privilege-to-root transition, root-level activity, sensitive-resource access, security-control degradation, persistence, cloud metadata interaction, Kubernetes trust-material access, container-runtime interaction, or another credible host-compromise indicator. AWS detections are strongest when CloudTrail, GuardDuty, Security Hub, Inspector, AWS Config, IAM, STS, Systems Manager, Secrets Manager, KMS, EC2, EKS, S3, VPC Flow Logs, and normalized Linux endpoint or audit telemetry are correlated in a SIEM or cloud analytics layer. The original AWS detection structure is retained, with only the CVE-specific exposure fields changed where required to support the durable Linux privilege-escalation behavior model.

Rule

AWS Linux Privilege-Escalation Exposure and Workload Prioritization

Rule Format

AWS Athena, Security Hub, Inspector, and Config enrichment pattern.

Detection Purpose

·        Identify AWS-hosted Linux workloads with active local privilege-escalation exposure.

·        Prioritize exposed or high-value EC2 instances, EKS worker nodes, container hosts, CI runners, build systems, internet-facing workloads, identity-adjacent systems, privileged automation hosts, and production workloads.

·        Correlate exposure findings with workload ownership, kernel state, IAM role context, public exposure, asset criticality, and orchestration context.

·        Support patching, hunting, containment prioritization, and telemetry validation without treating vulnerable state as proof of exploitation.

Detection Logic

·        Identify active Security Hub or Inspector findings associated with approved Linux local privilege-escalation exposure.

·        Exclude suppressed, resolved, passed, terminated, or otherwise inactive findings and workloads.

·        Join exposure findings to AWS Config or equivalent EC2 and EKS workload inventory.

·        Prioritize internet-facing and high-criticality Linux workloads.

·        Prioritize EKS nodes, container hosts, CI runners, systems with attached IAM roles, and production workloads.

·        Use exposure findings to scope investigation and remediation rather than declare successful exploitation.

·        Increase investigative urgency when exposure overlaps with suspicious host behavior, metadata access, GuardDuty findings, abnormal role activity, secret retrieval, SSM activity, or other post-compromise indicators.

Required Telemetry

·        Amazon Inspector vulnerability findings.

·        AWS Security Hub findings.

·        AWS Config resource inventory.

·        EC2 instance identity and operating-system context.

·        EKS cluster and node-group context.

·        Instance state.

·        Kernel version.

·        Public IP and internet-facing state.

·        IAM instance-profile and role context.

·        Workload type.

·        Workload owner.

·        Environment.

·        Asset criticality.

·        Active Linux privilege-escalation exposure list or maintained vulnerability set.

·        Optional Linux EDR, audit, process, identity, container, Kubernetes, and security-agent health telemetry.

Engineering Implementation Instructions

·        Maintain an approved and current set of Linux local privilege-escalation vulnerabilities or exposure findings covered by the report’s behavior model.

·        Populate <approved_linux_privilege_escalation_vulnerability_ids> from vulnerability-management or exposure-management sources.

·        Validate Inspector and Security Hub coverage across all relevant AWS accounts and regions.

·        Confirm that Security Hub workflow, record-state, compliance, and suppression fields are normalized consistently.

·        Validate AWS Config coverage for EC2 instances, EKS nodes, container hosts, CI runners, and ephemeral workloads.

·        Map EC2 resource IDs, instance IDs, EKS node identities, hostnames, and endpoint asset identifiers consistently.

·        Validate kernel-version, operating-system, workload-type, owner, environment, exposure-state, and criticality data.

·        Review terminated, autoscaled, replaced, recycled, or ephemeral assets for inventory drift.

·        Use the output for prioritization and hunting, not as proof that privilege escalation occurred.

·        Correlate high-priority results with host process, Linux audit, identity, cloud metadata, Kubernetes, container-runtime, GuardDuty, and CloudTrail evidence.

·        Test table names, field names, data types, joins, vulnerability identifiers, and account-region normalization before deployment.

·        Preserve the query as a single independently evaluable exposure-prioritization rule.

DRI Assessment

The rule is anchored to Linux privilege-escalation exposure, workload role, public exposure, cloud identity context, orchestration role, and business criticality rather than a single exploit artifact. It remains reusable as additional Linux local privilege-escalation vulnerabilities enter the maintained exposure set. The score is constrained because vulnerable workload state supports prioritization but does not establish exploitation.

DRI

8.0

TCR Assessment

Operational confidence depends on Inspector coverage, Security Hub aggregation, Config accuracy, vulnerability-set maintenance, tag quality, account coverage, role-to-workload mapping, workload ownership, and finding freshness. Full-telemetry confidence improves when EC2, EKS, IAM, public exposure, workload ownership, vulnerability state, endpoint telemetry, Linux audit, and security-agent health are centrally correlated.

Operational TCR

7.8

Full-Telemetry TCR

8.7

Limitations

·        Vulnerable AWS workload state is not exploitation evidence.

·        Inspector and Security Hub findings may lag behind actual patch state.

·        Ephemeral, autoscaled, stopped, terminated, replaced, or manually maintained instances may create inventory drift.

·        Missing tags, incomplete Config coverage, fragmented account visibility, or weak role-to-workload mapping can reduce prioritization accuracy.

·        A maintained Linux privilege-escalation vulnerability set is required.

·        Host telemetry is required to determine whether suspicious staging, privilege transition, or root-level activity occurred.

·        Exposure prioritization may include vulnerabilities that do not match every technical detail of the governing behavior model.

·        Table names, field names, joins, identifiers, and enrichment logic must be adapted to the target AWS export model.

Detection Query Pattern

Use this as an AWS Athena, Security Hub, Inspector, and Config enrichment pattern. Map table names, field names, approved vulnerability identifiers, and asset joins to the target AWS export model before deployment.

-- AWS Athena / Security Hub / Inspector / Config enrichment pattern

-- Table and field names must be adapted to the customer export model.

WITH vulnerable_findings AS (

  SELECT

    account_id,

    region,

    resource_id,

    finding_id,

    title,

    description,

    severity_label,

    workflow_status,

    record_state,

    compliance_status,

    updated_at

  FROM security_hub_findings

  WHERE record_state = 'ACTIVE'

    AND workflow_status NOT IN ('SUPPRESSED', 'RESOLVED')

    AND (

      compliance_status IS NULL

      OR compliance_status NOT IN ('PASSED')

    )

    AND vulnerability_id IN (

      <approved_linux_privilege_escalation_vulnerability_ids>

    )

),

asset_context AS (

  SELECT

    account_id,

    region,

    resource_id,

    resource_type,

    instance_id,

    instance_state,

    platform,

    kernel_version,

    public_ip_present,

    internet_facing,

    iam_instance_profile,

    iam_role_arn,

    eks_cluster,

    eks_node_group,

    workload_type,

    workload_owner,

    environment,

    asset_criticality,

    tags

  FROM aws_config_ec2_asset_inventory

  WHERE platform LIKE '%Linux%'

    AND instance_state NOT IN ('terminated')

)

SELECT

  vf.account_id,

  vf.region,

  vf.resource_id,

  ac.instance_id,

  vf.severity_label,

  ac.platform,

  ac.kernel_version,

  ac.instance_state,

  ac.internet_facing,

  ac.iam_instance_profile,

  ac.iam_role_arn,

  ac.eks_cluster,

  ac.eks_node_group,

  ac.workload_type,

  ac.workload_owner,

  ac.environment,

  ac.asset_criticality,

  CASE

    WHEN ac.internet_facing = true

      AND ac.asset_criticality IN ('critical','high') THEN 'high'

    WHEN ac.eks_cluster IS NOT NULL

      OR ac.eks_node_group IS NOT NULL

      OR ac.workload_type IN ('eks-node','container-host','ci-runner')

      OR ac.iam_role_arn IS NOT NULL THEN 'high'

    WHEN ac.environment = 'production' THEN 'medium'

    ELSE 'triage'

  END AS priority

FROM vulnerable_findings vf

JOIN asset_context ac

  ON vf.account_id = ac.account_id

 AND vf.region = ac.region

 AND vf.resource_id = ac.resource_id;

Rule

Post-Escalation AWS Credential and Control-Plane Activity After Suspected Linux Host Compromise

Rule Format

CloudTrail Lake, GuardDuty, and AWS control-plane correlation pattern.

Detection Purpose

·        Detect AWS control-plane activity that may follow root-level compromise of a Linux workload.

·        Identify suspicious use of IAM roles, instance profiles, access keys, assumed-role sessions, Secrets Manager, Systems Manager, EC2, EKS, KMS, S3, and STS capabilities associated with exposed or high-value Linux workloads.

·        Detect cloud-side blast-radius expansion involving secret retrieval, session initiation, role use, access-key creation, policy changes, security-group modification, snapshot or volume activity, storage access, or KMS decryption.

·        Provide independently useful cloud-control-plane evidence without claiming that AWS telemetry directly observed the local privilege-escalation event.

Detection Logic

·        Identify AWS API activity from IAM roles, instance profiles, access keys, or assumed-role sessions mapped to Linux EC2 instances, EKS nodes, container hosts, CI runners, or other covered workloads.

·        Identify STS, IAM, Secrets Manager, Systems Manager, EC2, EKS, KMS, and S3 operations relevant to credential use, secret access, remote command execution, privilege expansion, storage access, snapshot activity, network-control change, and workload discovery.

·        Prioritize activity associated with Linux privilege-escalation exposure, critical or high-value workloads, and covered workload types.

·        Require an unexpected source IP or unexpected user agent relative to approved cloud-administration and automation baselines.

·        Increase confidence when activity follows GuardDuty findings, suspicious host behavior, abnormal root-process activity, metadata access, security-agent degradation, Kubernetes trust-material access, container-runtime interaction, or another credible host-compromise signal.

·        Treat the result as possible cloud-side activity following workload compromise, not proof of how root access was obtained.

Required Telemetry

·        AWS CloudTrail Lake.

·        CloudTrail management events.

·        CloudTrail data events where required for S3 object activity.

·        GuardDuty findings.

·        Security Hub findings.

·        IAM role and instance-profile mapping.

·        EC2 instance identity.

·        EKS cluster and node-group context.

·        Workload type.

·        Asset criticality.

·        Exposure state.

·        Source IP.

·        User agent.

·        Access key.

·        Identity ARN.

·        Session issuer ARN.

·        Event source.

·        Event name.

·        Request parameters.

·        Response elements.

·        Approved cloud-administration source list.

·        Approved automation user-agent list.

·        Optional Linux host-compromise, metadata-access, EDR, audit, Kubernetes, and container-host enrichment.

Engineering Implementation Instructions

·        Map IAM roles and instance profiles to EC2 instances, EKS nodes, container hosts, CI runners, build systems, privileged automation, and high-value production workloads.

·        Replace the CVE-specific workload-status field with a maintained linux_privilege_escalation_exposure field or equivalent normalized exposure value.

·        Populate exposure status from Inspector, Security Hub, vulnerability-management, or exposure-management data.

·        Validate CloudTrail coverage across all relevant accounts and regions.

·        Confirm that the CloudTrail Lake event data store includes the required management and data events.

·        Enable and aggregate GuardDuty and Security Hub findings where available.

·        Establish expected role behavior for production workloads, EKS nodes, CI systems, automation roles, backup roles, deployment systems, and Systems Manager-managed instances.

·        Maintain narrowly scoped approved source-IP and automation user-agent datasets.

·        Validate role-to-instance, role-to-node, and role-to-workload attribution.

·        Review NAT gateways, proxies, AWS services, federated sessions, and automation platforms that can change apparent source-IP or user-agent behavior.

·        Correlate with host telemetry before describing the activity as suspected foothold-to-root compromise.

·        Test table names, nested-field access, joins, event-name coverage, source-IP exclusions, user-agent exclusions, and query performance before deployment.

·        Preserve the query as a single independently evaluable AWS control-plane rule.

DRI Assessment

The rule is anchored to post-escalation cloud activity and credential-use behavior rather than static exploit artifacts. It remains useful when the local exploit, vulnerable subsystem, staging method, or kernel primitive changes because it focuses on the cloud-side consequences of compromised workload credentials. The score is constrained because AWS control-plane events do not directly prove the local privilege-escalation path.

DRI

8.4

TCR Assessment

Operational confidence depends on CloudTrail coverage, GuardDuty coverage, IAM role mapping, instance-profile attribution, exposure-state accuracy, approved automation baselines, source-IP context, user-agent context, and enrichment quality. Full-telemetry confidence improves when CloudTrail, GuardDuty, Inspector, Security Hub, Config, EKS, IAM, Linux audit, EDR, metadata-access, and host-compromise telemetry are centrally correlated.

Operational TCR

7.7

Full-Telemetry TCR

8.7

Limitations

·        AWS control-plane activity may follow many compromise paths and is not unique to Linux local privilege escalation.

·        CloudTrail cannot directly observe local Linux privilege escalation.

·        Legitimate automation, deployment pipelines, Systems Manager activity, backup operations, security tooling, incident response, and administrative activity may generate overlapping API events.

·        Instance-profile and role mapping must be accurate to connect cloud activity to affected workloads.

·        Source-IP and user-agent deviations can occur because of proxies, NAT, AWS services, federated access, automation changes, and legitimate operational shifts.

·        CloudTrail data-event coverage may be required for some S3 object operations.

·        Host telemetry is required for high-confidence assessment of suspicious staging, privilege transition, or root-level compromise.

·        Exposure state increases priority but does not prove that the cloud activity resulted from privilege escalation.

Detection Query Pattern

Use this as a CloudTrail Lake SQL pattern. Map the event data store, table names, role-to-instance mapping, exposure field, approved source data, and approved automation data to the target AWS environment before deployment.

-- CloudTrail Lake SQL pattern.

-- Event data store, table names, and role-to-instance mapping must be adapted per environment.

SELECT

  ct.eventTime,

  ct.recipientAccountId,

  ct.awsRegion,

  ct.eventSource,

  ct.eventName,

  ct.userIdentity.type AS identity_type,

  ct.userIdentity.arn AS identity_arn,

  ct.userIdentity.accessKeyId AS access_key_id,

  ct.userIdentity.sessionContext.sessionIssuer.arn AS session_issuer_arn,

  ct.sourceIPAddress,

  ct.userAgent,

  ct.requestParameters,

  ct.responseElements,

  vrm.instance_id,

  vrm.workload_type,

  vrm.asset_criticality,

  vrm.exposure_state,

  vrm.eks_cluster,

  vrm.eks_node_group

FROM <cloudtrail_lake_event_data_store> ct

JOIN vulnerable_linux_workload_role_map vrm

  ON ct.userIdentity.sessionContext.sessionIssuer.arn = vrm.iam_role_arn

WHERE

  ct.eventSource IN (

    'sts.amazonaws.com',

    'iam.amazonaws.com',

    'secretsmanager.amazonaws.com',

    'ssm.amazonaws.com',

    'ec2.amazonaws.com',

    'eks.amazonaws.com',

    'kms.amazonaws.com',

    's3.amazonaws.com'

  )

  AND ct.eventName IN (

    'AssumeRole',

    'GetCallerIdentity',

    'GetSecretValue',

    'PutParameter',

    'GetParameter',

    'GetParameters',

    'SendCommand',

    'StartSession',

    'CreateAccessKey',

    'AttachUserPolicy',

    'AttachRolePolicy',

    'CreatePolicyVersion',

    'ModifyInstanceAttribute',

    'AuthorizeSecurityGroupIngress',

    'CreateSnapshot',

    'CopySnapshot',

    'CreateVolume',

    'AttachVolume',

    'DescribeCluster',

    'Decrypt',

    'ListBuckets',

    'GetObject'

  )

  AND (

    vrm.linux_privilege_escalation_exposure = true

    OR vrm.asset_criticality IN ('critical','high')

    OR vrm.workload_type IN ('ec2','eks-node','container-host','ci-runner')

  )

  AND (

    ct.sourceIPAddress NOT IN (

      SELECT approved_source_ip

      FROM approved_cloud_admin_sources

    )

    OR ct.userAgent NOT IN (

      SELECT approved_user_agent

      FROM approved_cloud_automation_user_agents

    )

  );

Azure

Detection Viability Assessment

Azure is conditionally viable for this behavior family when the affected Linux virtual machine, virtual-machine scale-set instance, AKS worker node, container host, CI runner, build system, internet-facing workload, identity-adjacent system, privileged automation host, or high-value production workload is deployed in Azure or when Azure telemetry can be correlated with Linux host behavior observed elsewhere. Azure telemetry should not be treated as primary proof of local privilege escalation by itself unless it is joined to suspicious writable-path execution, abnormal low-privilege-to-root transition, root-level activity, sensitive-resource access, security-control degradation, persistence, managed-identity use, Kubernetes trust-material access, container-runtime interaction, or another credible host-compromise indicator. Azure detections are strongest when Azure Activity logs, Microsoft Entra ID sign-in and audit logs, managed-identity activity, Defender for Cloud alerts, Microsoft Defender Vulnerability Management, Azure Resource Graph, AKS telemetry, Azure Monitor, Defender for Endpoint, Network Security Group flow logs, Azure Firewall logs, and normalized Linux endpoint or audit telemetry are correlated in Microsoft Sentinel, a SIEM, a data lake, or another analytics layer.

Rule

Azure Linux Privilege-Escalation Exposure and Workload Prioritization

Rule Format

Microsoft Defender for Cloud, Azure Resource Graph, and Microsoft Sentinel KQL exposure-enrichment pattern.

Detection Purpose

·        Identify Azure-hosted Linux workloads with active local privilege-escalation exposure.

·        Prioritize exposed or high-value Azure virtual machines, virtual-machine scale-set instances, AKS worker nodes, container hosts, CI runners, build systems, internet-facing workloads, identity-adjacent systems, privileged automation hosts, and production workloads.

·        Correlate exposure findings with workload ownership, operating-system state, managed-identity presence, public exposure, asset criticality, environment, and orchestration context.

·        Support patching, hunting, containment prioritization, telemetry validation, and workload-owner notification without treating vulnerable state as proof of exploitation.

Detection Logic

·        Identify active Defender for Cloud or vulnerability-management findings associated with approved Linux local privilege-escalation exposure.

·        Exclude healthy, exempted, suppressed, stopped, deallocated, or otherwise inactive findings and workloads.

·        Join exposure findings to Azure Resource Graph or equivalent inventory for virtual machines and virtual-machine scale-set instances.

·        Prioritize internet-facing and high-criticality Linux workloads.

·        Prioritize AKS nodes, container hosts, CI runners, workloads with managed identities, and production systems.

·        Use exposure findings to scope investigation and remediation rather than declare successful exploitation.

·        Increase investigative urgency when exposure overlaps with suspicious host behavior, metadata access, Defender findings, abnormal managed-identity activity, VM Run Command activity, AKS credential access, or other post-compromise indicators.

Required Telemetry

·        Microsoft Defender for Cloud recommendations.

·        Microsoft Defender Vulnerability Management findings where available.

·        Azure Resource Graph or equivalent imported resource inventory.

·        Azure virtual-machine and virtual-machine scale-set identity.

·        Linux operating-system and image context.

·        AKS cluster and node-pool context.

·        Power state.

·        Internet-facing state.

·        Managed-identity presence.

·        Workload type.

·        Workload owner.

·        Environment.

·        Asset criticality.

·        Active Linux privilege-escalation exposure list or maintained vulnerability set.

·        Optional Defender for Endpoint, Linux audit, process, identity, container, Kubernetes, and security-agent health telemetry.

Engineering Implementation Instructions

·        Maintain an approved and current set of Linux local privilege-escalation vulnerabilities or exposure findings covered by the report’s behavior model.

·        Populate the ApprovedLinuxPrivilegeEscalationIds array from Defender for Cloud, Microsoft Defender Vulnerability Management, vulnerability-management, or exposure-management sources.

·        Validate Defender and resource-inventory coverage across all relevant tenants, management groups, subscriptions, and regions.

·        Confirm that recommendation state, exemption state, suppression state, resource state, and finding freshness are normalized consistently.

·        Validate inventory coverage for Azure virtual machines, virtual-machine scale-set instances, AKS nodes, container hosts, CI runners, and ephemeral workloads.

·        Map Azure resource IDs, virtual-machine identities, scale-set instance identities, AKS node identities, hostnames, and endpoint asset identifiers consistently.

·        Validate operating-system state, image state, workload type, owner, environment, internet exposure, managed-identity presence, and asset criticality.

·        Review stopped, deallocated, autoscaled, rebuilt, recycled, or ephemeral assets for inventory drift.

·        Use the output for prioritization and hunting, not as proof that privilege escalation occurred.

·        Correlate high-priority results with host process, Linux audit, identity, metadata, AKS, container-runtime, Defender, and Azure Activity evidence.

·        Test table names, field names, data types, joins, vulnerability identifiers, resource-state handling, and subscription normalization before deployment.

·        Preserve the query as a single independently evaluable exposure-prioritization rule.

DRI Assessment

The rule is anchored to Linux privilege-escalation exposure, workload role, public exposure, managed-identity context, orchestration role, and business criticality rather than a single exploit artifact. It remains reusable as additional Linux local privilege-escalation vulnerabilities enter the maintained exposure set. The score is constrained because vulnerable workload state supports prioritization but does not establish exploitation.

DRI

8.0

TCR Assessment

Operational confidence depends on Defender coverage, resource-inventory accuracy, vulnerability-set maintenance, tag quality, subscription coverage, managed-identity mapping, workload ownership, finding freshness, and resource-state accuracy. Full-telemetry confidence improves when Azure virtual-machine, AKS, managed-identity, public-exposure, workload-ownership, vulnerability-state, endpoint, Linux audit, and security-agent health telemetry are centrally correlated.

Operational TCR

7.8

Full-Telemetry TCR

8.8

Limitations

·        Vulnerable Azure workload state is not exploitation evidence.

·        Defender and vulnerability findings may lag behind actual patch state.

·        Ephemeral, autoscaled, stopped, deallocated, rebuilt, replaced, or manually maintained instances may create inventory drift.

·        Missing tags, incomplete Defender coverage, fragmented subscription visibility, or weak managed-identity mapping can reduce prioritization accuracy.

·        A maintained Linux privilege-escalation vulnerability set is required.

·        Host telemetry is required to determine whether suspicious staging, privilege transition, or root-level activity occurred.

·        Exposure prioritization may include vulnerabilities that do not match every technical detail of the governing behavior model.

·        Table names, field names, joins, resource identifiers, and enrichment logic must be adapted to the target Azure environment.

Detection Query Pattern

Use this as an Azure Resource Graph, Defender for Cloud, and Microsoft Sentinel KQL exposure-enrichment pattern. Map table names, field names, approved vulnerability identifiers, and resource joins to the target Azure environment before deployment.

// Azure Resource Graph / Defender for Cloud / Sentinel enrichment pattern.

// SecurityRecommendation and Resources represent locally available or imported

// recommendation and resource-inventory tables.

let ApprovedLinuxPrivilegeEscalationIds = dynamic([

    "<CVE_OR_FINDING_ID_1>",

    "<CVE_OR_FINDING_ID_2>"

]);

let VulnerableFindings =

SecurityRecommendation

| where RecommendationDisplayName has_any (ApprovedLinuxPrivilegeEscalationIds)

   or Description has_any (ApprovedLinuxPrivilegeEscalationIds)

   or tostring(AdditionalData) has_any (ApprovedLinuxPrivilegeEscalationIds)

| where RecommendationState == "Unhealthy"

| where tostring(AdditionalData) !has "Exempted"

| project

    SubscriptionId,

    ResourceId = tolower(tostring(AssessedResourceId)),

    FindingName = RecommendationDisplayName,

    FindingState = RecommendationState,

    Severity,

    LastUpdated = TimeGenerated;

let AssetContext =

Resources

| where type =~ "microsoft.compute/virtualmachines"

   or type =~ "microsoft.compute/virtualmachinescalesets/virtualmachines"

| extend ResourceId = tolower(tostring(id))

| extend PowerState = tostring(properties.extended.instanceView.powerState.displayStatus)

| extend OsType = tostring(properties.storageProfile.osDisk.osType)

| extend Environment = tostring(tags.environment)

| extend WorkloadOwner = tostring(tags.owner)

| extend AssetCriticality = tostring(tags.criticality)

| extend WorkloadType = tostring(tags.workload_type)

| extend InternetFacing = tostring(tags.internet_facing)

| extend ManagedIdentityPresent = isnotempty(tostring(identity.principalId))

| where OsType =~ "Linux"

   or tostring(properties.storageProfile.imageReference.offer) has "linux"

| project

    SubscriptionId = tostring(subscriptionId),

    ResourceId,

    ResourceName = name,

    ResourceType = type,

    ResourceGroup = resourceGroup,

    Location = location,

    PowerState,

    OsType,

    Environment,

    WorkloadOwner,

    AssetCriticality,

    WorkloadType,

    InternetFacing,

    ManagedIdentityPresent;

VulnerableFindings

| join kind=inner AssetContext on SubscriptionId, ResourceId

| where PowerState !has "deallocated"

  and PowerState !has "stopped"

| extend Priority = case(

    InternetFacing =~ "true"

      and AssetCriticality in~ ("critical", "high"), "high",

    ManagedIdentityPresent == true

      or WorkloadType in~ ("aks-node", "container-host", "ci-runner"), "high",

    Environment =~ "production", "medium",

    "triage"

)

| project

    LastUpdated,

    SubscriptionId,

    ResourceGroup,

    ResourceName,

    ResourceType,

    Location,

    PowerState,

    Severity,

    FindingName,

    FindingState,

    Environment,

    WorkloadOwner,

    AssetCriticality,

    WorkloadType,

    InternetFacing,

    ManagedIdentityPresent,

    Priority

Rule

Post-Escalation Azure Managed-Identity and Control-Plane Activity After Suspected Linux Host Compromise

Rule Format

Azure Activity, Defender for Cloud, Azure Resource Graph, and Microsoft Sentinel KQL control-plane correlation pattern.

Detection Purpose

·        Detect Azure control-plane activity that may follow root-level compromise of a Linux workload.

·        Identify suspicious use of system-assigned managed identities, role assignments, VM Run Command, virtual-machine extensions, network-security controls, snapshots, disks, AKS credentials, and Storage account keys associated with exposed or high-value Linux workloads.

·        Detect cloud-side blast-radius expansion involving privilege modification, remote command execution, network-control modification, disk or snapshot activity, Kubernetes control-plane access, and storage-key retrieval.

·        Provide independently useful Azure control-plane evidence without claiming that Azure telemetry directly observed the local privilege-escalation event.

Detection Logic

·        Identify Azure API activity from system-assigned managed identities mapped to covered Linux virtual machines, virtual-machine scale-set instances, AKS nodes, container hosts, CI runners, or other high-value workloads.

·        Identify role-assignment changes, role-definition changes, VM Run Command, virtual-machine extension writes, network-security-rule changes, snapshot creation, disk modification, AKS user or administrator credential retrieval, and Storage account key retrieval.

·        Prioritize activity associated with Linux privilege-escalation exposure, critical or high-value workloads, AKS nodes, container hosts, CI runners, and production systems.

·        Require an unapproved source IP relative to approved cloud-administration baselines.

·        Increase confidence when activity follows Defender findings, suspicious host behavior, abnormal root-process activity, metadata access, security-agent degradation, Kubernetes trust-material access, container-runtime interaction, or another credible host-compromise signal.

·        Treat the result as possible cloud-side activity following workload compromise, not proof of how root access was obtained.

Required Telemetry

·        Azure Activity logs.

·        Microsoft Defender for Cloud recommendations or vulnerability findings.

·        Azure Resource Graph or equivalent imported resource inventory.

·        System-assigned managed-identity-to-workload mapping.

·        Azure virtual-machine and virtual-machine scale-set identity.

·        AKS cluster and node-pool context.

·        Workload type.

·        Asset criticality.

·        Exposure state.

·        Caller identity.

·        Caller IP address.

·        Operation name.

·        Activity status.

·        Subscription ID.

·        Resource group.

·        Resource ID.

·        Correlation ID.

·        Operation properties.

·        Approved Azure-administration source list.

·        Optional Microsoft Entra ID, Defender for Endpoint, Linux host-compromise, metadata-access, audit, Kubernetes, container-host, Key Vault, and Storage data-plane telemetry.

Engineering Implementation Instructions

·        Map system-assigned managed identities to Azure virtual machines, virtual-machine scale-set instances, AKS nodes, container hosts, CI runners, build systems, privileged automation, and high-value production workloads.

·        Maintain a linux_privilege_escalation_exposure field or equivalent normalized exposure value for covered Azure Linux workloads.

·        Populate exposure status from Defender for Cloud, Microsoft Defender Vulnerability Management, vulnerability-management, or exposure-management data.

·        Populate the ApprovedLinuxPrivilegeEscalationIds array from the maintained exposure set.

·        Populate the ApprovedAzureAdminSourceIps array with narrowly scoped administrative source addresses.

·        Validate Azure Activity coverage across all relevant tenants, management groups, subscriptions, and regions.

·        Confirm that diagnostic settings and Microsoft Sentinel connectors preserve the required operation, caller, caller-IP, resource, status, correlation, and properties fields.

·        Establish expected identity behavior for production workloads, AKS nodes, CI systems, automation identities, backup identities, deployment systems, VM Run Command, and virtual-machine extensions.

·        Validate system-assigned managed-identity-to-resource, managed-identity-to-node, and managed-identity-to-workload attribution.

·        Normalize managed-identity principal identifiers and Azure Activity caller identifiers before correlation.

·        Review Azure platform operations, proxies, automation services, managed services, and deployment platforms that can affect caller identity or source-IP context.

·        Correlate with host telemetry before describing the activity as suspected foothold-to-root compromise.

·        Test table names, field access, joins, operation-name coverage, source-IP exclusions, workload mapping, and query performance before deployment.

·        Preserve the query as a single independently evaluable Azure control-plane rule.

DRI Assessment

The rule is anchored to post-escalation cloud activity and managed-identity use rather than static exploit artifacts. It remains useful when the local exploit, vulnerable subsystem, staging method, or kernel primitive changes because it focuses on cloud-side consequences involving managed identities and workload control. The score is constrained because Azure control-plane events do not directly prove the local privilege-escalation path.

DRI

8.4

TCR Assessment

Operational confidence depends on Azure Activity coverage, Defender coverage, system-assigned managed-identity mapping, workload attribution, exposure-state accuracy, approved source baselines, caller normalization, and enrichment quality. Full-telemetry confidence improves when Azure Activity, Defender, resource inventory, Microsoft Entra ID, AKS, managed-identity, Linux audit, endpoint, metadata-access, and host-compromise telemetry are centrally correlated.

Operational TCR

7.6

Full-Telemetry TCR

8.7

Limitations

·        Azure control-plane activity may follow many compromise paths and is not unique to Linux local privilege escalation.

·        Azure Activity logs cannot directly observe local Linux privilege escalation.

·        Legitimate automation, deployment pipelines, VM Run Command activity, virtual-machine extensions, backup operations, security tooling, incident response, and administrative activity may generate overlapping events.

·        System-assigned managed-identity-to-workload mapping must be accurate to connect cloud activity to affected workloads.

·        The current query does not directly map user-assigned managed identities, service principals, or federated workload identities.

·        Caller-IP deviations can result from Azure services, managed services, automation platforms, proxies, and legitimate operational changes.

·        Key Vault secret retrieval and other data-plane actions require separate diagnostic telemetry and are not directly covered by this Azure Activity rule.

·        Host telemetry is required for high-confidence assessment of suspicious staging, privilege transition, or root-level compromise.

·        Exposure state increases priority but does not prove that Azure activity resulted from privilege escalation.

Detection Query Pattern

Use this as a Microsoft Sentinel and Log Analytics KQL pattern. Map table names, managed-identity relationships, exposure fields, approved source data, connectors, and diagnostic settings to the target Azure environment before deployment.

// Sentinel / Log Analytics KQL pattern.

// SecurityRecommendation and Resources represent locally available or imported

// recommendation and resource-inventory tables.

let ApprovedLinuxPrivilegeEscalationIds = dynamic([

    "<CVE_OR_FINDING_ID_1>",

    "<CVE_OR_FINDING_ID_2>"

]);

let ApprovedAzureAdminSourceIps = dynamic([

    "<APPROVED_ADMIN_IP_1>",

    "<APPROVED_ADMIN_IP_2>"

]);

let VulnerableWorkloadIdentities =

Resources

| where type =~ "microsoft.compute/virtualmachines"

   or type =~ "microsoft.compute/virtualmachinescalesets/virtualmachines"

| extend ResourceId = tolower(tostring(id))

| extend ManagedIdentityPrincipalId = tolower(tostring(identity.principalId))

| extend Environment = tostring(tags.environment)

| extend WorkloadOwner = tostring(tags.owner)

| extend AssetCriticality = tostring(tags.criticality)

| extend WorkloadType = tostring(tags.workload_type)

| where isnotempty(ManagedIdentityPrincipalId)

| join kind=inner (

    SecurityRecommendation

    | where RecommendationDisplayName has_any (ApprovedLinuxPrivilegeEscalationIds)

       or Description has_any (ApprovedLinuxPrivilegeEscalationIds)

       or tostring(AdditionalData) has_any (ApprovedLinuxPrivilegeEscalationIds)

    | where RecommendationState == "Unhealthy"

    | where tostring(AdditionalData) !has "Exempted"

    | project AssessedResourceId = tolower(tostring(AssessedResourceId))

) on $left.ResourceId == $right.AssessedResourceId

| project

    ManagedIdentityPrincipalId,

    ResourceId,

    Environment,

    WorkloadOwner,

    AssetCriticality,

    WorkloadType;

let SuspiciousAzureActivity =

AzureActivity

| where OperationNameValue in~ (

    "Microsoft.Authorization/roleAssignments/write",

    "Microsoft.Authorization/roleDefinitions/write",

    "Microsoft.Compute/virtualMachines/runCommand/action",

    "Microsoft.Compute/virtualMachines/extensions/write",

    "Microsoft.Network/networkSecurityGroups/securityRules/write",

    "Microsoft.Compute/snapshots/write",

    "Microsoft.Compute/disks/write",

    "Microsoft.ContainerService/managedClusters/listClusterUserCredential/action",

    "Microsoft.ContainerService/managedClusters/listClusterAdminCredential/action",

    "Microsoft.Storage/storageAccounts/listKeys/action"

)

| where ActivityStatusValue in~ ("Success", "Succeeded", "Accepted")

| extend NormalizedCaller = tolower(tostring(Caller))

| project

    TimeGenerated,

    SubscriptionId,

    ResourceGroup,

    ResourceId = tolower(tostring(ResourceId)),

    OperationNameValue,

    Caller = NormalizedCaller,

    CallerIpAddress = tostring(CallerIpAddress),

    ActivityStatusValue,

    CorrelationId,

    Properties;

SuspiciousAzureActivity

| join kind=inner VulnerableWorkloadIdentities

    on $left.Caller == $right.ManagedIdentityPrincipalId

| where not(CallerIpAddress in~ (ApprovedAzureAdminSourceIps))

| extend Priority = case(

    AssetCriticality in~ ("critical", "high"), "high",

    WorkloadType in~ ("aks-node", "container-host", "ci-runner"), "high",

    Environment =~ "production", "medium",

    "triage"

)

| project

    TimeGenerated,

    SubscriptionId,

    ResourceGroup,

    OperationNameValue,

    Caller,

    CallerIpAddress,

    ActivityStatusValue,

    ResourceId,

    Environment,

    WorkloadOwner,

    AssetCriticality,

    WorkloadType,

    Priority,

    CorrelationId,

    Properties

GCP

Detection Viability Assessment

GCP is conditionally viable for this behavior family when the affected Linux Compute Engine instance, managed-instance-group member, GKE worker node, container host, CI runner, build system, internet-facing workload, identity-adjacent system, privileged automation host, or high-value production workload is deployed in Google Cloud or when Google Cloud telemetry can be correlated with Linux host behavior observed elsewhere. GCP telemetry should not be treated as primary proof of local privilege escalation by itself unless it is joined to suspicious writable-path execution, abnormal low-privilege-to-root transition, root-level activity, sensitive-resource access, security-control degradation, persistence, service-account use, cloud metadata interaction, Kubernetes trust-material access, container-runtime interaction, or another credible host-compromise indicator. GCP detections are strongest when Google Cloud Admin Activity logs, Data Access logs, IAM and service-account activity, Security Command Center findings, VM Manager vulnerability data, Cloud Asset Inventory, Compute Engine activity, GKE activity, Secret Manager logs, Cloud Storage logs, Cloud KMS logs, VPC Flow Logs, Cloud DNS logs, and normalized Linux endpoint or audit telemetry are correlated in Google Security Operations, a SIEM, BigQuery, a data lake, or another analytics layer.

Rule

GCP Linux Privilege-Escalation Exposure and Workload Prioritization

Rule Format

Security Command Center, VM Manager, Cloud Asset Inventory, and BigQuery exposure-enrichment pattern.

Detection Purpose

·        Identify Google Cloud-hosted Linux workloads with active local privilege-escalation exposure.

·        Prioritize exposed or high-value Compute Engine instances, managed-instance-group members, GKE worker nodes, container hosts, CI runners, build systems, internet-facing workloads, identity-adjacent systems, privileged automation hosts, and production workloads.

·        Correlate exposure findings with organization and project context, workload ownership, operating-system state, service-account presence, public exposure, GKE context, asset criticality, and environment.

·        Support patching, hunting, containment prioritization, telemetry validation, and workload-owner notification without treating vulnerable state as proof of exploitation.

Detection Logic

·        Identify active and unmuted Security Command Center, VM Manager, or equivalent vulnerability findings associated with approved Linux local privilege-escalation exposure.

·        Exclude muted, resolved, terminated, deleted, or otherwise inactive findings and workloads.

·        Join exposure findings to Cloud Asset Inventory or equivalent Compute Engine and GKE inventory.

·        Prioritize internet-facing and high-criticality Linux workloads.

·        Prioritize GKE nodes, container hosts, CI runners, workloads with attached service accounts, and production systems.

·        Use exposure findings to scope investigation and remediation rather than declare successful exploitation.

·        Increase investigative urgency when exposure overlaps with suspicious host behavior, metadata access, Security Command Center findings, abnormal service-account activity, secret access, storage access, GKE credential activity, or other post-compromise indicators.

Required Telemetry

·        Security Command Center vulnerability findings.

·        VM Manager vulnerability findings where available.

·        Cloud Asset Inventory.

·        Compute Engine instance identity and operating-system context.

·        GKE cluster and node-pool context.

·        Instance state.

·        Kernel version.

·        Public-IP and internet-facing state.

·        Attached service-account context.

·        Workload type.

·        Workload owner.

·        Environment.

·        Asset criticality.

·        Active Linux privilege-escalation exposure list or maintained vulnerability set.

·        Optional Linux EDR, audit, process, identity, container, Kubernetes, and security-agent health telemetry.

Engineering Implementation Instructions

·        Maintain an approved and current set of Linux local privilege-escalation vulnerabilities or exposure findings covered by the report’s behavior model.

·        Populate the ApprovedLinuxPrivilegeEscalationIds and ApprovedLinuxPrivilegeEscalationPatterns arrays from Security Command Center, VM Manager, vulnerability-management, or exposure-management sources.

·        Validate Security Command Center, VM Manager, and Cloud Asset Inventory coverage across all relevant organizations, folders, projects, and regions.

·        Confirm that finding state, mute state, resource state, and finding freshness are normalized consistently.

·        Validate inventory coverage for Compute Engine instances, managed instance groups, GKE nodes, container hosts, CI runners, and ephemeral workloads.

·        Map organization IDs, folder IDs, project IDs, resource names, instance IDs, GKE node identities, hostnames, and endpoint asset identifiers consistently.

·        Normalize project IDs and resource names before joining findings to asset inventory.

·        Validate operating-system state, kernel version, workload type, owner, environment, internet exposure, service-account presence, and asset criticality.

·        Review stopped, deleted, autoscaled, rebuilt, recycled, or ephemeral assets for inventory drift.

·        Use the output for prioritization and hunting, not as proof that privilege escalation occurred.

·        Correlate high-priority results with host process, Linux audit, identity, metadata, GKE, container-runtime, Security Command Center, and Cloud Audit Log evidence.

·        Test table names, field names, data types, joins, vulnerability identifiers, pattern matching, resource-state handling, and project normalization before deployment.

·        Preserve the query as a single independently evaluable exposure-prioritization rule.

DRI Assessment

The rule is anchored to Linux privilege-escalation exposure, workload role, public exposure, service-account context, GKE placement, and business criticality rather than a single exploit artifact. It remains reusable as additional Linux local privilege-escalation vulnerabilities enter the maintained exposure set. The score is constrained because vulnerable workload state supports prioritization but does not establish exploitation.

DRI

8.0

TCR Assessment

Operational confidence depends on Security Command Center coverage, VM Manager coverage, Cloud Asset Inventory accuracy, vulnerability-set maintenance, label quality, project coverage, service-account mapping, workload ownership, finding freshness, and resource-state accuracy. Full-telemetry confidence improves when Compute Engine, GKE, service-account, public-exposure, workload-ownership, vulnerability-state, endpoint, Linux audit, and security-agent health telemetry are centrally correlated.

Operational TCR

7.8

Full-Telemetry TCR

8.8

Limitations

·        Vulnerable Google Cloud workload state is not exploitation evidence.

·        Security Command Center and VM Manager findings may lag behind actual patch state.

·        Ephemeral, autoscaled, stopped, deleted, rebuilt, replaced, or manually maintained instances may create inventory drift.

·        Missing labels, incomplete vulnerability coverage, fragmented project visibility, or weak service-account mapping can reduce prioritization accuracy.

·        A maintained Linux privilege-escalation vulnerability set is required.

·        Pattern-based finding matching can introduce false positives if the maintained patterns are too broad.

·        Host telemetry is required to determine whether suspicious staging, privilege transition, or root-level activity occurred.

·        Exposure prioritization may include vulnerabilities that do not match every technical detail of the governing behavior model.

·        Table names, field names, joins, identifiers, and enrichment logic must be adapted to the target Google Cloud export model.

Detection Query Pattern

Use this as a BigQuery, Security Command Center, VM Manager, and Cloud Asset Inventory exposure-enrichment pattern. Map table names, field names, approved vulnerability identifiers, matching patterns, and resource joins to the target Google Cloud export model before deployment.

-- BigQuery / Security Command Center / VM Manager / Cloud Asset Inventory pattern.

-- Table and field names must be adapted to the customer export model.

WITH parameters AS (

  SELECT

    [

      '<CVE_OR_FINDING_ID_1>',

      '<CVE_OR_FINDING_ID_2>'

    ] AS ApprovedLinuxPrivilegeEscalationIds,

    [

      '%<APPROVED_FINDING_PATTERN_1>%',

      '%<APPROVED_FINDING_PATTERN_2>%'

    ] AS ApprovedLinuxPrivilegeEscalationPatterns

),

vulnerable_findings AS (

  SELECT

    organization_id,

    folder_id,

    LOWER(project_id) AS project_id,

    LOWER(resource_name) AS resource_name,

    finding_id,

    vulnerability_id,

    category,

    severity,

    state,

    mute,

    event_time,

    update_time,

    finding_class,

    description

  FROM `security_command_center_findings`

  CROSS JOIN parameters

  WHERE state = 'ACTIVE'

    AND (mute IS NULL OR mute != 'MUTED')

    AND (

      vulnerability_id IN UNNEST(

        ApprovedLinuxPrivilegeEscalationIds

      )

      OR EXISTS (

        SELECT 1

        FROM UNNEST(

          ApprovedLinuxPrivilegeEscalationPatterns

        ) AS approved_pattern

        WHERE LOWER(COALESCE(description, ''))

          LIKE LOWER(approved_pattern)

           OR LOWER(COALESCE(category, ''))

          LIKE LOWER(approved_pattern)

           OR LOWER(COALESCE(finding_id, ''))

          LIKE LOWER(approved_pattern)

      )

    )

),

asset_context AS (

  SELECT

    LOWER(project_id) AS project_id,

    LOWER(resource_name) AS resource_name,

    asset_type,

    instance_id,

    instance_status,

    os_type,

    kernel_version,

    public_ip_present,

    internet_facing,

    service_account_email,

    gke_cluster,

    gke_node_pool,

    workload_type,

    workload_owner,

    environment,

    asset_criticality,

    labels

  FROM `cloud_asset_inventory_compute_instances`

  WHERE LOWER(COALESCE(os_type, '')) LIKE '%linux%'

    AND instance_status NOT IN ('TERMINATED', 'DELETED')

)

SELECT

  vf.organization_id,

  vf.folder_id,

  vf.project_id,

  vf.resource_name,

  ac.instance_id,

  vf.severity,

  ac.os_type,

  ac.kernel_version,

  ac.instance_status,

  ac.internet_facing,

  ac.service_account_email,

  ac.gke_cluster,

  ac.gke_node_pool,

  ac.workload_type,

  ac.workload_owner,

  ac.environment,

  ac.asset_criticality,

  CASE

    WHEN ac.internet_facing = TRUE

      AND LOWER(ac.asset_criticality) IN ('critical', 'high')

      THEN 'high'

    WHEN ac.gke_cluster IS NOT NULL

      OR ac.gke_node_pool IS NOT NULL

      OR LOWER(ac.workload_type) IN (

        'gke-node',

        'container-host',

        'ci-runner'

      )

      OR ac.service_account_email IS NOT NULL

      THEN 'high'

    WHEN LOWER(ac.environment) = 'production'

      THEN 'medium'

    ELSE 'triage'

  END AS priority

FROM vulnerable_findings AS vf

JOIN asset_context AS ac

  ON vf.project_id = ac.project_id

 AND vf.resource_name = ac.resource_name;

Rule

Post-Escalation GCP Service-Account and Control-Plane Activity After Suspected Linux Host Compromise

Rule Format

Cloud Audit Logs, Security Command Center, Cloud Asset Inventory, and BigQuery control-plane correlation pattern.

Detection Purpose

·        Detect Google Cloud control-plane activity that may follow root-level compromise of a Linux workload.

·        Identify suspicious use of attached service accounts involving IAM policy changes, service-account key creation, service-account impersonation, Secret Manager access, Cloud Storage access, Cloud KMS use, GKE activity, Compute Engine modification, firewall changes, snapshot activity, and image creation.

·        Detect privilege modification, secret retrieval, storage access, cryptographic-key use, workload-control activity, network-control modification, and image or snapshot creation associated with exposed or high-value Linux workloads.

·        Provide independently useful Google Cloud control-plane evidence without claiming that Google Cloud telemetry directly observed the local privilege-escalation event.

Detection Logic

·        Identify Google Cloud API activity from service accounts mapped to covered Compute Engine instances, GKE nodes, container hosts, CI runners, or other high-value Linux workloads.

·        Identify IAM policy changes, service-account key creation, service-account impersonation, Secret Manager access, Cloud Storage access, Cloud KMS decryption, GKE cluster activity, Compute Engine metadata or service-account modification, firewall changes, snapshot creation, and image creation.

·        Prioritize activity associated with Linux privilege-escalation exposure, critical or high-value workloads, GKE nodes, container hosts, CI runners, and production systems.

·        Require either an unexpected source IP or an unexpected user agent relative to approved cloud-administration and automation baselines.

·        Increase confidence when activity follows Security Command Center findings, suspicious host behavior, abnormal root-process activity, metadata access, security-agent degradation, Kubernetes trust-material access, container-runtime interaction, or another credible host-compromise signal.

·        Treat the result as possible cloud-side activity following workload compromise, not proof of how root access was obtained.

Required Telemetry

·        Google Cloud Admin Activity logs.

·        Google Cloud Data Access logs where required.

·        Security Command Center findings.

·        Cloud Asset Inventory.

·        IAM and service-account audit events.

·        Service-account-to-workload mapping.

·        Compute Engine instance identity.

·        GKE cluster and node-pool context.

·        Workload type.

·        Asset criticality.

·        Exposure state.

·        Principal email.

·        Caller IP.

·        User agent.

·        Service name.

·        Method name.

·        Resource name.

·        Request and response data.

·        Approved Google Cloud administration source list.

·        Approved Google Cloud automation user-agent list.

·        Optional Linux host-compromise, metadata-access, EDR, audit, Kubernetes, and container-host enrichment.

Engineering Implementation Instructions

·        Map attached service accounts to Compute Engine instances, GKE nodes, container hosts, CI runners, build systems, privileged automation, and high-value production workloads.

·        Maintain a linux_privilege_escalation_exposure field or equivalent normalized exposure value for covered Google Cloud Linux workloads.

·        Populate exposure status from Security Command Center, VM Manager, vulnerability-management, or exposure-management data.

·        Validate Cloud Audit Log coverage across all relevant organizations, folders, projects, and regions.

·        Confirm that Data Access logging is enabled where Secret Manager, Cloud Storage, and Cloud KMS activity must be detected.

·        Enable and aggregate Security Command Center findings where available.

·        Establish expected service-account behavior for production workloads, GKE nodes, CI systems, automation identities, backup identities, deployment systems, and managed services.

·        Maintain narrowly scoped approved source-IP and automation user-agent datasets.

·        Remove null or empty values from approved-source and approved-user-agent datasets before deployment.

·        Normalize service-account email addresses before joining audit activity to workload identity mappings.

·        Validate service-account-to-instance, service-account-to-node, and service-account-to-workload attribution.

·        Review NAT, proxies, Google-managed services, workload federation, automation platforms, and deployment systems that can affect caller-IP or user-agent context.

·        Correlate with host telemetry before describing the activity as suspected foothold-to-root compromise.

·        Test table names, nested-field access, joins, service-name coverage, method-name coverage, success-state handling, source-IP exclusions, user-agent exclusions, and query performance before deployment.

·        Preserve the query as a single independently evaluable Google Cloud control-plane rule.

DRI Assessment

The rule is anchored to post-escalation cloud activity and service-account-use behavior rather than static exploit artifacts. It remains useful when the local exploit, vulnerable subsystem, staging method, or kernel primitive changes because it focuses on the cloud-side consequences of compromised workload identities. The score is constrained because Google Cloud control-plane events do not directly prove the local privilege-escalation path.

DRI

8.4

TCR Assessment

Operational confidence depends on Cloud Audit Log coverage, Data Access log coverage, Security Command Center coverage, service-account mapping, workload attribution, exposure-state accuracy, approved automation baselines, source-IP context, user-agent context, and enrichment quality. Full-telemetry confidence improves when Cloud Audit Logs, Security Command Center, VM Manager, Cloud Asset Inventory, IAM, GKE, Secret Manager, Cloud Storage, Cloud KMS, Linux audit, endpoint, metadata-access, and host-compromise telemetry are centrally correlated.

Operational TCR

7.6

Full-Telemetry TCR

8.7

Limitations

·        Google Cloud control-plane activity may follow many compromise paths and is not unique to Linux local privilege escalation.

·        Cloud Audit Logs cannot directly observe local Linux privilege escalation.

·        Legitimate automation, deployment pipelines, backup operations, managed services, security tooling, incident response, and administrative activity may generate overlapping API events.

·        Service-account-to-workload mapping must be accurate to connect cloud activity to affected workloads.

·        Data Access logging may be required for Secret Manager, Cloud Storage, and Cloud KMS actions.

·        Source-IP and user-agent deviations can occur because of proxies, NAT, Google-managed services, federated access, automation changes, and legitimate operational shifts.

·        A missing caller IP or user agent can increase false-positive volume and must be handled according to the organization’s logging model.

·        The query identifies service-account activity associated with mapped workloads but does not prove that credentials were obtained from the workload.

·        Host telemetry is required for high-confidence assessment of suspicious staging, privilege transition, or root-level compromise.

·        Exposure state increases priority but does not prove that Google Cloud activity resulted from privilege escalation.

Detection Query Pattern

Use this as a BigQuery and Cloud Audit Logs SQL pattern. Map table names, service-account relationships, exposure fields, approved-source datasets, approved automation datasets, and logging exports to the target Google Cloud environment before deployment.

-- BigQuery / Cloud Audit Logs pattern.

-- Table names and fields must be adapted to the customer logging export.

WITH vulnerable_workload_identities AS (

  SELECT

    LOWER(project_id) AS project_id,

    LOWER(resource_name) AS resource_name,

    instance_id,

    LOWER(service_account_email) AS service_account_email,

    workload_type,

    workload_owner,

    environment,

    asset_criticality,

    internet_facing,

    gke_cluster,

    gke_node_pool

  FROM `gcp_vulnerable_linux_workload_service_account_map`

  WHERE linux_privilege_escalation_exposure = TRUE

     OR LOWER(asset_criticality) IN ('critical', 'high')

     OR LOWER(workload_type) IN (

       'compute',

       'gke-node',

       'container-host',

       'ci-runner'

     )

),

suspicious_audit_activity AS (

  SELECT

    timestamp,

    LOWER(resource.labels.project_id) AS project_id,

    protoPayload.serviceName AS service_name,

    protoPayload.methodName AS method_name,

    LOWER(

      protoPayload.authenticationInfo.principalEmail

    ) AS principal_email,

    protoPayload.requestMetadata.callerIp AS caller_ip,

    protoPayload.requestMetadata.callerSuppliedUserAgent AS user_agent,

    protoPayload.resourceName AS resource_name,

    IFNULL(protoPayload.status.code, 0) AS status_code,

    protoPayload.request AS request,

    protoPayload.response AS response

  FROM `gcp_cloud_audit_logs`

  WHERE protoPayload.serviceName IN (

      'iam.googleapis.com',

      'iamcredentials.googleapis.com',

      'secretmanager.googleapis.com',

      'storage.googleapis.com',

      'cloudkms.googleapis.com',

      'container.googleapis.com',

      'compute.googleapis.com'

    )

    AND protoPayload.methodName IN (

      'SetIamPolicy',

      'google.iam.admin.v1.CreateServiceAccountKey',

      'google.iam.credentials.v1.GenerateAccessToken',

      'google.cloud.secretmanager.v1.SecretManagerService.AccessSecretVersion',

      'storage.objects.get',

      'Decrypt',

      'google.container.v1.ClusterManager.GetCluster',

      'google.container.v1.ClusterManager.UpdateCluster',

      'v1.compute.instances.setMetadata',

      'v1.compute.instances.setServiceAccount',

      'v1.compute.firewalls.insert',

      'v1.compute.firewalls.patch',

      'v1.compute.disks.createSnapshot',

      'v1.compute.images.insert'

    )

    AND IFNULL(protoPayload.status.code, 0) = 0

),

approved_admin_sources AS (

  SELECT DISTINCT approved_source_ip

  FROM `approved_gcp_admin_sources`

  WHERE approved_source_ip IS NOT NULL

    AND approved_source_ip != ''

),

approved_automation_user_agents AS (

  SELECT DISTINCT approved_user_agent

  FROM `approved_gcp_automation_user_agents`

  WHERE approved_user_agent IS NOT NULL

    AND approved_user_agent != ''

)

SELECT

  saa.timestamp,

  saa.project_id,

  saa.service_name,

  saa.method_name,

  saa.principal_email,

  saa.caller_ip,

  saa.user_agent,

  saa.resource_name,

  vwi.instance_id,

  vwi.workload_type,

  vwi.workload_owner,

  vwi.environment,

  vwi.asset_criticality,

  vwi.internet_facing,

  vwi.gke_cluster,

  vwi.gke_node_pool,

  CASE

    WHEN LOWER(vwi.asset_criticality) IN ('critical', 'high')

      THEN 'high'

    WHEN LOWER(vwi.workload_type) IN (

      'gke-node',

      'container-host',

      'ci-runner'

    )

      THEN 'high'

    WHEN LOWER(vwi.environment) = 'production'

      THEN 'medium'

    ELSE 'triage'

  END AS priority

FROM suspicious_audit_activity AS saa

JOIN vulnerable_workload_identities AS vwi

  ON saa.principal_email = vwi.service_account_email

WHERE

  NOT EXISTS (

    SELECT 1

    FROM approved_admin_sources AS aas

    WHERE aas.approved_source_ip = saa.caller_ip

  )

  OR NOT EXISTS (

    SELECT 1

    FROM approved_automation_user_agents AS aua

    WHERE aua.approved_user_agent = saa.user_agent

  );

S26 Threat-to-Rule Traceability Matrix

Traceability Purpose

This section maps the primary behavioral threat conditions in this report to the S25 detection coverage developed across NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA, YARA, AWS, Azure, and GCP.

The traceability model is behavior-led. It does not rely on a single CVE identifier, exploit name, proof-of-concept artifact, repository reference, filename, hash, kernel primitive, syscall, package version, vulnerable-image label, or static indicator as the basis for coverage.

The governing behavior model is constrained or low-privilege execution followed by exploit staging, abnormal privilege transition, root-owned process activity, privileged-resource or trust-material access, security-control degradation, persistence, workload-boundary abuse, anomalous outbound communication, or downstream infrastructure expansion.

Coverage Scope

The S25 rule set provides coverage for the observable enterprise sequence associated with suspicious execution from writable or transient Linux paths; abnormal movement from low-privilege execution to root-owned activity; suspicious privileged-binary interaction; root-level credential, configuration, token, socket, or trust-material access; persistence; audit or security-control degradation; cloud metadata or workload-identity interaction; container-runtime and Kubernetes-node activity; anomalous outbound communication; east-west expansion; vulnerable-workload prioritization; and post-compromise AWS, Azure, or Google Cloud control-plane activity.

Coverage is strongest where Linux process telemetry, Linux audit records, process ancestry, real-user and effective-user context, file activity, privileged-binary execution, workload role, vulnerable-state history, security-agent health, container-to-host mapping, pod-to-node mapping, cloud-instance mapping, CI/CD context, DNS, proxy, firewall, NDR, network-flow, cloud-audit, identity, and asset-inventory telemetry can be joined through reliable host, workload, process, user, identity, resource, and time-window relationships.

Primary Coverage Areas

·        Suspicious non-root execution of shells, scripting engines, compilers, linkers, build tools, permission-modification tools, scripts, ELF binaries, temporary executables, or unfamiliar binaries from writable, transient, user-controlled, workspace, build, runner, mounted-volume, or container-layer paths

·        Rapid file creation, compilation, permission modification, execution, and deletion associated with possible local exploit staging

·        Abnormal effective-user, UID, or process-lineage transition from constrained execution to root-owned process activity

·        Root-owned shells, interpreters, privileged utilities, service processes, or other processes created from suspicious non-root, application, service, container, CI/CD, build, or writable-path parentage

·        Suspicious interaction with SUID-root binaries, setuid or setgid paths, authentication mechanisms, namespaces, mount functions, or other elevation mechanisms

·        Root-level access to credential stores, SSH material, service credentials, application secrets, cloud identity material, Kubernetes service-account tokens, kubelet resources, container-runtime sockets, host-mounted secrets, CI/CD credentials, repository credentials, or signing material

·        Root-level persistence, discovery, remote-access preparation, tunneling, service manipulation, credential use, lateral-movement preparation, or destructive activity

·        Security-agent, audit, logging, cloud-agent, vulnerability-scanner, container-security, or workload-protection degradation

·        Container-originated or pod-originated activity followed by unexpected host-level root execution, namespace activity, runtime-socket access, kubelet access, or host-mounted resource access

·        Rare or anomalous outbound communication from high-risk Linux workloads

·        Cloud metadata or workload-identity access followed by anomalous network or cloud-service activity

·        Abnormal east-west expansion from Linux workloads into trust-sensitive infrastructure

·        Exposure prioritization for Linux workloads in AWS, Azure, and Google Cloud

·        Post-compromise AWS credential, role, secret, storage, remote-command, snapshot, network-control, or control-plane activity

·        Post-compromise Azure managed-identity, VM Run Command, role, AKS, Storage, disk, snapshot, network-control, or control-plane activity

·        Post-compromise Google Cloud service-account, IAM, Secret Manager, Cloud Storage, Cloud KMS, GKE, Compute Engine, firewall, snapshot, image, or control-plane activity

Traceability Mapping

Suspicious Exploit Staging From Writable or Transient Linux Paths

This behavior is covered where Linux process, file, user, effective-user, command-line, working-directory, executable-path, parent-process, workload-role, and approved-workflow telemetry can identify suspicious execution from writable or transient locations.

Mapped Coverage

·        SentinelOne coverage through Suspicious Linux Exploit Staging and Execution From Writable Paths

·        Splunk coverage through Suspicious Linux Execution From Writable or Transient Paths

·        Elastic coverage through Suspicious Linux Execution From Writable or Transient Paths

·        QRadar coverage through Suspicious Linux Exploit Staging Followed by Abnormal Privilege Transition

·        SIGMA coverage through Writable-Path Exploit Staging on Linux Workloads

·        NDR supporting coverage through Rare Outbound Communication From High-Risk Linux Workloads when staging is followed by anomalous egress

·        AWS, Azure, and GCP exposure-prioritization rules provide supporting workload context but do not directly detect local staging

Coverage Qualification

·        Writable-path execution alone is not sufficient

·        Compilation alone is not sufficient

·        Script execution alone is not sufficient

·        Interpreter execution alone is not sufficient

·        A proof-of-concept filename, repository reference, hash, or exploit string is not sufficient

·        Coverage requires suspicious process context, affirmative non-root identity, workload context, path context, approved-workflow exclusion, privilege-transition evidence, post-root behavior, or another corroborating signal

·        Approved CI/CD builds, software compilation, package installation, deployment, configuration management, vulnerability validation, incident response, development, and maintenance activity require suppression or downgrade when expected context aligns

Abnormal Low-Privilege-to-Root Process Transition

This behavior is covered where process ancestry, source-user, effective-user, UID, effective UID, parent process, child process, executable path, command line, and host-role telemetry can establish an abnormal privilege-boundary outcome.

Mapped Coverage

·        SentinelOne coverage through Abnormal Low-Privilege-to-Root Process Transition

·        Splunk coverage through Suspicious Root Process From Non-Administrative or Writable-Path Parent Context

·        Elastic coverage through Abnormal Low-Privilege-to-Root Process Transition

·        QRadar coverage through Abnormal Low-Privilege-to-Root Execution Followed by High-Risk Root Activity

·        SIGMA coverage through Abnormal Low-Privilege-to-Root Process Transition

·        NDR supporting coverage through Rare Outbound Communication From High-Risk Linux Workloads or Abnormal East-West Expansion From Linux Workloads when network behavior follows suspected host compromise

·        AWS, Azure, and GCP post-compromise rules provide downstream cloud evidence but do not directly observe the local transition

Coverage Qualification

·        A root-owned process alone is not sufficient

·        A shell running as root alone is not sufficient

·        Sudo activity alone is not sufficient

·        A privileged utility invocation alone is not sufficient

·        A UID of zero alone is not sufficient

·        Coverage requires suspicious parentage, constrained-user origin, writable-path context, abnormal process lineage, unapproved administrative context, sensitive-resource access, security-control degradation, persistence, or downstream expansion

·        Approved sudo, privilege-management, package-management, service-management, orchestration, configuration-management, deployment, backup, monitoring, security, incident-response, and maintenance workflows require baseline validation

Suspicious Privileged-Binary, SUID, Authentication, Namespace, or Mount Interaction

This behavior is covered where privileged utility execution, SUID-root interaction, authentication events, namespace activity, mount activity, parent-process context, and user-transition telemetry can be joined to suspicious staging or abnormal root-process creation.

Mapped Coverage

·        SentinelOne coverage through Abnormal Low-Privilege-to-Root Process Transition where privileged-binary, SUID, authentication, namespace, or mount activity precedes an abnormal root-owned process outcome

·        Splunk coverage through Suspicious Root Process From Non-Administrative or Writable-Path Parent Context

·        Elastic coverage through Abnormal Low-Privilege-to-Root Process Transition

·        QRadar coverage through Suspicious Linux Exploit Staging Followed by Abnormal Privilege Transition and Abnormal Low-Privilege-to-Root Execution Followed by High-Risk Root Activity

·        SIGMA coverage through Abnormal Low-Privilege-to-Root Process Transition

·        Linux audit, EDR, eBPF, syscall, kernel, crash, and fault telemetry provide optional supporting evidence

Coverage Qualification

·        SUID execution alone is not sufficient

·        Setuid or setgid activity alone is not sufficient

·        Namespace activity alone is not sufficient

·        Mount activity alone is not sufficient

·        Authentication activity alone is not sufficient

·        Kernel, syscall, crash, or fault evidence alone is not sufficient

·        Coverage requires suspicious origin, abnormal parentage, low-privilege context, unexpected root outcome, sensitive-resource access, defensive-control change, persistence, or related post-exploitation behavior

·        Distribution-specific, service-specific, container, package, orchestration, and administrative baselines must be validated before production alerting

Suspicious Root-Level Credential, Secret, and Trust-Material Access

This behavior is covered where root-level process, command-line, file, audit, identity, and workload telemetry can identify access to credentials, keys, tokens, sockets, metadata paths, or other trust-sensitive resources.

Mapped Coverage

·        SentinelOne coverage through Suspicious Root-Level Sensitive Resource Access or Security-Control Modification

·        Splunk coverage through Suspicious Root-Level Sensitive Resource Access or Security-Control Modification

·        Elastic coverage through Suspicious Root-Level Sensitive Resource Access or Security-Control Modification

·        QRadar coverage through Suspicious Root-Level Sensitive-Resource Activity or Confirmed Security-Control Degradation

·        SIGMA coverage through Suspicious Post-Root Activity on Linux Workloads

·        NDR supporting coverage through Cloud Metadata or Workload Identity Access Followed by Anomalous Activity

·        AWS coverage through Post-Escalation AWS Credential and Control-Plane Activity After Suspected Linux Host Compromise

·        Azure coverage through Post-Escalation Azure Managed-Identity and Control-Plane Activity After Suspected Linux Host Compromise

·        GCP coverage through Post-Escalation GCP Service-Account and Control-Plane Activity After Suspected Linux Host Compromise

Coverage Qualification

·        Access to /etc/shadow alone is not sufficient

·        Access to /etc/sudoers alone is not sufficient

·        Access to /root/.ssh alone is not sufficient

·        Access to a Kubernetes service-account token alone is not sufficient

·        Access to a container-runtime socket alone is not sufficient

·        Access to cloud metadata alone is not sufficient

·        Coverage requires root or effective-root context plus suspicious process lineage, abnormal timing, workload context, privilege-transition evidence, unapproved activity, network behavior, or downstream identity use

·        Approved backup, monitoring, vulnerability scanning, configuration management, secret rotation, Kubernetes administration, container management, incident response, and forensic collection require local baseline validation

Persistence and Security-Control Degradation

This behavior is covered where root-level process, file, service, audit, endpoint-health, logging, telemetry-forwarding, or security-agent events identify suspicious persistence or defensive-control modification.

Mapped Coverage

·        SentinelOne coverage through Suspicious Root-Level Sensitive Resource Access or Security-Control Modification

·        Splunk coverage through Suspicious Root-Level Sensitive Resource Access or Security-Control Modification

·        Elastic coverage through Suspicious Root-Level Sensitive Resource Access or Security-Control Modification

·        QRadar coverage through Suspicious Root-Level Sensitive-Resource Activity or Confirmed Security-Control Degradation

·        SIGMA coverage through Suspicious Post-Root Activity on Linux Workloads

·        NDR supporting coverage through Rare Outbound Communication From High-Risk Linux Workloads or Abnormal East-West Expansion From Linux Workloads when control degradation is followed by network expansion

Coverage Qualification

·        A service stop alone is not sufficient

·        An audit-policy change alone is not sufficient

·        A firewall modification alone is not sufficient

·        A cron, systemd, shell-profile, or SSH-key change alone is not sufficient

·        Security-agent failure alone is not sufficient

·        Coverage requires suspicious root context, abnormal process lineage, unapproved workflow, temporal proximity to staging or privilege transition, or corroborating sensitive-resource, persistence, network, or expansion evidence

·        Approved patching, troubleshooting, endpoint management, incident response, security testing, logging maintenance, firewall administration, and configuration-management activity require suppression or downgrade

Container, Kubernetes, and Workload-Boundary Abuse

This behavior is covered where container, pod, namespace, node, kubelet, runtime, host-process, file, identity, and workload telemetry can link container-originated or pod-originated activity to host-level root behavior or trust-sensitive resource access.

Mapped Coverage

·        SentinelOne coverage through Abnormal Low-Privilege-to-Root Process Transition and Suspicious Root-Level Sensitive Resource Access or Security-Control Modification

·        Splunk coverage through Suspicious Root Process From Non-Administrative or Writable-Path Parent Context and Suspicious Root-Level Sensitive Resource Access or Security-Control Modification

·        Elastic coverage through Abnormal Low-Privilege-to-Root Process Transition and Suspicious Root-Level Sensitive Resource Access or Security-Control Modification

·        QRadar coverage through Suspicious Linux Exploit Staging Followed by Abnormal Privilege Transition, Abnormal Low-Privilege-to-Root Execution Followed by High-Risk Root Activity, and Suspicious Root-Level Sensitive-Resource Activity or Confirmed Security-Control Degradation

·        SIGMA coverage through Abnormal Low-Privilege-to-Root Process Transition and Suspicious Post-Root Activity on Linux Workloads

·        NDR coverage through Cloud Metadata or Workload Identity Access Followed by Anomalous Activity and Abnormal East-West Expansion From Linux Workloads

·        AWS coverage through AWS Linux Privilege-Escalation Exposure and Workload Prioritization and Post-Escalation AWS Credential and Control-Plane Activity After Suspected Linux Host Compromise

·        Azure coverage through Azure Linux Privilege-Escalation Exposure and Workload Prioritization and Post-Escalation Azure Managed-Identity and Control-Plane Activity After Suspected Linux Host Compromise

·        GCP coverage through GCP Linux Privilege-Escalation Exposure and Workload Prioritization and Post-Escalation GCP Service-Account and Control-Plane Activity After Suspected Linux Host Compromise

Coverage Qualification

·        Container activity alone is not sufficient

·        Kubernetes API activity alone is not sufficient

·        Runtime-socket access alone is not sufficient

·        HostPath use alone is not sufficient

·        Node-level process activity alone is not sufficient

·        Coverage requires Linux host, process, user, workload, node, container, pod, namespace, resource, identity, or bounded-time correlation

·        Approved Kubernetes operations, container management, node maintenance, orchestration, deployment, autoscaling, backup, monitoring, incident response, and security tooling require local baseline validation

Rare or Anomalous Outbound Communication From High-Risk Linux Workloads

This behavior is covered where NDR, DNS, proxy, firewall, cloud-flow, and endpoint-network telemetry can identify role-inconsistent outbound communication from Linux workloads.

Mapped Coverage

·        NDR / Network Behavioral Analytics coverage through Rare Outbound Communication From High-Risk Linux Workloads

·        SentinelOne supporting coverage where outbound communication is attributable to a suspicious or newly created process

·        Splunk, Elastic, and QRadar supporting coverage where network telemetry and host context are ingested into the same analytics environment

·        AWS, Azure, and GCP supporting coverage where outbound activity reaches metadata, identity, secret, storage, repository, deployment, or infrastructure-management services

Coverage Qualification

·        Rare egress alone is not sufficient

·        A new destination alone is not sufficient

·        A suspicious domain alone is not sufficient

·        An unusual destination port alone is not sufficient

·        A single outbound connection alone is not sufficient

·        Coverage requires role-aware deviation, destination enrichment, connection cadence, recurrence, suspicious process or host context, workload criticality, metadata access, privilege activity, or another corroborating behavior

·        Approved updates, package repositories, code repositories, artifact registries, container registries, cloud services, backup, monitoring, telemetry, vulnerability management, orchestration, deployment, vendor support, and incident response require tightly scoped exceptions

Cloud Metadata or Workload-Identity Access Followed by Anomalous Activity

This behavior is covered where metadata, managed-identity, workload-identity, service-account-token, token-broker, network, cloud-service, and optional cloud-audit telemetry can be correlated to the same canonical Linux workload.

Mapped Coverage

·        NDR / Network Behavioral Analytics coverage through Cloud Metadata or Workload Identity Access Followed by Anomalous Activity

·        SentinelOne, Splunk, Elastic, QRadar, and SIGMA supporting coverage where metadata access, token paths, command-line behavior, or process context is visible

·        AWS coverage through Post-Escalation AWS Credential and Control-Plane Activity After Suspected Linux Host Compromise

·        Azure coverage through Post-Escalation Azure Managed-Identity and Control-Plane Activity After Suspected Linux Host Compromise

·        GCP coverage through Post-Escalation GCP Service-Account and Control-Plane Activity After Suspected Linux Host Compromise

Coverage Qualification

·        Metadata access alone is not sufficient

·        Token-endpoint access alone is not sufficient

·        A workload-identity request alone is not sufficient

·        Cloud-service access alone is not sufficient

·        Coverage requires anomalous follow-on communication, sensitive cloud-service access, unexpected workload identity, unusual cadence, new or rare behavior, unapproved source context, or cloud-audit corroboration

·        Cloud-audit enrichment increases confidence but is not required for the underlying NDR network sequence

·        Approved initialization, cloud-agent, autoscaling, orchestration, monitoring, backup, deployment, and workload-identity activity require baseline validation

Abnormal East-West Expansion Into Trust-Sensitive Infrastructure

This behavior is covered where internal NDR, firewall, DNS, proxy, flow, asset-role, service-family, peer-group, and workload-identity telemetry can identify role-inconsistent internal expansion.

Mapped Coverage

·        NDR / Network Behavioral Analytics coverage through Abnormal East-West Expansion From Linux Workloads

·        SentinelOne supporting coverage where internal connections are attributable to suspicious processes

·        Splunk, Elastic, and QRadar supporting coverage where endpoint, identity, network, asset, and service-role telemetry are centrally correlated

·        AWS, Azure, and GCP supporting coverage where expansion reaches cloud identities, control planes, storage, secrets, Kubernetes services, or management resources

Coverage Qualification

·        Internal communication alone is not sufficient

·        SSH activity alone is not sufficient

·        A new internal destination alone is not sufficient

·        One administrative-service connection alone is not sufficient

·        Coverage requires deviation from expected peer groups or service families plus role-aware fan-out, unique-destination, unique-port, rate-change, scan, or protected-service thresholds

·        Approved orchestration, configuration management, vulnerability scanning, backup, monitoring, deployment, asset discovery, administration, red-team, and incident-response activity require suppression or downgrade

AWS Linux Workload Exposure and Post-Compromise Activity

This behavior is covered where Inspector, Security Hub, AWS Config, CloudTrail, GuardDuty, IAM, STS, Systems Manager, Secrets Manager, KMS, EC2, EKS, S3, and Linux host telemetry can be correlated.

Mapped Coverage

·        AWS Linux Privilege-Escalation Exposure and Workload Prioritization

·        Post-Escalation AWS Credential and Control-Plane Activity After Suspected Linux Host Compromise

·        Splunk, Elastic, and QRadar provide supporting coverage where AWS telemetry and Linux host context are ingested into the same analytics environment

·        NDR provides supporting coverage through Cloud Metadata or Workload Identity Access Followed by Anomalous Activity, Rare Outbound Communication From High-Risk Linux Workloads, and Abnormal East-West Expansion From Linux Workloads

Coverage Qualification

·        AWS vulnerable-workload state alone is not sufficient

·        IAM role activity alone is not sufficient

·        Role assumption alone is not sufficient

·        Secrets Manager, KMS, Systems Manager, EC2, EKS, S3, or STS activity alone is not sufficient

·        Coverage requires workload-to-role mapping, exposure or criticality context, unexpected source or user-agent behavior, suspicious host evidence, GuardDuty context, or other credible workload-compromise linkage

·        CloudTrail cannot directly observe local Linux privilege escalation

·        Approved automation, deployment, backup, Systems Manager, security, administrative, and incident-response activity require baseline validation

Azure Linux Workload Exposure and Post-Compromise Activity

This behavior is covered where Defender for Cloud, Microsoft Defender Vulnerability Management, Azure Resource Graph, Azure Activity, Microsoft Entra ID, AKS, managed-identity, VM Run Command, Storage, network-control, endpoint, and Linux audit telemetry can be correlated.

Mapped Coverage

·        Azure Linux Privilege-Escalation Exposure and Workload Prioritization

·        Post-Escalation Azure Managed-Identity and Control-Plane Activity After Suspected Linux Host Compromise

·        Splunk, Elastic, and QRadar provide supporting coverage where Azure telemetry and Linux host context are ingested into the same analytics environment

·        NDR provides supporting coverage through Cloud Metadata or Workload Identity Access Followed by Anomalous Activity, Rare Outbound Communication From High-Risk Linux Workloads, and Abnormal East-West Expansion From Linux Workloads

Coverage Qualification

·        Azure vulnerable-workload state alone is not sufficient

·        Managed-identity activity alone is not sufficient

·        VM Run Command activity alone is not sufficient

·        Role, AKS, Storage, disk, snapshot, or network-control activity alone is not sufficient

·        Coverage requires accurate system-assigned managed-identity-to-workload mapping, exposure or criticality context, unapproved source context, suspicious host evidence, Defender findings, or other credible workload-compromise linkage

·        The Azure control-plane rule does not directly cover user-assigned managed identities, service principals, or federated workload identities

·        Azure Activity cannot directly observe local Linux privilege escalation

·        Approved automation, deployment, VM extension, backup, security, administrative, and incident-response activity require baseline validation

GCP Linux Workload Exposure and Post-Compromise Activity

This behavior is covered where Security Command Center, VM Manager, Cloud Asset Inventory, Cloud Audit Logs, IAM, service-account activity, Secret Manager, Cloud Storage, Cloud KMS, GKE, Compute Engine, and Linux host telemetry can be correlated.

Mapped Coverage

·        GCP Linux Privilege-Escalation Exposure and Workload Prioritization

·        Post-Escalation GCP Service-Account and Control-Plane Activity After Suspected Linux Host Compromise

·        Splunk, Elastic, and QRadar provide supporting coverage where Google Cloud audit telemetry and Linux host context are ingested into the same analytics environment

·        NDR provides supporting coverage through Cloud Metadata or Workload Identity Access Followed by Anomalous Activity, Rare Outbound Communication From High-Risk Linux Workloads, and Abnormal East-West Expansion From Linux Workloads

Coverage Qualification

·        Google Cloud vulnerable-workload state alone is not sufficient

·        Service-account activity alone is not sufficient

·        IAM, Secret Manager, Cloud Storage, Cloud KMS, GKE, Compute Engine, firewall, snapshot, or image activity alone is not sufficient

·        Coverage requires accurate service-account-to-workload mapping, exposure or criticality context, unexpected source-IP or user-agent behavior, suspicious host evidence, Security Command Center context, or another credible workload-compromise linkage

·        Cloud Audit Logs cannot directly observe local Linux privilege escalation

·        Data Access logging is required for some Secret Manager, Cloud Storage, and Cloud KMS actions

·        Approved automation, deployment, backup, managed-service, security, administrative, and incident-response activity require baseline validation

NDR / Network Behavioral Analytics Coverage Disposition

NDR / Network Behavioral Analytics provides primary network-behavior coverage through Rare Outbound Communication From High-Risk Linux Workloads, Cloud Metadata or Workload Identity Access Followed by Anomalous Activity, and Abnormal East-West Expansion From Linux Workloads.

NDR can identify durable post-compromise communication and expansion behavior but cannot directly observe the local privilege-transition mechanism or independently prove that root access was obtained.

NDR coverage depends on canonical workload identity resolution, source attribution, Linux asset grouping, role-aware baselines, destination enrichment, east-west visibility, metadata-endpoint mapping, cloud-service classification, approved-service exceptions, service-family mapping, and bounded-time correlation.

SentinelOne Coverage Disposition

SentinelOne provides primary endpoint-behavior coverage through Suspicious Linux Exploit Staging and Execution From Writable Paths, Abnormal Low-Privilege-to-Root Process Transition, and Suspicious Root-Level Sensitive Resource Access or Security-Control Modification.

Coverage is strongest where process lineage, real-user and effective-user context, UID fields, executable paths, working directories, file events, endpoint tags, security-agent events, network connections, and container or Kubernetes context are available.

SentinelOne does not independently prove the underlying kernel exploit primitive and should not attribute cloud, Kubernetes, repository, CI/CD, or control-plane activity to Linux privilege escalation without additional correlation.

Splunk Coverage Disposition

Splunk provides primary SIEM correlation and enrichment coverage through Suspicious Linux Execution From Writable or Transient Paths, Suspicious Root Process From Non-Administrative or Writable-Path Parent Context, and Suspicious Root-Level Sensitive Resource Access or Security-Control Modification.

Coverage depends on normalized process, file, audit, identity, workload, cloud, Kubernetes, container, security-control, network, and asset-context fields.

Splunk can correlate host and downstream activity but cannot prove the underlying privilege-escalation mechanism from normalized events alone.

Elastic Coverage Disposition

Elastic provides primary endpoint and ECS-aligned coverage through Suspicious Linux Execution From Writable or Transient Paths, Abnormal Low-Privilege-to-Root Process Transition, and Suspicious Root-Level Sensitive Resource Access or Security-Control Modification.

Coverage depends on effective-identity fidelity, ECS or local-field normalization, parent-child process linkage, file-event coverage, exception quality, and workload enrichment.

Elastic should not classify isolated writable-path execution, root activity, sensitive-file activity, or cloud events as confirmed privilege escalation.

QRadar Coverage Disposition

QRadar provides primary SIEM correlation and offense-generation coverage through Suspicious Linux Exploit Staging Followed by Abnormal Privilege Transition, Abnormal Low-Privilege-to-Root Execution Followed by High-Risk Root Activity, and Suspicious Root-Level Sensitive-Resource Activity or Confirmed Security-Control Degradation.

Coverage depends on validated DSM parsing, custom properties, effective-user and UID fields, parent-process context, file-event mapping, hostname normalization, reference-set quality, exposure-state enrichment, and workload-role context.

QRadar cannot prove the underlying exploit mechanism and must treat exploit staging, root-process activity, and post-root behavior as behavioral evidence rather than exploit attribution.

SIGMA Coverage Disposition

SIGMA provides portable event-rule template coverage through Writable-Path Exploit Staging on Linux Workloads, Abnormal Low-Privilege-to-Root Process Transition, and Suspicious Post-Root Activity on Linux Workloads.

SIGMA is useful for backend-mappable event logic but should not be treated as a complete backend-independent multi-event sequence-correlation layer. Local field mapping, backend translation, effective-user handling, file-event translation, exception validation, enrichment, and SIEM-native correlation remain required.

YARA Coverage Disposition

YARA has zero deployable rules for this EXP report.

YARA is not viable as a primary S25 detection system because the report’s governing model is behavioral, sequence-based, privilege-transition driven, process-context based, Linux audit and endpoint-telemetry driven, sensitive-resource access based, control-degradation based, persistence based, workload-boundary based, network-behavior based, and cloud-context based rather than static-file, malware-signature, or artifact-matching based.

YARA may provide limited supporting value only if a confirmed malicious exploit file, compiled payload, script artifact, loader, dropper, shared object, kernel-module artifact, container-layer artifact, archive artifact, memory artifact, persistence implant, credential-theft tool, cloud-token harvesting artifact, Kubernetes trust-material collection utility, container-runtime abuse tool, or reusable malware-family artifact is recovered and independently validated.

Final YARA Outcome

No YARA rules survive.

Coverage Gaps and Non-Coverage Conditions

The S25 rule set does not directly prove the underlying Linux kernel exploit, memory-corruption path, race condition, synchronization flaw, filesystem primitive, namespace abuse, SUID mechanism, authentication flaw, or other technical privilege-escalation mechanism.

The S25 rule set also does not independently prove credential theft, container escape, Kubernetes compromise, cloud compromise, repository compromise, CI/CD compromise, lateral movement, persistence, defensive-control degradation, or data theft without the required behavior and context linkage.

Coverage Weakens Under the Following Conditions

·        Linux process, command-line, executable-path, working-directory, process-ancestry, real-user, effective-user, UID, or effective-UID telemetry is missing, truncated, delayed, or inconsistently normalized

·        Linux audit, EDR, Sysmon for Linux, osquery, eBPF, kernel, crash, fault, journal, or security-agent telemetry is unavailable

·        Writable, transient, build, workspace, runner, mounted-volume, container-layer, privileged, sensitive-resource, persistence, and security-tool paths are incomplete or stale

·        Container-to-host, pod-to-node, namespace-to-workload, cloud-instance-to-host, CI-runner-to-host, or identity-to-workload mappings are unreliable

·        Vulnerable-state history, kernel state, package state, image state, live-patch state, backport status, reboot status, or exposure history is unavailable or inaccurate

·        Root-owned process activity cannot be linked to a source user, effective user, parent process, process lineage, workload role, container, pod, node, CI job, service account, or administrative workflow

·        Sensitive-file, token, socket, secret, credential, metadata, kubelet, runtime, repository, signing-material, or host-mounted resource access is not logged

·        Security-agent, audit, logging, telemetry-forwarding, cloud-agent, vulnerability-scanner, container-security, or workload-protection health is not monitored

·        Approved sudo, privilege-management, package-management, service-management, orchestration, configuration-management, CI/CD, backup, monitoring, vulnerability-validation, deployment, maintenance, incident-response, and red-team workflows are not tightly scoped

·        NDR source attribution is obscured by NAT, proxies, shared gateways, overlays, service meshes, container networking, Kubernetes networking, or centralized egress

·        Canonical workload identity resolution, role-aware destination baselines, expected peer groups, service-family mapping, and approved network paths are incomplete

·        Link-local metadata traffic, managed-identity traffic, service-account-token activity, or local token-broker traffic is not visible

·        CloudTrail, GuardDuty, Security Hub, Inspector, AWS Config, IAM, STS, Systems Manager, Secrets Manager, KMS, EC2, EKS, S3, or relevant AWS data-event coverage is disabled or incomplete

·        Azure Activity, Defender for Cloud, Resource Graph, Microsoft Entra ID, AKS, managed-identity, VM Run Command, Storage, network-control, or endpoint telemetry is disabled or incomplete

·        Security Command Center, VM Manager, Cloud Asset Inventory, Cloud Audit Logs, Data Access logs, IAM, service-account, Secret Manager, Cloud Storage, Cloud KMS, GKE, or Compute Engine telemetry is disabled or incomplete

·        Cloud role, managed-identity, or service-account mappings cannot be tied back to the originating Linux workload

·        Source-IP, user-agent, identity, role, principal, resource, account, subscription, project, region, or time-window context is unreliable

·        Adversary activity blends into approved administration, automation, package management, deployment, build, orchestration, backup, monitoring, security tooling, vendor support, managed services, incident response, or maintenance

·        Attackers use existing trusted binaries, approved destinations, expected peer relationships, normal cloud identities, low-and-slow timing, in-memory execution, or existing root processes

·        Exploit artifacts are renamed, recompiled, embedded, encrypted, deleted, or never written to disk

·        Security-control degradation removes the telemetry required to confirm later activity

·        Ephemeral workloads, containers, nodes, CI runners, or cloud instances are terminated, recycled, rebuilt, or replaced before evidence is preserved

·        No observable staging, privilege transition, root-owned process activity, sensitive-resource access, defensive-control change, persistence, network behavior, workload-boundary activity, or downstream cloud activity occurs

Traceability Conclusion

The S25 detection set provides broad behavior-led coverage across suspicious exploit staging, abnormal low-privilege-to-root transition, privileged-binary interaction, root-level sensitive-resource access, persistence, security-control degradation, container and Kubernetes trust-boundary activity, rare outbound communication, cloud metadata or workload-identity access, east-west expansion, cloud workload exposure, and downstream AWS, Azure, and Google Cloud control-plane activity.

The strongest direct host-behavior coverage is provided by SentinelOne, Splunk, Elastic, QRadar, and SIGMA-translated logic. NDR / Network Behavioral Analytics provides strong supporting and independently useful post-compromise network coverage. AWS, Azure, and GCP provide exposure prioritization and downstream cloud-activity coverage but do not independently confirm local Linux privilege escalation. YARA has no deployable rule because the governing report model is behavioral rather than artifact-driven.

The rule set intentionally avoids CVE-only, exploit-name-only, proof-of-concept-only, filename-only, hash-only, repository-only, kernel-version-only, syscall-only, SUID-only, root-process-only, sensitive-file-only, cloud-event-only, network-event-only, or vulnerable-state-only conclusions. Detection confidence depends on correlating constrained execution, staging, privilege transition, root activity, privileged-resource access, trust-material exposure, defensive-control change, persistence, workload-boundary interaction, network behavior, and downstream infrastructure activity rather than treating any single event category as proof of compromise.

S27 Behavior & Log Artifacts

Purpose

This section identifies the primary behavior and log artifacts that support detection, investigation, triage, and validation for suspicious Linux exploit staging; abnormal low-privilege-to-root transition; privileged-binary interaction; root-level sensitive-resource access; persistence; security-control degradation; container, Kubernetes, and workload-boundary abuse; anomalous outbound communication; east-west expansion; cloud workload exposure; and downstream AWS, Azure, and Google Cloud control-plane activity.

The artifacts below are behavior-led. They should not be treated as proof of a specific Linux vulnerability, exploit, kernel primitive, privilege-escalation mechanism, credential theft, container escape, Kubernetes compromise, cloud compromise, malicious persistence, successful lateral movement, malicious security-control degradation, or data theft unless they are correlated into a coherent sequence.

Primary Artifact Categories

·        Linux process, process-ancestry, user, effective-user, UID, effective UID, executable-path, working-directory, command-line, and file artifacts

·        Writable-path, transient-path, build-path, workspace, runner, mounted-volume, container-layer, compilation, permission-modification, execution, and deletion artifacts

·        Root-owned process, privileged-binary, SUID, setuid, setgid, authentication, namespace, mount, and process-transition artifacts

·        Credential, SSH, token, cloud metadata, service-account token, kubelet, container-runtime socket, repository, signing-material, secret, and host-mounted trust-material artifacts

·        Cron, systemd, shell-profile, SSH-key, service, startup, persistence, and remote-access preparation artifacts

·        Audit, logging, endpoint-security, cloud-agent, workload-protection, container-security, vulnerability-scanner, firewall, and telemetry-forwarding health artifacts

·        Container, pod, namespace, node, runtime, kubelet, host-process, HostPath, and workload-boundary artifacts

·        DNS, proxy, firewall, NDR, destination-reputation, first-seen, ASN, geography, protocol, destination-port, egress, and east-west network artifacts

·        AWS, Azure, and Google Cloud workload-exposure and post-compromise control-plane artifacts

·        Host, workload, process, user, container, pod, node, cloud resource, identity, destination, and event-timestamp correlation artifacts

Linux Exploit-Staging and Writable-Path Artifacts

Relevant Artifacts

Process name, executable path, working directory, command line, parent process, grandparent process, process ID, parent process ID, real user, effective user, UID, effective UID, group ID, effective group ID, file path, file name, file type, file creation, file modification, permission change, ownership change, execution event, deletion event, compiler execution, linker execution, build-tool execution, archive extraction, script execution, shell execution, interpreter execution, transfer-tool execution, temporary executable, ELF file, writable-path indicator, transient-path indicator, user-controlled path, build workspace, CI runner workspace, mounted volume, container-layer path, workload role, approved workflow, and event timestamp.

Useful Log Sources

·        SentinelOne endpoint telemetry

·        Linux audit records

·        Auditd

·        Sysmon for Linux

·        Elastic Defend

·        Elastic Endpoint

·        Splunk-ingested Linux process and file telemetry

·        QRadar-normalized Linux events

·        EDR process and file telemetry

·        osquery

·        eBPF telemetry

·        File-integrity monitoring

·        CI/CD runner logs

·        Build-system logs

·        Container-runtime logs

·        Kubernetes audit and node telemetry

·        SIEM-normalized Linux telemetry

Detection Use

These artifacts support detection when non-root or constrained execution launches shells, interpreters, compilers, linkers, permission-modification tools, scripts, unfamiliar binaries, or temporary executables from writable, transient, build, runner, mounted-volume, or container-layer paths. They are strongest when staging activity is followed by abnormal root-owned process creation, sensitive-resource access, persistence, security-control degradation, metadata access, rare egress, or east-west expansion.

Investigation Use

Investigators should determine whether the activity is expected for development, software compilation, package installation, CI/CD, deployment, configuration management, vulnerability validation, incident response, maintenance, container initialization, or approved build workflows. They should review process ancestry, user context, executable origin, file creation and deletion timing, workload role, asset criticality, and subsequent privilege-transition or post-root behavior.

Non-Coverage Conditions

Writable-path execution alone is not sufficient. Compiler execution alone is not sufficient. Script execution alone is not sufficient. A temporary binary alone is not sufficient. A proof-of-concept filename, repository path, exploit string, or hash is not sufficient. These artifacts require suspicious process context, affirmative non-root identity, workload context, path context, abnormal sequence behavior, privilege-transition evidence, post-root activity, or another corroborating signal.

Privilege-Transition and Root-Process Artifacts

Relevant Artifacts

Source user, source UID, effective user, effective UID, target user, target UID, root-owned child process, parent process, parent executable path, parent command line, child process, child executable path, child command line, process ancestry, process start time, authentication event, sudo event, su event, pkexec event, SUID-root binary, setuid event, setgid event, capability change, namespace creation, mount activity, unshare activity, privileged utility execution, shell creation, interpreter creation, service-context execution, container-originated process, CI-runner-originated process, workload role, approved administrator context, and event timestamp.

Useful Log Sources

·        SentinelOne

·        Linux audit and Auditd

·        Sysmon for Linux

·        Elastic Defend

·        Splunk process and authentication telemetry

·        QRadar-normalized Linux process events

·        EDR telemetry

·        PAM and authentication logs

·        Sudo logs

·        System journal

·        eBPF process telemetry

·        Container-runtime telemetry

·        Kubernetes node telemetry

·        SIEM-normalized process and user telemetry

Detection Use

These artifacts support detection when constrained, service, application, container, build, runner, or other non-administrative execution produces a root-owned process or when a suspicious parent process creates a root shell, interpreter, service process, privileged utility, or other high-risk child process.

Investigation Use

Investigators should determine whether the privilege transition is expected for sudo, package management, service management, orchestration, deployment, backup, monitoring, security tooling, incident response, configuration management, or maintenance. They should validate the source user, parent process, child process, process lineage, workload role, timing, command line, authentication context, and any subsequent sensitive-resource or persistence behavior.

Non-Coverage Conditions

A root-owned process alone is not sufficient. A shell running as root alone is not sufficient. Sudo activity alone is not sufficient. A UID of zero alone is not sufficient. SUID execution alone is not sufficient. Namespace or mount activity alone is not sufficient. These artifacts require abnormal parentage, constrained-user origin, writable-path context, unexpected process lineage, unapproved administrative context, sensitive-resource access, security-control degradation, persistence, network expansion, or downstream cloud activity.

Sensitive-Resource and Trust-Material Artifacts

Relevant Artifacts

/etc/shadow, /etc/gshadow, /etc/sudoers, /etc/sudoers.d, /root/.ssh, user SSH keys, authorized keys, service credentials, application secrets, environment files, cloud credentials, cloud metadata paths, Kubernetes service-account tokens, kubeconfig files, kubelet credentials, container-runtime sockets, Docker socket, containerd socket, CRI socket, CI/CD credentials, repository credentials, package-signing keys, code-signing keys, TLS keys, host-mounted secrets, secret-store paths, token files, credential databases, file open, file read, file copy, file archive, file permission change, file ownership change, transfer-tool use, archive-tool use, process identity, workload identity, source user, and event timestamp.

Useful Log Sources

·        SentinelOne file and process telemetry

·        Linux audit file-access records

·        Auditd

·        Elastic Endpoint

·        Splunk file and process telemetry

·        QRadar-normalized Linux events

·        File-integrity monitoring

·        osquery

·        EDR telemetry

·        Kubernetes audit logs

·        Kubelet logs

·        Container-runtime logs

·        CI/CD platform logs

·        Cloud metadata access telemetry

·        SIEM-normalized trust-material telemetry

Detection Use

These artifacts support detection when root or effective-root processes access credential stores, SSH material, service credentials, application secrets, cloud identity material, Kubernetes service-account tokens, kubelet resources, container-runtime sockets, host-mounted secrets, repository credentials, CI/CD credentials, or signing material following suspicious staging or privilege transition.

Investigation Use

Investigators should determine whether the access is expected for backup, monitoring, configuration management, secret rotation, Kubernetes administration, container management, deployment, incident response, forensic collection, or security tooling. They should review process lineage, effective identity, workload context, file action, object sensitivity, timing, network behavior, and subsequent identity or control-plane use.

Non-Coverage Conditions

Access to a sensitive file alone is not sufficient. Access to /etc/shadow, /root/.ssh, a Kubernetes token, cloud metadata, a container-runtime socket, or repository credentials alone is not sufficient. These artifacts require root or effective-root context plus suspicious process lineage, privilege-transition evidence, abnormal timing, unapproved activity, network behavior, downstream identity use, or another corroborating signal.

Persistence and Security-Control Artifacts

Relevant Artifacts

Cron modification, systemd unit creation or modification, init-script modification, shell-profile modification, SSH authorized-key modification, startup-script modification, service creation, service enablement, daemon reload, SUID or setgid permission change, immutable-file modification, remote-access configuration, tunnel creation, audit-rule deletion, audit-service stop, logging-service stop, endpoint-security service stop, vulnerability-scanner stop, cloud-agent stop, container-security control change, firewall flush, firewall disablement, telemetry-forwarder stop, log deletion, log truncation, agent uninstall, security policy change, process name, command line, file path, service name, control-health status, and event timestamp.

Useful Log Sources

·        SentinelOne

·        Linux audit and Auditd

·        System journal

·        Sysmon for Linux

·        Elastic Defend

·        Splunk process, file, service, and security-control telemetry

·        QRadar-normalized Linux events

·        EDR security-agent telemetry

·        File-integrity monitoring

·        Service-manager logs

·        Firewall logs

·        Cloud-agent logs

·        Vulnerability-scanner logs

·        Container-security logs

·        SIEM-normalized control-health telemetry

Detection Use

These artifacts support detection when root-level activity establishes persistence, modifies startup behavior, creates remote-access capability, degrades audit or logging, disables security tooling, removes vulnerability visibility, weakens firewall controls, or disrupts telemetry forwarding.

Investigation Use

Investigators should determine whether the activity is expected for patching, troubleshooting, endpoint management, security testing, incident response, logging maintenance, firewall administration, configuration management, deployment, or approved maintenance. They should review the initiating process, effective identity, affected control, timing, prior privilege-transition evidence, and subsequent network or cloud activity.

Non-Coverage Conditions

A service stop alone is not sufficient. An audit-policy change alone is not sufficient. A firewall modification alone is not sufficient. A cron, systemd, shell-profile, or SSH-key change alone is not sufficient. Security-agent failure alone is not sufficient. These artifacts require suspicious root context, abnormal process lineage, unapproved workflow, temporal proximity to staging or privilege transition, or corroborating sensitive-resource, persistence, network, or downstream activity.

Container, Kubernetes, and Workload-Boundary Artifacts

Relevant Artifacts

Container ID, pod name, pod UID, namespace, node name, cluster name, container image, image digest, runtime, runtime socket, kubelet endpoint, kubelet credential, Kubernetes service-account token, kubeconfig, HostPath mount, privileged container, host PID namespace, host network, host IPC, namespace creation, namespace entry, mount operation, container-originated process, host-level child process, node-level root process, host-mounted secret access, node credential access, runtime API access, container escape indicator, workload role, service account, cloud identity, and event timestamp.

Useful Log Sources

·        Kubernetes audit logs

·        Kubelet logs

·        Container-runtime logs

·        Containerd logs

·        Docker logs

·        CRI logs

·        Kubernetes node telemetry

·        SentinelOne container-aware endpoint telemetry

·        Elastic Kubernetes and container telemetry

·        Splunk Kubernetes telemetry

·        QRadar-normalized container events

·        Cloud-provider Kubernetes logs

·        EDR and Linux audit telemetry

·        NDR / Network Behavioral Analytics

·        SIEM-normalized workload telemetry

Detection Use

These artifacts support detection when container-originated or pod-originated execution is followed by unexpected host-level root activity, namespace manipulation, runtime-socket access, kubelet access, host-mounted resource access, service-account-token access, cloud metadata access, or east-west expansion.

Investigation Use

Investigators should determine whether the activity is expected for orchestration, node maintenance, privileged workloads, container management, autoscaling, deployment, monitoring, backup, incident response, or security tooling. They should validate container-to-host, pod-to-node, namespace-to-workload, identity-to-workload, and process-lineage relationships.

Non-Coverage Conditions

Container activity alone is not sufficient. Kubernetes API activity alone is not sufficient. Runtime-socket access alone is not sufficient. HostPath use alone is not sufficient. A privileged container alone is not sufficient. Node-level root activity alone is not sufficient. These artifacts require reliable host, process, user, workload, node, container, pod, namespace, resource, identity, or bounded-time correlation.

Rare Egress and Suspicious Destination Artifacts

Relevant Artifacts

Source host, source IP, workload ID, workload role, container ID, pod ID, node ID, destination domain, destination IP, destination port, destination protocol, destination reputation, destination first-seen status, destination domain age, destination ASN, destination geography, proxy action, firewall action, DNS query, NDR flow, connection count, connection cadence, byte count, recurrence, baseline deviation, process attribution, cloud-service classification, and event timestamp.

Useful Log Sources

·        NDR / Network Behavioral Analytics

·        DNS logs

·        Proxy logs

·        Firewall logs

·        Endpoint network telemetry

·        SentinelOne network telemetry

·        VPC and cloud flow logs

·        Kubernetes network telemetry

·        Service-mesh telemetry

·        Cloud DNS logs

·        SIEM-normalized network telemetry

Detection Use

These artifacts support detection when high-risk Linux workloads communicate with new, rare, suspicious, geographically unusual, role-inconsistent, or otherwise anomalous destinations after suspicious staging, privilege transition, sensitive-resource access, persistence, security-control degradation, metadata access, or workload-boundary activity.

Investigation Use

Investigators should determine whether the destination is expected for updates, package repositories, code repositories, artifact registries, container registries, backup, monitoring, telemetry, security tooling, vulnerability management, orchestration, cloud services, vendor support, incident response, or business operations. They should review destination age, reputation, ASN, geography, port, protocol, timing, recurrence, process attribution, and workload role.

Non-Coverage Conditions

Rare egress alone is not sufficient. A new destination alone is not sufficient. A suspicious domain alone is not sufficient. An unusual destination port alone is not sufficient. A single outbound connection alone is not sufficient. These artifacts require role-aware deviation, destination enrichment, connection cadence, suspicious process or host context, workload criticality, privilege activity, metadata access, or another corroborating behavior.

Cloud Metadata and Workload-Identity Artifacts

Relevant Artifacts

Metadata endpoint, link-local address, token endpoint, workload-identity endpoint, instance-identity document, IAM role credential request, managed-identity token request, service-account token request, token-broker access, service-account token file, identity principal, cloud resource, cloud service, destination service, source workload, source process, request frequency, user agent, source IP, event timestamp, cloud-audit event, and follow-on cloud-service activity.

Useful Log Sources

·        NDR / Network Behavioral Analytics

·        Endpoint network telemetry

·        Linux audit and process telemetry

·        CloudTrail

·        Azure Activity

·        Microsoft Entra ID logs

·        Google Cloud Audit Logs

·        Cloud-provider metadata telemetry where available

·        Kubernetes audit logs

·        Service-mesh logs

·        Proxy logs

·        Firewall logs

·        SIEM-normalized cloud identity telemetry

Detection Use

These artifacts support detection when metadata or workload-identity access is followed by anomalous cloud-service communication, sensitive-resource access, unexpected identity use, unusual cadence, or activity from a workload not expected to request identity material.

Investigation Use

Investigators should determine whether the request is expected for initialization, cloud agents, autoscaling, orchestration, deployment, monitoring, backup, application behavior, or workload identity. They should review the originating process, source workload, requested identity, destination service, event sequence, and any downstream cloud control-plane activity.

Non-Coverage Conditions

Metadata access alone is not sufficient. Token-endpoint access alone is not sufficient. A workload-identity request alone is not sufficient. Cloud-service access alone is not sufficient. These artifacts require anomalous follow-on communication, sensitive service access, unexpected identity context, unusual cadence, new behavior, or cloud-audit corroboration.

East-West Expansion Artifacts

Relevant Artifacts

Source workload, source host, source process, source identity, destination host, destination workload, destination service, destination port, service family, peer group, asset role, unique destination count, unique port count, connection rate, fan-out, scan pattern, authentication attempt, protected-service indicator, expected peer group, approved administrative path, and event timestamp.

Useful Log Sources

·        NDR / Network Behavioral Analytics

·        Internal firewall logs

·        East-west flow telemetry

·        Service-mesh telemetry

·        Kubernetes network telemetry

·        Endpoint network telemetry

·        DNS logs

·        Proxy logs

·        Cloud flow logs

·        Asset inventory

·        Identity telemetry

·        SIEM-normalized internal network telemetry

Detection Use

These artifacts support detection when Linux workloads communicate with unexpected peer groups, administrative services, data services, identity systems, orchestration services, repositories, build systems, Kubernetes services, or management infrastructure using role-inconsistent ports, fan-out, connection rates, or destination patterns.

Investigation Use

Investigators should determine whether the activity is expected for orchestration, configuration management, deployment, backup, monitoring, vulnerability scanning, asset discovery, administration, red-team activity, incident response, or business workflows. They should review process attribution, source role, destination role, peer-group deviation, unique destination count, port diversity, timing, and preceding host behavior.

Non-Coverage Conditions

Internal communication alone is not sufficient. SSH activity alone is not sufficient. A new internal destination alone is not sufficient. One administrative-service connection alone is not sufficient. These artifacts require deviation from expected peer groups or service families plus role-aware fan-out, unique-destination, unique-port, rate-change, scan, or protected-service thresholds.

AWS Workload-Exposure and Post-Compromise Artifacts

Relevant Artifacts

Inspector finding, Security Hub finding, AWS Config state, EC2 instance ID, EKS node, AMI, kernel state, package state, public exposure, security group, instance profile, IAM role, role session, STS activity, CloudTrail event, source IP, user agent, Systems Manager activity, Run Command, Secrets Manager access, KMS activity, S3 access, snapshot activity, image activity, GuardDuty finding, account ID, region, resource ARN, principal ARN, event name, and event timestamp.

Useful Log Sources

·        Amazon Inspector

·        Security Hub

·        AWS Config

·        CloudTrail management events

·        CloudTrail data events

·        GuardDuty

·        IAM and STS logs

·        Systems Manager logs

·        EC2 logs

·        EKS logs

·        S3 data events

·        Secrets Manager logs

·        KMS logs

·        VPC Flow Logs

·        SIEM-normalized AWS telemetry

Detection Use

These artifacts support AWS exposure prioritization and post-compromise cloud-activity detection when Linux workload exposure, workload criticality, instance-profile mapping, suspicious host behavior, or anomalous role activity can be correlated with sensitive AWS control-plane actions.

Investigation Use

Investigators should determine whether activity aligns to the same instance, EKS node, workload, role, account, source IP, user agent, Systems Manager session, secret, key, bucket, snapshot, image, or resource associated with the suspected Linux host compromise.

Non-Coverage Conditions

AWS activity alone is not sufficient. Vulnerable workload state alone is not sufficient. Role assumption alone is not sufficient. Systems Manager, Secrets Manager, KMS, S3, EC2, or EKS activity alone is not sufficient. These artifacts require reliable workload-to-role mapping, exposure or criticality context, suspicious host evidence, unexpected source context, GuardDuty context, or another credible compromise linkage.

Azure Workload-Exposure and Post-Compromise Artifacts

Relevant Artifacts

Defender for Cloud recommendation, Microsoft Defender Vulnerability Management finding, Azure Resource Graph record, virtual-machine ID, scale-set instance ID, AKS node, Linux image, operating-system state, power state, managed-identity principal ID, Azure Activity event, role assignment, role definition change, VM Run Command, VM extension write, network-security-rule change, snapshot creation, disk modification, AKS credential retrieval, Storage account key retrieval, caller, caller IP, correlation ID, subscription ID, resource group, resource ID, and event timestamp.

Useful Log Sources

·        Defender for Cloud

·        Microsoft Defender Vulnerability Management

·        Azure Resource Graph

·        Azure Activity logs

·        Microsoft Entra ID logs

·        AKS logs

·        Defender for Endpoint

·        Azure Monitor

·        Network Security Group flow logs

·        Azure Firewall logs

·        Storage logs

·        SIEM-normalized Azure telemetry

Detection Use

These artifacts support Azure exposure prioritization and post-compromise managed-identity or control-plane activity detection when Linux workload exposure, workload criticality, system-assigned managed-identity mapping, suspicious host behavior, or anomalous control-plane activity can be correlated.

Investigation Use

Investigators should determine whether activity aligns to the same virtual machine, scale-set instance, AKS node, system-assigned managed identity, subscription, resource group, resource, source IP, correlation ID, disk, snapshot, Storage account, or network control associated with the suspected Linux host compromise.

Non-Coverage Conditions

Azure activity alone is not sufficient. Vulnerable workload state alone is not sufficient. Managed-identity activity alone is not sufficient. VM Run Command, role assignment, AKS, Storage, disk, snapshot, or network-control activity alone is not sufficient. These artifacts require accurate system-assigned managed-identity-to-workload mapping, exposure or criticality context, suspicious host evidence, unapproved source context, Defender findings, or another credible compromise linkage.

GCP Workload-Exposure and Post-Compromise Artifacts

Relevant Artifacts

Security Command Center finding, VM Manager finding, Cloud Asset Inventory record, Compute Engine instance ID, GKE node, operating-system state, kernel version, public exposure, attached service account, Cloud Audit Log event, principal email, caller IP, user agent, IAM policy change, service-account key creation, service-account impersonation, Secret Manager access, Cloud Storage access, Cloud KMS activity, GKE activity, Compute Engine metadata change, service-account change, firewall change, snapshot creation, image creation, organization ID, project ID, resource name, method name, and event timestamp.

Useful Log Sources

·        Security Command Center

·        VM Manager

·        Cloud Asset Inventory

·        Google Cloud Admin Activity logs

·        Google Cloud Data Access logs

·        IAM logs

·        Service-account logs

·        Secret Manager logs

·        Cloud Storage logs

·        Cloud KMS logs

·        GKE logs

·        Compute Engine logs

·        VPC Flow Logs

·        SIEM-normalized Google Cloud telemetry

Detection Use

These artifacts support GCP exposure prioritization and post-compromise service-account or control-plane activity detection when Linux workload exposure, workload criticality, service-account mapping, suspicious host behavior, or anomalous Google Cloud activity can be correlated.

Investigation Use

Investigators should determine whether activity aligns to the same Compute Engine instance, GKE node, service account, organization, project, source IP, user agent, secret, bucket, KMS key, firewall, snapshot, image, or resource associated with the suspected Linux host compromise.

Non-Coverage Conditions

Google Cloud activity alone is not sufficient. Vulnerable workload state alone is not sufficient. Service-account activity alone is not sufficient. IAM, Secret Manager, Cloud Storage, Cloud KMS, GKE, Compute Engine, firewall, snapshot, or image activity alone is not sufficient. These artifacts require accurate service-account-to-workload mapping, exposure or criticality context, suspicious host evidence, unexpected source-IP or user-agent behavior, Security Command Center context, or another credible compromise linkage.

YARA Artifact Disposition

YARA has no deployable primary-rule artifact set for this EXP report.

YARA is not viable as a primary artifact model because the report’s detection surface is behavioral, sequence-based, privilege-transition driven, process-context based, Linux audit and endpoint-telemetry driven, sensitive-resource access based, persistence based, control-degradation based, workload-boundary based, network-behavior based, and cloud-context based rather than static-file, malware-signature, or artifact-matching based.

YARA may become useful only if a confirmed malicious exploit file, compiled payload, script artifact, loader, dropper, shared object, kernel-module artifact, container-layer artifact, archive artifact, memory artifact, persistence implant, credential-theft tool, cloud-token harvesting artifact, Kubernetes trust-material collection utility, container-runtime abuse tool, or reusable malware-family artifact is recovered and independently validated.

Final YARA Outcome

No YARA rules survive.

S28 Detection Strategy and SOC Implementation Guidance

Figure 5

Purpose

This section provides implementation guidance for operationalizing the S25 rule set and S26 traceability model across NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA, YARA, AWS, Azure, GCP, Linux audit, endpoint, EDR, container, Kubernetes, CI/CD, DNS, proxy, firewall, SIEM, SOAR, and incident-response environments.

The detection strategy is sequence-based. It prioritizes correlated behavior over single-event alerting and avoids treating a single CVE identifier, exploit name, repository reference, filename, hash, writable-path event, root process, SUID event, sensitive-file event, metadata request, network connection, cloud event, vulnerable-state observation, or static indicator as proof of compromise.

Implementation Strategy

Deploy the detection model in layered stages:

·        Linux asset, workload, operating-system, kernel, package, image, container, Kubernetes node, CI/CD runner, cloud resource, exposure state, and business-criticality context first

·        Process, process-ancestry, user, effective-user, UID, executable-path, working-directory, command-line, file, writable-path, build-path, transient-path, and workload-role context second

·        Privileged-binary, SUID, setuid, setgid, authentication, namespace, mount, effective-identity, root-process, and privilege-transition context third

·        Credential, SSH, cloud metadata, Kubernetes token, kubelet, container-runtime socket, repository, CI/CD, signing-material, secret, and host-mounted trust-material context fourth

·        Persistence, service, startup, audit, logging, endpoint-security, firewall, cloud-agent, vulnerability-scanner, container-security, and telemetry-forwarding context fifth

·        Container-to-host, pod-to-node, namespace-to-workload, cloud-instance-to-host, CI-runner-to-host, and identity-to-workload correlation sixth

·        DNS, proxy, firewall, NDR, destination reputation, first-seen, ASN, geography, destination-port, protocol, rare-egress, metadata-access, and east-west expansion context seventh

·        AWS, Azure, and Google Cloud workload-exposure and downstream control-plane correlation eighth

·        Alert promotion only after telemetry validation, field-mapping validation, false-positive baselining, exception governance, and triage-playbook alignment

Telemetry Normalization Requirements

Implementation requires normalized entity and time correlation across Linux process, Linux audit, endpoint, EDR, file, authentication, service, security-control, container, Kubernetes, CI/CD, DNS, proxy, firewall, NDR, AWS, Azure, Google Cloud, SOAR, incident-response, and SIEM telemetry.

Minimum Normalization Requirements

·        Hostname

·        Canonical host ID

·        Workload ID

·        Workload role

·        Business criticality

·        Environment

·        Exposure state

·        Operating-system family

·        Distribution

·        Kernel version

·        Package state

·        Image ID

·        Container ID

·        Pod name

·        Pod UID

·        Namespace

·        Node name

·        Cluster name

·        CI/CD runner ID

·        Cloud provider

·        Cloud account, subscription, or project

·        Cloud resource ID

·        Process name

·        Executable path

·        Working directory

·        Command line

·        Process ID

·        Parent process ID

·        Parent process name

·        Parent executable path

·        Parent command line

·        Process ancestry

·        Real user

·        Effective user

·        UID

·        Effective UID

·        Group ID

·        Effective group ID

·        File path

·        File name

·        File action

·        File owner

·        File permissions

·        Writable-path indicator

·        Transient-path indicator

·        Build-path indicator

·        Approved workflow context

·        Authentication event

·        Sudo event

·        SUID or setgid indicator

·        Namespace activity

·        Mount activity

·        Root-process indicator

·        Sensitive-resource category

·        Credential or secret category

·        Cloud metadata indicator

·        Kubernetes token indicator

·        Kubelet indicator

·        Container-runtime-socket indicator

·        Persistence indicator

·        Security-control category

·        Control-health state

·        DNS query

·        Destination domain

·        Destination IP

·        Destination port

·        Destination protocol

·        Destination reputation

·        Destination first-seen status

·        Destination ASN

·        Destination geography

·        Proxy action

·        Firewall action

·        Service-family classification

·        Expected peer group

·        AWS account, role, principal, region, resource, and event

·        Azure tenant, subscription, managed identity, resource, caller, and correlation ID

·        GCP organization, project, service account, principal, resource, and method

·        SOAR case ID

·        Incident-response case ID

·        Event timestamp

·        Event source

Correlation Requirements

Rules should use bounded correlation windows that reflect the relationship between suspicious staging, abnormal privilege transition, root-level activity, sensitive-resource access, persistence, security-control degradation, network behavior, workload-boundary activity, and downstream cloud activity.

Recommended Starting Windows

·        Suspicious writable-path file creation, compilation, permission modification, or extraction to execution within 30 minutes

·        Suspicious non-root staging to abnormal root-owned process creation within 30 minutes

·        Abnormal root-process creation to sensitive-resource access within 2 hours

·        Abnormal root-process creation to persistence or security-control degradation within 4 hours

·        Container-originated or pod-originated execution to unexpected host-level root activity within 30 minutes

·        Suspicious host activity to cloud metadata or workload-identity access within 2 hours

·        Suspicious host activity to rare outbound communication within 4 hours

·        Suspicious host activity to abnormal east-west expansion within 8 hours

·        Suspected Linux host compromise to AWS, Azure, or Google Cloud control-plane activity within 24 hours

·        Continued root activity, sensitive-resource access, persistence, egress, east-west expansion, or cloud activity after containment within 24 hours

These windows should be tightened in high-volume environments and extended only when host identity, workload identity, process lineage, user lineage, container or pod lineage, cloud-resource lineage, destination continuity, SOAR evidence, or incident-response evidence supports continuity.

Alert Promotion Guidance

Do not promote a hunt or correlation search into alert mode until the following conditions are met:

·        Required telemetry is present and normalized

·        Required field mappings are validated

·        Real-user and effective-user fields are reliable

·        UID and effective-UID fields are reliable

·        Process ancestry is reliable

·        Executable-path and working-directory fields are reliable

·        Writable and transient path sets are validated

·        Linux asset and workload tagging are reliable

·        Container-to-host and pod-to-node mappings are reliable

·        Cloud-instance-to-host mappings are reliable

·        CI-runner-to-host mappings are reliable

·        Sensitive-resource and persistence path sets are validated

·        Security-control health fields are validated

·        DNS, proxy, firewall, NDR, and flow mappings are validated

·        Cloud identity and workload mappings are reliable

·        Event timing and ordering are reliable

·        Approved workflow baselines are defined

·        False-positive sources are reviewed

·        High-volume expected workflows are suppressed or downgraded

·        Query performance is tested

·        Triage guidance is documented

·        Analyst review criteria are established

·        Local severity logic is calibrated

·        Alert-routing ownership is assigned

False-Positive Control

False-positive control should use allowlists, reference sets, approved workflow baselines, approved administrator groups, approved service accounts, approved package-management tools, approved configuration-management tools, approved orchestration processes, approved CI/CD runners, approved build workspaces, approved deployment processes, approved backup processes, approved monitoring tools, approved security tools, approved vulnerability-validation activity, approved incident-response activity, approved maintenance windows, approved writable paths, approved parent-child process relationships, approved sensitive-resource access patterns, approved persistence workflows, approved egress destinations, approved peer groups, approved cloud automation identities, and known operational workflows.

Common False-Positive Sources

·        Approved software compilation

·        Approved CI/CD builds

·        Approved package installation

·        Approved deployment activity

·        Approved configuration management

·        Approved orchestration

·        Approved container initialization

·        Approved Kubernetes node maintenance

·        Approved sudo activity

·        Approved privilege-management activity

·        Approved service management

·        Approved backup activity

·        Approved monitoring activity

·        Approved vulnerability scanning

·        Approved vulnerability validation

·        Approved penetration testing

·        Approved red-team activity

·        Approved security tooling

·        Approved incident-response activity

·        Approved forensic collection

·        Approved secret rotation

·        Approved SSH-key management

·        Approved repository access

·        Approved signing activity

·        Approved cloud-agent activity

·        Approved cloud automation

·        Infrastructure-as-code workflows

·        Autoscaling activity

·        Break-glass administration

·        Emergency maintenance

·        Platform-support activity

·        Managed-service activity

Triage Guidance

Initial triage should determine whether suspicious activity forms a coherent sequence rather than a single-event anomaly.

Triage Questions

·        Was suspicious non-root execution observed from a writable, transient, build, runner, mounted-volume, or container-layer path

·        Was a script, shell, interpreter, compiler, linker, build tool, permission-modification tool, archive tool, transfer tool, or unfamiliar binary involved

·        Did file creation, compilation, permission modification, execution, and deletion occur in rapid sequence

·        Did the activity originate from an application, service, container, pod, CI/CD runner, build account, or other constrained context

·        Did an abnormal root-owned process, shell, interpreter, service process, or privileged utility follow

·        Was a privileged binary, SUID path, authentication mechanism, namespace, mount function, or capability change involved

·        Did root-level access to credentials, SSH material, cloud metadata, Kubernetes tokens, kubelet resources, container-runtime sockets, repository credentials, CI/CD credentials, secrets, or signing material occur

·        Did persistence, service modification, startup modification, SSH-key modification, tunnel creation, remote-access preparation, audit degradation, logging degradation, firewall modification, or security-agent degradation occur

·        Did container-originated or pod-originated activity produce unexpected host-level root behavior

·        Did rare outbound communication, metadata access, workload-identity access, or abnormal east-west expansion follow

·        Did AWS, Azure, or Google Cloud identity, secret, storage, remote-command, snapshot, image, network-control, Kubernetes, or control-plane activity follow

·        Can the activity be linked through host, workload, process ancestry, user, effective user, container, pod, node, cloud resource, cloud identity, source IP, destination, SOAR case, or incident-response case

·        Is the activity explained by approved development, package management, deployment, orchestration, configuration management, CI/CD, backup, monitoring, vulnerability validation, security tooling, incident response, or maintenance

Escalation Guidance

Escalate when multiple behavior classes align in sequence, especially when suspicious staging is followed by abnormal privilege transition, sensitive-resource access, persistence, security-control degradation, workload-boundary abuse, rare egress, east-west expansion, or downstream cloud activity.

Higher-Priority Escalation Conditions

·        The affected Linux workload is internet-facing

·        The affected workload is production

·        The affected workload is identity-adjacent

·        The affected workload is a CI/CD runner, build system, repository-adjacent host, container host, Kubernetes node, or privileged automation system

·        The workload has access to cloud identities, secrets, signing material, repositories, production data, or orchestration controls

·        Suspicious writable-path staging and abnormal root-process creation align

·        Suspicious non-root execution and root-level sensitive-resource access align

·        Root activity and persistence align

·        Root activity and security-control degradation align

·        Container or pod activity and unexpected host-level root execution align

·        Cloud metadata or workload-identity access and anomalous cloud activity align

·        Rare egress follows suspicious host activity

·        East-west expansion follows suspicious host activity

·        AWS, Azure, or Google Cloud activity involves privileged roles, managed identities, service accounts, secrets, keys, storage, remote command, snapshots, images, network controls, Kubernetes credentials, or administrative configuration

·        Multiple systems independently show aligned behavior

Deployment Guardrails

Do not deploy these detections as fully automated blocking or containment logic without local validation.

Do not treat a single CVE identifier, exploit name, repository reference, filename, hash, writable-path event, compiler event, root process, SUID event, sudo event, sensitive-file event, service stop, metadata request, network connection, cloud event, vulnerable-state observation, or static indicator as proof of compromise.

Do not attribute endpoint-only, process-only, file-only, root-only, sensitive-resource-only, container-only, network-only, cloud-only, or exposure-only anomalies to successful Linux privilege escalation, credential theft, container escape, Kubernetes compromise, cloud compromise, malicious persistence, successful lateral movement, malicious security-control degradation, or data theft without reliable host, process, user, workload, identity, resource, and sequence correlation.

Do not enable high-confidence alerting until platform-specific schemas, index names, sourcetypes, DSM fields, custom properties, ECS mappings, endpoint fields, Linux audit fields, process mappings, file mappings, identity mappings, container mappings, Kubernetes mappings, CI/CD mappings, network mappings, cloud fields, enrichment sources, exception lists, false-positive baselines, query performance, triage readiness, and escalation criteria have been validated.

S29 Detection Coverage Summary

Coverage Summary

The S25 detection set provides broad behavior-led coverage for suspicious Linux exploit staging, abnormal low-privilege-to-root transition, privileged-binary interaction, root-level sensitive-resource access, persistence, security-control degradation, container and Kubernetes workload-boundary abuse, rare outbound communication, cloud metadata or workload-identity access, abnormal east-west expansion, cloud workload exposure, and downstream AWS, Azure, and Google Cloud control-plane activity.

Coverage is strongest when Linux process, audit, endpoint, EDR, file, authentication, service, security-control, container, Kubernetes, CI/CD, DNS, proxy, firewall, NDR, cloud-audit, identity, asset-inventory, and SIEM telemetry are normalized and correlated into bounded sequences.

The report’s detection model intentionally avoids CVE-only matching, exploit-name-only matching, proof-of-concept-only matching, repository-only matching, filename-only matching, hash-only matching, kernel-version-only matching, syscall-only matching, writable-path-only conclusions, root-process-only conclusions, SUID-only conclusions, sensitive-file-only conclusions, cloud-event-only conclusions, network-event-only conclusions, vulnerable-state-only conclusions, and other single-event determinations.

Strong Coverage Areas

·        Suspicious Linux exploit staging and execution from writable or transient paths

·        Rapid file creation, compilation, permission modification, execution, and deletion

·        Abnormal low-privilege-to-root process transition

·        Root-owned processes created from suspicious non-administrative, application, service, container, CI/CD, build, or writable-path parentage

·        Root-level sensitive-resource access

·        Persistence and security-control degradation

·        Container-originated or pod-originated activity followed by unexpected host-level root behavior

·        Rare outbound communication from high-risk Linux workloads

·        Cloud metadata or workload-identity access followed by anomalous activity

·        Abnormal east-west expansion into trust-sensitive infrastructure

·        AWS, Azure, and GCP Linux workload exposure prioritization

·        Post-compromise AWS credential and control-plane activity

·        Post-compromise Azure system-assigned managed-identity and control-plane activity

·        Post-compromise Google Cloud service-account and control-plane activity

Moderate Coverage Areas

·        Privileged-binary, SUID, authentication, namespace, mount, syscall, kernel, crash, or fault activity where telemetry is partial

·        Privilege-transition detection where source-user, effective-user, UID, or process-ancestry fields are incomplete

·        Sensitive-resource access where object-level file telemetry is incomplete

·        Persistence or security-control degradation where service, audit, file, or agent-health telemetry is inconsistent

·        Container and Kubernetes coverage where pod-to-node, container-to-host, or namespace-to-workload mapping is partial

·        CI/CD and build-system coverage where runner-to-host or job-to-process lineage is incomplete

·        NDR coverage where source attribution is obscured by NAT, shared gateways, overlays, service meshes, or centralized egress

·        Cloud metadata or workload-identity detection where link-local traffic or token-broker activity is not visible

·        SIGMA portability across SIEM backends

·        Cloud detection where role, managed-identity, service-account, workload, resource, source-IP, or user-agent mapping is partial

Limited Coverage Areas

·        Exploitation that produces no observable staging, privilege transition, root-owned process activity, sensitive-resource access, persistence, security-control degradation, network behavior, workload-boundary activity, or cloud activity

·        In-memory or living-off-the-land exploitation that remains inside expected process and network behavior

·        Root activity that blends into approved administrative workflows

·        Sensitive-resource access performed by expected privileged processes

·        Persistence that mirrors approved configuration-management or deployment activity

·        Security-control degradation that resembles troubleshooting or maintenance

·        Container or Kubernetes abuse without reliable host, node, container, pod, or identity correlation

·        Rare egress that uses approved destinations, protocols, identities, or infrastructure

·        East-west expansion that follows expected peer relationships or administrative paths

·        Cloud activity without reliable workload-to-role, workload-to-managed-identity, or workload-to-service-account mapping

·        Environments without CloudTrail data events, Azure diagnostic visibility, Google Cloud Data Access logs, or equivalent sensitive-service telemetry

Non-Covered Areas

The S25 rule set does not directly prove:

·        The specific Linux vulnerability used

·        The specific kernel primitive used

·        The specific filesystem, namespace, authentication, synchronization, or memory-corruption mechanism

·        Successful exploitation

·        Credential theft

·        Container escape

·        Kubernetes compromise

·        Repository compromise

·        CI/CD compromise

·        AWS compromise

·        Azure compromise

·        Google Cloud compromise

·        Attacker-established persistence without corroborating process, file, service, identity, or sequence evidence

·        Successful lateral movement or compromise of destination systems

·        Data theft

·        Adversary attribution

·        Campaign attribution

These outcomes require investigation, corroborating telemetry, and incident-specific validation.

System Coverage Summary

NDR / Network Behavioral Analytics

NDR provides primary network-behavior coverage through Rare Outbound Communication From High-Risk Linux Workloads, Cloud Metadata or Workload Identity Access Followed by Anomalous Activity, and Abnormal East-West Expansion From Linux Workloads.

NDR does not directly observe the local privilege-transition mechanism and cannot independently prove root access, credential theft, attacker-established persistence, successful lateral movement, container escape, Kubernetes compromise, or cloud compromise without endpoint, audit, identity, workload, cloud, or SIEM-forwarded context.

SentinelOne

SentinelOne provides primary endpoint coverage through Suspicious Linux Exploit Staging and Execution From Writable Paths, Abnormal Low-Privilege-to-Root Process Transition, and Suspicious Root-Level Sensitive Resource Access or Security-Control Modification.

SentinelOne is strongest where process lineage, real-user and effective-user context, UID fields, executable paths, working directories, file events, endpoint tags, security-agent events, network connections, and container or Kubernetes context are available.

Splunk

Splunk provides strong SIEM correlation coverage through Suspicious Linux Execution From Writable or Transient Paths, Suspicious Root Process From Non-Administrative or Writable-Path Parent Context, and Suspicious Root-Level Sensitive Resource Access or Security-Control Modification.

Splunk production value depends on normalized process, file, audit, user, workload, container, Kubernetes, network, cloud, and asset-context fields with reliable sequence logic and exceptions.

Elastic

Elastic provides strong endpoint and ECS-aligned coverage through Suspicious Linux Execution From Writable or Transient Paths, Abnormal Low-Privilege-to-Root Process Transition, and Suspicious Root-Level Sensitive Resource Access or Security-Control Modification.

Elastic production value depends on effective-identity fidelity, parent-child process linkage, file-event coverage, ECS or local-field normalization, exception quality, and workload enrichment.

QRadar

QRadar provides strong SIEM correlation and offense-generation coverage through Suspicious Linux Exploit Staging Followed by Abnormal Privilege Transition, Abnormal Low-Privilege-to-Root Execution Followed by High-Risk Root Activity, and Suspicious Root-Level Sensitive-Resource Activity or Confirmed Security-Control Degradation.

QRadar production value depends on validated DSM parsing, custom properties, reference sets, reference maps, event ordering, hostname normalization, exposure-state enrichment, and workload-role context.

SIGMA

SIGMA provides portable event-rule template coverage through Writable-Path Exploit Staging on Linux Workloads, Abnormal Low-Privilege-to-Root Process Transition, and Suspicious Post-Root Activity on Linux Workloads.

SIGMA production value depends on backend translation quality, field mappings, effective-user handling, file-event translation, enrichment, exception validation, and SIEM-native correlation.

YARA

YARA has zero deployable rules for this EXP report because no stable malicious exploit file, compiled payload, loader, dropper, script family, shared object, kernel-module artifact, container-layer artifact, persistence implant, credential-theft tool, token-harvesting artifact, or reusable malware family is available.

AWS

AWS provides conditional exposure prioritization through AWS Linux Privilege-Escalation Exposure and Workload Prioritization and downstream activity coverage through Post-Escalation AWS Credential and Control-Plane Activity After Suspected Linux Host Compromise.

AWS coverage depends on reliable workload-to-role mapping, exposure or criticality context, CloudTrail, GuardDuty, Inspector, Security Hub, AWS Config, IAM, STS, Systems Manager, Secrets Manager, KMS, EC2, EKS, S3, source-IP, user-agent, and Linux host correlation.

Azure

Azure provides conditional exposure prioritization through Azure Linux Privilege-Escalation Exposure and Workload Prioritization and downstream activity coverage through Post-Escalation Azure Managed-Identity and Control-Plane Activity After Suspected Linux Host Compromise.

Azure coverage depends on reliable system-assigned managed-identity-to-workload mapping, Defender for Cloud, Microsoft Defender Vulnerability Management, Azure Resource Graph, Azure Activity, AKS, VM Run Command, Storage, disk, snapshot, network-control, source-IP, and Linux host correlation.

The Azure control-plane rule does not directly cover user-assigned managed identities, service principals, or federated workload identities.

GCP

GCP provides conditional exposure prioritization through GCP Linux Privilege-Escalation Exposure and Workload Prioritization and downstream activity coverage through Post-Escalation GCP Service-Account and Control-Plane Activity After Suspected Linux Host Compromise.

GCP coverage depends on reliable service-account-to-workload mapping, Security Command Center, VM Manager, Cloud Asset Inventory, Cloud Audit Logs, IAM, Secret Manager, Cloud Storage, Cloud KMS, GKE, Compute Engine, source-IP, user-agent, and Linux host correlation.

Coverage Conclusion

The detection set provides strong practical coverage for observable enterprise behavior associated with suspicious Linux exploit staging, abnormal privilege transition, root-level sensitive-resource access, persistence, security-control degradation, workload-boundary abuse, rare egress, cloud metadata or workload-identity access, east-west expansion, cloud workload exposure, and downstream cloud activity.

It is strongest when multiple telemetry classes align in sequence and weakest where exploitation produces no observable process, file, identity, root-process, sensitive-resource, persistence, control-health, network, workload-boundary, or cloud behavior.

S30 Intelligence Maturity Assessment

Maturity Assessment Summary

The intelligence maturity level for this report is high for behavior-led detection strategy and moderate for direct exploitation confirmation.

The detection model is mature because it focuses on durable behavioral relationships: suspicious exploit staging, abnormal low-privilege-to-root transition, root-owned process activity, sensitive-resource access, persistence, security-control degradation, container and Kubernetes workload-boundary activity, anomalous outbound communication, east-west expansion, workload exposure, and downstream cloud activity.

Direct exploitation confirmation remains limited because enterprise telemetry generally does not expose the specific vulnerability, kernel primitive, race condition, memory-corruption path, filesystem mechanism, namespace technique, authentication flaw, or other technical privilege-escalation mechanism directly. Most environments infer compromise through process, identity, file, audit, security-control, workload, network, and cloud behavior.

Behavioral Intelligence Maturity

Behavioral maturity is high.

The report identifies repeatable post-foothold behavior that can be detected across Linux process, Linux audit, endpoint, EDR, file, authentication, service, security-control, container, Kubernetes, CI/CD, DNS, proxy, firewall, NDR, SIEM, AWS, Azure, and Google Cloud platforms.

The behaviors are durable across CVE identifiers, exploit names, proof-of-concept repositories, filenames, hashes, kernel primitives, syscall variation, package versions, distributions, container images, cloud providers, attacker tooling, source infrastructure, and campaign branding.

Strong Behavioral Anchors

·        Suspicious execution from writable, transient, build, runner, mounted-volume, or container-layer paths

·        Rapid file creation, compilation, permission modification, execution, and deletion

·        Abnormal low-privilege-to-root process transition

·        Root-owned process activity from suspicious parentage

·        Root-level access to credentials, SSH material, cloud metadata, Kubernetes tokens, kubelet resources, container-runtime sockets, repository credentials, CI/CD credentials, secrets, or signing material

·        Root-level persistence and remote-access preparation

·        Audit, logging, endpoint-security, firewall, cloud-agent, vulnerability-scanner, container-security, or telemetry-forwarding degradation

·        Container-originated or pod-originated activity followed by unexpected host-level root activity

·        Rare outbound communication from high-risk Linux workloads

·        Cloud metadata or workload-identity access followed by anomalous activity

·        Abnormal east-west expansion into trust-sensitive infrastructure

·        AWS, Azure, and GCP workload-exposure and post-compromise control-plane activity

Telemetry Maturity

Telemetry maturity is moderate to high.

Linux process, audit, endpoint, EDR, file, authentication, service, container, Kubernetes, CI/CD, DNS, proxy, firewall, NDR, cloud-audit, identity, and asset-inventory telemetry provide strong coverage where host, workload, process, user, effective-user, UID, file, container, pod, node, cloud resource, identity, destination, and timestamp fields are available and normalized.

Telemetry maturity decreases when effective-user fields are unavailable, process ancestry is incomplete, command lines are truncated, writable-path mapping is weak, file access is not logged, container-to-host mapping is unreliable, cloud identity mappings are incomplete, metadata traffic is not visible, or approved workflow baselines are weak.

Cloud and Workload Maturity

Cloud and workload maturity is moderate to strong.

AWS, Azure, and Google Cloud provide useful exposure and downstream activity visibility when cloud telemetry can be joined to suspected Linux host compromise through workload, role, managed identity, service account, source IP, user agent, resource, account, subscription, project, region, or time-window lineage.

Cloud platforms do not independently prove local Linux privilege escalation. Their strongest value comes from workload prioritization and correlation with suspicious host behavior, metadata access, identity use, secret access, storage access, remote command, snapshot activity, image activity, network-control change, Kubernetes activity, or other cloud-side effects.

Maturity increases when CloudTrail, GuardDuty, Inspector, Security Hub, AWS Config, Azure Activity, Defender for Cloud, Microsoft Defender Vulnerability Management, Azure Resource Graph, Google Cloud Audit Logs, Security Command Center, VM Manager, Cloud Asset Inventory, sensitive-service logs, and cloud identity mappings are normalized and validated.

Adversary-Resilience Maturity

Adversary-resilience maturity is high for behavior-led detection and moderate for high-confidence exploit attribution.

The detection model is resilient because it avoids brittle indicators and focuses on behavior an adversary may produce when converting constrained Linux execution into root-level access, credential or trust-material access, persistence, control degradation, workload-boundary abuse, network expansion, or cloud-side activity.

The model is less resilient when adversaries use existing trusted binaries, approved writable paths, expected administrative processes, normal cloud identities, approved destinations, expected peer relationships, low-and-slow timing, in-memory execution, existing root processes, or established automation channels. It is also less resilient when adversaries avoid sensitive-resource access, persistence, security-control changes, anomalous network behavior, and downstream cloud activity.

Operationalization Maturity

Operationalization maturity is moderate.

The S25 rules are implementation-ready detection patterns, but production deployment requires local validation of schemas, index names, sourcetypes, DSM fields, custom properties, ECS mappings, Linux audit fields, process fields, file fields, identity fields, container fields, Kubernetes fields, cloud fields, network fields, asset mappings, workload mappings, enrichment, exceptions, false-positive baselines, query performance, triage logic, and alert-routing decisions.

Operational maturity increases when detection owners validate each platform’s field mappings, confirm telemetry quality, baseline approved administration, package management, service management, CI/CD, build, deployment, orchestration, configuration management, backup, monitoring, vulnerability validation, security tooling, cloud automation, incident response, and maintenance, and test sequence logic using realistic benign and suspicious event data.

Attribution Maturity

Attribution maturity is low to moderate.

The rule set supports detection of behavior consistent with suspicious Linux exploit staging, abnormal privilege transition, root-level sensitive-resource access, persistence, security-control degradation, workload-boundary abuse, anomalous network activity, and downstream cloud activity.

It should not be used by itself to attribute activity to a specific adversary, campaign, exploit developer, malware family, infrastructure provider, or named threat group without external evidence and incident-specific validation.

Attribution requires corroborating evidence such as exploitation timeline, process lineage, Linux audit records, kernel or crash evidence, recovered exploit artifacts, source infrastructure, command history, credential access, persistence, network destinations, cloud activity, victimology, actor tradecraft, and threat-intelligence reporting.

Maturity Limitations

Primary Maturity Limitations

·        Limited direct visibility into exploitation success

·        Limited direct visibility into the underlying kernel or privilege-escalation mechanism

·        Variable effective-user and UID telemetry

·        Variable process-ancestry telemetry

·        Variable command-line visibility

·        Variable writable-path and transient-path mapping

·        Variable file-event coverage

·        Variable sensitive-resource access telemetry

·        Variable persistence telemetry

·        Variable audit and security-agent health telemetry

·        Variable container-to-host and pod-to-node mapping

·        Variable CI-runner-to-host mapping

·        Variable cloud-instance-to-host mapping

·        Variable cloud role, managed-identity, and service-account mapping

·        Variable cloud data-event logging

·        Variable metadata and workload-identity visibility

·        Variable source-IP and user-agent stability

·        Variable east-west network visibility

·        Variable approved workflow baselines

·        High false-positive potential when detections are deployed without local tuning

Maturity Improvement Priorities

Priority Improvements

·        Improve Linux process, command-line, executable-path, working-directory, parent-process, process-ancestry, real-user, effective-user, UID, and effective-UID telemetry

·        Improve Linux audit, Sysmon for Linux, osquery, eBPF, system journal, crash, fault, and security-agent telemetry

·        Improve writable, transient, build, workspace, runner, mounted-volume, and container-layer path inventories

·        Improve sensitive-resource, credential, SSH, cloud metadata, Kubernetes token, kubelet, container-runtime socket, repository, CI/CD, secret, and signing-material logging

·        Improve cron, systemd, startup, shell-profile, SSH-key, service, persistence, remote-access, and tunnel telemetry

·        Improve audit, logging, firewall, endpoint-security, cloud-agent, vulnerability-scanner, container-security, and telemetry-forwarding health monitoring

·        Improve container-to-host, pod-to-node, namespace-to-workload, cloud-instance-to-host, CI-runner-to-host, and identity-to-workload mapping

·        Improve DNS, proxy, firewall, NDR, destination-reputation, destination-first-seen, ASN, geography, protocol, destination-port, and east-west normalization

·        Improve cloud metadata and workload-identity visibility

·        Improve AWS workload-to-role mapping

·        Improve Azure system-assigned managed-identity-to-workload mapping

·        Improve Google Cloud service-account-to-workload mapping

·        Enable relevant AWS, Azure, and Google Cloud data-event logging

·        Improve vulnerable-state history, kernel state, package state, image state, live-patch state, reboot state, and exposure-state tracking

·        Build approved workflow baselines for sudo, privilege management, package management, service management, CI/CD, compilation, deployment, orchestration, configuration management, backup, monitoring, vulnerability validation, security tooling, cloud automation, incident response, and maintenance

·        Test detection logic against realistic benign and suspicious sequences before alert promotion

Final Intelligence Maturity Assessment

The report’s intelligence maturity is strong for behavior-led detection engineering, strong for executive risk framing, moderate to strong for telemetry-driven operational detection, moderate to strong for Linux endpoint, audit, SIEM, network, container, Kubernetes, workload, and cloud correlation, moderate for AWS, Azure, and Google Cloud downstream activity correlation, and low to moderate for direct exploitation or attribution confirmation.

The S25 through S30 detection model is best used as an implementation-ready threat-to-detection framework that identifies suspicious exploit staging, abnormal privilege transition, root-level sensitive-resource access, persistence, security-control degradation, workload-boundary abuse, anomalous outbound communication, east-west expansion, cloud workload exposure, and downstream cloud activity.

It should not be used as a standalone proof model for a specific Linux vulnerability, successful privilege escalation, credential theft, container escape, Kubernetes compromise, repository compromise, CI/CD compromise, attacker-established persistence, successful lateral movement, malicious security-control degradation, data theft, or cloud compromise without corroborating telemetry and incident-specific validation.

S31 — Telemetry Dependencies

Linux foothold-to-root privilege escalation and cloud workload trust compromise require telemetry capable of proving whether suspicious constrained execution remained limited to failed exploitation or progressed into abnormal privilege transition, unauthorized root-level activity, credential or trust-material access, security-control degradation, scheduled persistence, workload-boundary interaction, downstream account use, or broader infrastructure expansion. The central dependency is the ability to correlate Linux asset inventory, vulnerable-state history, endpoint process telemetry, Linux audit records, authentication and privilege-transition data, file activity, security-agent health, container and Kubernetes context, cloud identity activity, CI/CD and repository records, network telemetry, change-control records, incident-response evidence, and business-owner context into one foothold-to-root-to-impact investigation model.

Linux Asset, Vulnerability, and Workload Context

·        Asset telemetry must identify Linux servers, cloud instances, Kubernetes worker nodes, container hosts, CI runners, build systems, developer systems, privileged automation hosts, identity-adjacent systems, repositories, databases, storage systems, backup systems, and production-critical workloads.

·        Vulnerability telemetry must identify kernel, package, image, workload, node-pool, golden-image, template, and reboot state at the time suspicious activity occurred.

·        Required fields include hostname, canonical asset identifier, cloud instance identifier, operating system, distribution, kernel version, package version, image identifier, container-host role, Kubernetes cluster, node, pod, namespace, workload owner, service account, CI-runner role, business criticality, internet exposure, patch state, vulnerable-state history, and remediation status where available.

·        This telemetry is required to determine whether suspicious execution affected a system capable of supporting local privilege escalation and whether successful root access could expose credentials, workload identities, privileged interfaces, or downstream trust relationships.

·        Current patch status must not replace historical vulnerable-state validation because systems may have been patched, rebooted, rebuilt, rotated, or replaced after suspicious activity.

Endpoint Process, User, and Privilege-Transition Telemetry

·        Endpoint telemetry must capture process creation, process ancestry, process termination, command line, executable path, working directory, process user, real user, effective user, UID, effective UID, parent user, parent process, file hash where available, and timestamp.

·        Required visibility includes shells, interpreters, build tools, compilers, linkers, permission-modification tools, download tools, archive tools, temporary executables, privileged utilities, authentication mechanisms, service processes, and root-owned child processes.

·        This telemetry is required to determine whether constrained execution progressed into exploit staging, privileged-mechanism interaction, abnormal effective-user transition, root-owned process creation, or unauthorized root-level execution.

·        Process telemetry must preserve sufficient ancestry to connect application services, web-service accounts, containers, CI jobs, developer activity, automation, or other low-privilege contexts to later privileged activity.

·        Process and privilege-transition telemetry must be interpreted against approved sudo workflows, privilege-management systems, package management, configuration management, orchestration, deployment activity, vulnerability validation, troubleshooting, maintenance, red-team activity, and incident response.

Linux Audit, Authentication, Kernel, and Fault Telemetry

·        Linux audit and authentication telemetry must capture sudo, PAM, su, privilege-management activity, authentication failures and successes, user and group changes, setuid or setgid behavior, privileged file access, process execution, permission changes, ownership changes, and relevant system-call activity where configured.

·        Kernel and fault telemetry should capture warnings, oops events, panics, hangs, watchdog events, segmentation faults, service crashes, process faults, unexplained restarts, and resource-exhaustion behavior near suspicious local execution.

·        Required fields include asset identifier, user, effective user, UID, effective UID, executable, command line, audit event type, authentication mechanism, result, timestamp, kernel event, fault type, service, process identifier, and approved administrative context where available.

·        This telemetry is required to distinguish failed exploit attempts, unstable exploitation, vulnerable-state probing, approved testing, and successful privilege escalation.

·        Direct kernel, syscall, eBPF, memory, or race-condition telemetry should be treated as high-value enrichment rather than a universal prerequisite.

File, Credential, Secret, and Persistence Telemetry

·        File telemetry must capture creation, write, modification, rename, execution, deletion, permission change, ownership change, setuid or setgid change, archive creation, download, read access, and timestamp change where available.

·        Required coverage includes temporary directories, shared-memory paths, user home directories, application workspaces, CI workspaces, build paths, runner paths, mounted volumes, container writable layers, cron paths, SSH directories, shell profiles, systemd paths, privileged configuration paths, credential stores, secret paths, and security-tool directories.

·        Sensitive-resource telemetry should cover SSH material, service credentials, application secrets, cloud credentials, workload identity material, Kubernetes service account tokens, host-mounted secrets, CI/CD credentials, repository credentials, package-registry credentials, deployment secrets, and signing material.

·        Persistence telemetry must capture new or modified root-level cron entries, scheduled scripts, associated file changes, execution results, and approved administrative context.

·        This telemetry is required to determine whether root access exposed trust material, established recurring privileged execution, altered authentication state, or created a post-remediation access path.

·        Sensitive-resource and persistence activity must be interpreted against approved backup, monitoring, secret rotation, deployment, configuration management, administrative maintenance, and incident-response workflows.

Security-Control and Telemetry-Health Data

·        Security-control telemetry must capture endpoint-protection stops, audit-policy changes, logging changes, telemetry-forwarding changes, cloud-agent changes, vulnerability-scanner interference, container-security changes, workload-protection changes, protected-process termination, and confirmed control-health state changes.

·        Required fields include asset identifier, control name, service name, previous state, new state, initiating user, initiating process, command line, timestamp, approved change record, maintenance context, and recovery status where available.

·        This telemetry is required to determine whether suspicious root-level activity weakened prevention, detection, logging, vulnerability management, cloud visibility, container visibility, or forensic assurance.

·        Control-health evidence must distinguish actual service or policy change from missing telemetry, temporary communication loss, platform maintenance, package upgrades, planned restart, or collection failure.

·        Post-remediation validation must confirm that affected controls were restored and remained healthy after containment.

Container, Kubernetes, and Workload-Boundary Telemetry

·        Container and Kubernetes telemetry must identify container-originated or pod-originated activity that progresses into host-level execution, host namespace interaction, runtime-socket access, kubelet access, hostPath access, node-level resource interaction, or host-mounted secret access.

·        Required fields include container identifier, image identifier, pod, namespace, cluster, node, service account, workload identity, process identifier, host process, executable path, command line, mount context, runtime context, API action, source identity, destination resource, and timestamp where available.

·        This telemetry is required to determine whether suspicious Linux root activity affected only the host or expanded across container, node, namespace, workload, or cluster trust boundaries.

·        Container-to-host and pod-to-node mapping must be preserved across restarts, rescheduling, autoscaling, and workload replacement.

·        Kubernetes API activity must not be treated as proof of host compromise unless it can be linked by node, pod, service account, workload identity, source address, process context, or bounded time window.

Cloud Identity and Control-Plane Telemetry

·        Cloud telemetry must capture workload identity use, managed identity activity, role use, token-service access, metadata-service access, secret retrieval, storage access, snapshot activity, image activity, remote command activity, network-control changes, security-control changes, and infrastructure-management actions.

·        Required fields include cloud provider, account, subscription, project, region, resource identifier, instance identifier, principal, role, managed identity, service account, source IP, user agent, API action, target resource, result, timestamp, and approved automation context.

·        This telemetry is required to determine whether trust material exposed from a suspected root-compromised Linux workload was used against cloud resources.

·        Cloud activity must be correlated to the affected Linux host, workload, identity, resource, account, destination, or bounded time window.

·        Cloud-control-plane activity alone cannot prove local Linux privilege escalation and should be treated as downstream or supporting evidence.

CI/CD, Repository, Package-Registry, and Deployment Telemetry

·        CI/CD telemetry must capture pipeline execution, runner activity, job identity, build activity, secret access, deployment actions, artifact creation, artifact publication, administrative changes, repository access, package-registry access, and signing-system interaction.

·        Required fields include CI platform, runner, job, pipeline, repository, branch, commit, user, service account, token identity, artifact, package, registry, deployment target, timestamp, source address, result, and approved release context.

·        This telemetry is required to determine whether credentials, tokens, or identities exposed through Linux root compromise were used against software-delivery or deployment trust paths.

·        Repository and deployment anomalies must be tied to the suspected Linux compromise by credential, identity, runner, host, source address, artifact, resource, or bounded time window.

·        Normal build, release, automation, package publication, dependency retrieval, and emergency deployment activity must be available for false-positive control.

Network, DNS, Proxy, Firewall, and NDR Telemetry

·        Network telemetry must capture inbound and outbound communication involving affected Linux systems, containers, Kubernetes nodes, CI runners, build systems, cloud instances, repositories, management systems, identity services, storage systems, databases, backup platforms, and downstream infrastructure.

·        Outbound telemetry should identify rare destinations, newly observed domains, raw-IP communication, unusual ports, unexpected protocols, repeated callbacks, beacon-like behavior, tunneling, tool retrieval, repository access, package-registry access, metadata access, cloud-service access, and abnormal east-west expansion.

·        Required fields include source asset, source IP, source process where available, container, pod, namespace, destination domain, destination IP, destination port, protocol, timestamp, action, destination reputation, ASN, geography, first-seen status, session count, duration, bytes transferred, and network behavior where available.

·        This telemetry is required to connect suspicious root activity, credential access, persistence, security-control degradation, workload-boundary interaction, and downstream expansion into one investigation timeline.

·        Network telemetry must not be used as standalone proof of successful privilege escalation because process, user, effective-user, credential, and host context may be absent.

Change-Control, Incident Response, Remediation, and Business Context

·        Change-control telemetry must capture approved administration, sudo activity, package management, kernel updates, reboot activity, configuration management, orchestration, backup, vulnerability validation, CI/CD activity, deployment activity, secret rotation, node maintenance, workload replacement, red-team activity, and incident-response collection.

·        Incident-response records must capture affected host, workload, container, node, user, effective user, process chain, vulnerable state, sensitive resource, security control, identity, cloud resource, downstream system, containment action, action owner, timestamp, evidence source, validation status, and closure rationale.

·        Business context must identify asset owner, workload owner, application owner, identity owner, cloud owner, cluster owner, CI/CD owner, repository owner, data sensitivity, business criticality, regulated workload status, customer impact, partner impact, and recovery priority.

·        This telemetry is required to determine whether suspicious behavior was attacker-driven, administrator-driven, automation-driven, maintenance-related, validation-related, recovery-related, or incident-response-related.

·        Remediation must not be treated as complete until vulnerable-state resolution, host trust, credential exposure, security-control health, persistence state, workload-boundary exposure, downstream identity activity, and post-remediation behavior have been explicitly validated.

S32 — Detection Limitations

Detection of Linux foothold-to-root privilege escalation and cloud workload trust compromise is limited by whether the organization can reconstruct the relationship between constrained execution, exploit staging, privileged-mechanism interaction, abnormal privilege transition, unauthorized root-level activity, sensitive-resource access, security-control degradation, scheduled persistence, workload-boundary interaction, downstream identity use, network expansion, cloud activity, and remediation evidence. Environments that rely only on vulnerable-version status, CVE references, public proof-of-concept files, exploit names, kernel warnings, isolated writable-path execution, SUID activity, generic root processes, sensitive-file access, or cloud anomalies will not have enough evidence for high-confidence compromise or impact determination.

Primary Limitations

·        Missing Linux asset inventory may prevent identification of affected servers, cloud instances, Kubernetes nodes, container hosts, CI runners, build systems, developer systems, privileged automation hosts, identity-adjacent systems, and production workloads.

·        Missing historical vulnerability and patch data may prevent validation of kernel, package, image, workload, node-pool, reboot, live-patch, or backport state when suspicious behavior occurred.

·        Missing process telemetry may prevent review of process ancestry, command line, executable path, working directory, process user, real user, effective user, UID, effective UID, parent process, and abnormal root-owned child creation.

·        Missing or unreliable effective-user data may prevent confirmation that constrained execution crossed into unauthorized root-level execution.

·        Missing Linux audit, authentication, PAM, sudo, kernel, syscall, eBPF, crash, or fault telemetry may prevent reliable review of privilege-transition behavior, exploit instability, privileged-mechanism interaction, and failed-to-success sequences.

·        Missing file telemetry may prevent identification of temporary artifacts, compiled binaries, permission changes, rapid execution and deletion, credential access, secret access, or cron persistence.

·        Missing sensitive-resource telemetry may prevent assessment of SSH material, service credentials, application secrets, cloud credentials, workload identities, Kubernetes service account tokens, host-mounted secrets, CI/CD credentials, repository credentials, deployment secrets, or signing material.

·        Missing security-control health data may prevent confirmation of endpoint-agent stopping, audit modification, logging disruption, telemetry-forwarding changes, cloud-agent tampering, vulnerability-scanner interference, or container-security degradation.

·        Missing container-to-host or pod-to-node mapping may prevent attribution of container-originated activity to host-level root execution or node-level resource interaction.

·        Missing Kubernetes telemetry may prevent review of service account use, API activity, kubelet access, hostPath use, node-resource access, and cluster-side effects.

·        Missing cloud identity and audit telemetry may prevent review of metadata access, managed identity use, role activity, secret retrieval, storage access, snapshot activity, remote commands, image activity, or security-control changes.

·        Missing CI/CD, repository, package-registry, deployment, or signing telemetry may prevent review of downstream use of credentials or trust material exposed from the Linux system.

·        Missing DNS, proxy, firewall, NDR, EDR network, or flow telemetry may prevent assessment of rare egress, callbacks, tunneling, tool retrieval, cloud-service access, repository access, east-west movement, or internal-service expansion.

·        Missing change-control, maintenance, patching, orchestration, deployment, vulnerability-validation, red-team, and incident-response records may prevent reliable false-positive control.

·        Short telemetry retention may prevent reconstruction of activity that occurred before patching, reboot, host isolation, workload replacement, node rotation, credential rotation, or security-control restoration.

·        Poor timestamp normalization may break correlation across endpoint, audit, file, container, Kubernetes, cloud, CI/CD, identity, and network telemetry.

·        Incomplete normalization of host, workload, container, pod, node, user, effective user, identity, cloud resource, repository, destination, and business-owner fields may prevent reliable cross-platform correlation.

Detection Boundary

·        A vulnerable kernel, package, image, or workload is not proof of successful privilege escalation.

·        A CVE match, KEV status, exploit name, public repository, proof-of-concept file, hash, filename, source-code fragment, or kernel-version finding is not proof of compromise by itself.

·        Writable-path execution, compilation, permission change, SUID execution, namespace interaction, mount activity, kernel instability, or process fault should not be treated as successful escalation without a credible privilege transition or post-root sequence.

·        A root-owned process is not proof of malicious privilege escalation without abnormal parentage, constrained origin, suspicious timing, unauthorized context, protected-resource access, defensive-control change, persistence, or downstream behavior.

·        Sensitive-file access should not be attributed to malicious root activity without process, user, effective-user, workload, resource, change-control, or time-window linkage.

·        Security-control degradation should not be attributed to attacker activity without confirmed state change and correlation to suspicious root-level execution or unauthorized administration.

·        Container, Kubernetes, cloud, CI/CD, repository, identity, or network anomalies should not be attributed to Linux privilege escalation without host, workload, process, identity, resource, destination, or bounded time-window correlation.

·        Cron activity should not be treated as malicious persistence when it matches approved administration, backup, monitoring, package management, orchestration, deployment, or maintenance behavior.

·        Downstream valid-account use should not be attributed to exposed Linux trust material without credential, identity, source, host, workload, resource, destination, or time-window linkage.

·        Legitimate administration, package installation, configuration management, orchestration, backup, vulnerability validation, build activity, deployment activity, troubleshooting, red-team work, recovery activity, and incident response can create overlapping signals.

·        Detection logic must not depend on another CyberDax alert, DRI score, TCR score, or post-alert analyst judgment as an input.

·        High-confidence conclusions should require validated multi-signal correlation across constrained execution, privilege transition, root activity, protected-resource access, security-control state, persistence, workload context, identity activity, network behavior, and approved workflow evidence where applicable.

Operational Impact of Limitations

Detection coverage should be reduced, converted to hunt-only logic, or withheld when process ancestry, effective-user fields, audit data, file telemetry, security-control health, workload mapping, cloud identity mapping, network attribution, or bounded sequence correlation are unavailable or unreliable. Suspicious Linux activity may remain analytically important but unsuitable for high-confidence compromise determination when the organization cannot validate whether low-privilege execution became unauthorized root control or whether root control resulted in credential exposure, persistence, defensive degradation, workload-boundary abuse, downstream account use, or broader infrastructure expansion.

S33 — Defensive Control & Hardening Improvements

Defensive improvement should focus on making constrained Linux execution, privilege-boundary activity, root-level control, sensitive-resource access, security-control state, scheduled persistence, workload-boundary interaction, cloud identity use, CI/CD trust, and downstream expansion measurable, governed, and recoverable. The objective is not only to patch one kernel, package, image, or CVE, but to prove that suspicious foothold-to-root behavior can be prevented, detected, scoped, contained, and separated from legitimate Linux administration and automation.

Linux Asset, Vulnerability, and Exposure Governance

·        Maintain complete inventory of Linux servers, cloud instances, Kubernetes nodes, container hosts, CI runners, build systems, developer systems, privileged automation hosts, identity-adjacent systems, repositories, databases, storage systems, backup platforms, and production-critical workloads.

·        Maintain historical kernel, package, image, node-pool, template, reboot, backport, and live-patch state rather than relying only on current scanner results.

·        Prioritize remediation for internet-facing systems, customer-facing applications, cloud workloads, Kubernetes nodes, container hosts, CI runners, build systems, identity-adjacent systems, repositories, signing systems, databases, storage systems, and privileged automation.

·        Require auditable ownership, patch windows, reboot validation, image replacement, node rotation, workload replacement, exception approval, and remediation closure.

·        Treat unknown workload ownership, unknown vulnerable-state history, unknown internet exposure, unknown credential concentration, or unknown downstream trust relationships as unresolved enterprise risk.

Privilege-Boundary and Administrative Hardening

·        Reduce unnecessary local accounts, service accounts, SUID-root binaries, setuid or setgid paths, privileged utilities, sudo permissions, passwordless administrative paths, and standing root access.

·        Require role-based privilege, least privilege, time-bounded administrative access, MFA where supported, privileged-access workflows, session recording where feasible, and auditable approval for high-risk root activity.

·        Baseline approved sudo, su, PAM, package-management, configuration-management, orchestration, backup, deployment, vulnerability-validation, and incident-response workflows.

·        Restrict compiler, linker, interpreter, download-tool, archive-tool, and execution capability on production systems where operationally feasible.

·        Treat unexplained low-privilege-to-root transition, root-owned shell creation, or service-account-originated privileged activity as high-priority investigation context.

Writable-Path, File, and Execution Hardening

·        Restrict execution from temporary directories, shared-memory paths, user-controlled paths, application workspaces, CI workspaces, build paths, mounted volumes, and container writable layers where operationally feasible.

·        Apply noexec, nodev, nosuid, read-only, application-control, or equivalent restrictions to appropriate filesystems and mounts.

·        Monitor rapid file creation, compilation, permission change, execution, deletion, archive creation, and short-lived executable behavior.

·        Remove unnecessary development tools, compilers, interpreters, transfer tools, and archive tools from production systems where feasible.

·        Maintain known-good baselines for privileged binaries, system files, scheduled tasks, security tools, authentication files, and protected configuration paths.

Credential, Secret, and Trust-Material Protection

·        Minimize credentials, SSH keys, service secrets, cloud credentials, workload identities, Kubernetes tokens, CI/CD credentials, repository credentials, deployment secrets, and signing material stored or mounted on Linux systems.

·        Use short-lived credentials, workload identity, managed identity, secret-management systems, scoped tokens, hardware-backed protection, and automated rotation where available.

·        Restrict access to credential stores, SSH directories, cloud credential paths, service-account token paths, host-mounted secrets, repository credentials, signing systems, and deployment secrets.

·        Require credential and token rotation when root compromise cannot be ruled out or protected trust material may have been accessed.

·        Map every high-value Linux workload to the credentials, identities, roles, tokens, repositories, deployment systems, and downstream services it can reach.

Container, Kubernetes, and Workload-Boundary Hardening

·        Restrict privileged containers, host-network access, host-PID access, host-IPC access, hostPath mounts, container runtime socket exposure, kubelet access, host namespace access, and unnecessary node-level permissions.

·        Enforce workload security policies, image provenance, admission controls, read-only filesystems, capability reduction, seccomp, AppArmor or SELinux controls, and non-root container execution where feasible.

·        Limit Kubernetes service account permissions, disable unnecessary token mounting, use short-lived projected tokens, and separate workload identities by namespace, role, and environment.

·        Monitor container-originated activity that results in unexpected host-level root execution, runtime-socket use, namespace entry, kubelet interaction, or host-mounted secret access.

·        Rebuild or replace affected nodes and container hosts when host-level root compromise cannot be ruled out.

Security-Control and Logging Hardening

·        Protect EDR, Linux audit, logging, telemetry forwarding, cloud agents, vulnerability scanners, container-security controls, and workload-protection services from unauthorized stopping, modification, or removal.

·        Use tamper protection, restricted service management, protected configuration, centralized policy, remote log forwarding, immutable or write-protected storage, and health monitoring where available.

·        Alert on confirmed control state changes following suspicious root-level activity.

·        Preserve endpoint, audit, journal, kernel, file, container, Kubernetes, cloud, CI/CD, identity, DNS, proxy, firewall, and NDR data before host rebuild, node rotation, workload replacement, or agent reinstallation.

·        Validate that logging and security controls remain healthy after containment and remediation.

Cloud, CI/CD, Repository, and Downstream Trust Hardening

·        Reduce standing cloud roles, managed identity permissions, service-account permissions, CI/CD privileges, repository privileges, package-registry privileges, deployment privileges, and infrastructure-management permissions available from Linux workloads.

·        Restrict metadata-service access and require modern metadata protections where supported.

·        Separate build, deployment, signing, repository, package-registry, and production identities.

·        Monitor new or unusual identity use, role activity, repository access, deployment activity, storage access, snapshot activity, remote commands, and infrastructure changes after suspicious Linux root activity.

·        Require downstream trust review when root compromise affects CI runners, build systems, repositories, signing systems, deployment platforms, Kubernetes nodes, container hosts, cloud instances, or privileged automation.

Incident Response and Containment Hardening

·        Create response procedures for suspected exploit staging, abnormal privilege transition, unauthorized root activity, sensitive-resource access, security-control degradation, cron persistence, workload-boundary interaction, cloud identity use, CI/CD access, repository access, and east-west expansion.

·        Require responders to validate affected asset, vulnerable-state history, process ancestry, source user, effective user, root process, sensitive resource, security-control state, scheduled task, container context, Kubernetes context, cloud identity, downstream activity, and remediation status.

·        Prepare decision paths for isolation, evidence preservation, patching, credential rotation, workload replacement, node replacement, security-control restoration, cloud-role restriction, repository review, deployment review, legal and compliance escalation, cyber-insurance coordination, communications planning, and executive reporting.

·        Treat suspected root compromise as a host-trust and downstream-trust incident, not only as a vulnerability-management or patching event.

·        Require post-event validation that no suspicious identity use, persistence, security-control degradation, workload-boundary activity, cloud activity, CI/CD activity, repository access, or internal expansion continued after remediation.

S34 — Defensive Control & Hardening Architecture

Figure 6

The defensive architecture should treat Linux servers, cloud workloads, Kubernetes nodes, container hosts, CI runners, build systems, and privileged automation platforms as governed trust-bearing infrastructure rather than isolated patch-management assets. The architecture must connect asset inventory, vulnerable-state history, constrained-execution visibility, privilege-transition monitoring, credential protection, workload-boundary controls, security-control integrity, cloud and CI/CD trust, network monitoring, incident-response containment, and executive trust restoration into one foothold-to-root-to-impact assurance model.

Architecture Layer One — Linux Asset and Workload Governance

Linux asset and workload governance establishes which Linux systems, cloud instances, Kubernetes nodes, container hosts, CI runners, build systems, developer systems, privileged automation platforms, and production workloads exist; which are internet-facing or trust-sensitive; which credentials and identities they hold; and which downstream systems they can access. This layer captures ownership, workload role, business criticality, exposure, vulnerable-state history, patch state, image lineage, node mapping, identity mapping, and remediation status.

Architecture Layer Two — Constrained Execution Visibility

Constrained execution visibility determines whether suspicious activity began from an application, service account, web-service process, container, CI job, developer account, automation account, or other low-privilege context. This layer captures process creation, process ancestry, user context, working directory, executable path, command line, writable-path execution, compilation, temporary artifacts, permission changes, and approved workflow context.

Architecture Layer Three — Privilege-Transition and Root-Activity Monitoring

Privilege-transition and root-activity monitoring determines whether constrained execution crossed into unauthorized root-level control. This layer captures real user, effective user, UID, effective UID, sudo, PAM, su, privileged-binary interaction, root-owned child processes, service-context execution, kernel events, authentication events, audit records, process faults, and approved administrative transitions.

Architecture Layer Four — Credential and Trust-Material Protection

Credential and trust-material protection determines whether root-level activity exposed SSH material, service credentials, application secrets, cloud credentials, workload identities, Kubernetes service account tokens, host-mounted secrets, CI/CD credentials, repository credentials, deployment secrets, or signing material. This layer captures sensitive-resource access, token use, secret retrieval, archive creation, copy activity, permission changes, ownership changes, and rotation status.

Architecture Layer Five — Security-Control and Persistence Integrity

Security-control and persistence integrity determines whether the adversary weakened detection or established recurring privileged execution. This layer captures EDR state, Linux audit state, logging state, telemetry-forwarding health, cloud-agent state, vulnerability-scanner state, container-security state, workload-protection state, root cron changes, associated scripts, execution results, protected configuration, and approved maintenance context.

Architecture Layer Six — Container, Kubernetes, and Host-Boundary Control

Container, Kubernetes, and host-boundary control determines whether suspicious root-level activity crossed workload boundaries or exposed node-level control. This layer captures container process context, pod, namespace, cluster, node, service account, workload identity, runtime-socket access, kubelet access, host namespace entry, hostPath access, host-mounted secrets, node-resource interaction, admission controls, and workload security policy.

Architecture Layer Seven — Cloud and Software-Delivery Trust Monitoring

Cloud and software-delivery trust monitoring determines whether credentials or identities exposed from the Linux system were used against cloud, CI/CD, repository, package-registry, signing, deployment, or production systems. This layer captures role use, managed identity activity, service-account activity, secret retrieval, storage access, snapshot activity, remote commands, image activity, repository access, pipeline activity, artifact activity, package publication, signing activity, and deployment changes.

Architecture Layer Eight — Network Egress and Internal Expansion Monitoring

Network egress and internal expansion monitoring determines whether the affected Linux system initiated callbacks, tunneling, tool retrieval, rare external communication, metadata access, cloud-service access, repository access, SSH fan-out, service enumeration, or trust-sensitive east-west expansion. This layer captures DNS, proxy, firewall, NDR, flow, source-workload identity, destination reputation, first-seen status, cadence, protocol, port, protected-service mapping, and approved peer baselines.

Architecture Layer Nine — SOC Correlation and False-Positive Control

SOC correlation joins Linux asset context, vulnerable-state history, process ancestry, user transition, file activity, privileged-resource access, security-control state, persistence, container and Kubernetes context, cloud identity activity, CI/CD activity, repository activity, network behavior, change-control records, and approved workflow baselines. This layer distinguishes attacker-driven activity from administration, package management, configuration management, orchestration, build activity, deployment activity, backup, monitoring, vulnerability validation, maintenance, red-team activity, and incident response.

Architecture Layer Ten — Incident Response and Executive Trust Workflow

Incident response and executive trust workflow connects technical evidence to containment and business decisions. This layer captures incident severity, affected hosts, workloads, nodes, identities, credentials, repositories, deployment systems, cloud resources, downstream services, containment actions, patch validation, host replacement, node replacement, credential rotation, security-control restoration, legal review, compliance review, cyber-insurance coordination, communications planning, executive reporting, and confirmation that host and workload trust can be restored.

Architecture Outcome

The architecture should enable the organization to answer seven questions during a Linux foothold-to-root and workload-trust incident:

·        Which Linux host, workload, container, pod, node, user, effective user, process, sensitive resource, identity, credential, security control, scheduled task, cloud resource, repository, deployment system, destination, business owner, or remediation action was affected?

·        Did the activity align with approved administration, sudo workflows, package management, configuration management, orchestration, CI/CD activity, backup, monitoring, vulnerability validation, maintenance, red-team activity, or incident response?

·        Did constrained execution transition into unauthorized root-level control?

·        Did root-level control result in credential access, security-control degradation, scheduled persistence, workload-boundary interaction, cloud activity, CI/CD or repository access, or downstream account use?

·        Can the organization isolate or replace affected systems, preserve evidence, validate vulnerable-state history, rotate exposed credentials, restore security controls, review workload boundaries, and restrict downstream trust without over-attributing legitimate Linux operations?

·        Can the organization prove that root-owned activity, sensitive-resource access, cron changes, control-state changes, cloud activity, repository activity, and network behavior were approved rather than attacker-driven?

·        Can leadership make defensible decisions about host trust, credential exposure, workload identity, cloud exposure, Kubernetes exposure, software-delivery trust, production impact, legal obligations, cyber-insurance coordination, and return-to-service approval?

S35 — Defensive Control Mapping Matrix

Preventive Controls

·        Maintain complete inventory of Linux servers, cloud instances, Kubernetes nodes, container hosts, CI runners, build systems, developer systems, privileged automation hosts, repositories, databases, storage systems, backup systems, workload identities, credentials, business owners, patch state, vulnerable-state history, and downstream trust dependencies.

·        Enforce timely patching, reboot validation, live-patch validation, image replacement, node rotation, workload replacement, exception governance, and remediation closure.

·        Reduce unnecessary SUID-root and setgid paths, standing root access, passwordless sudo, privileged utilities, local administrative accounts, compilers, interpreters, transfer tools, and archive tools on production systems.

·        Restrict execution from writable and transient paths using noexec, nodev, nosuid, read-only mounts, application control, or equivalent safeguards where operationally feasible.

·        Enforce least privilege for cloud roles, workload identities, Kubernetes service accounts, CI/CD accounts, repository accounts, package-registry accounts, deployment identities, and signing systems.

·        Restrict privileged containers, host namespaces, hostPath mounts, runtime sockets, kubelet access, metadata-service access, and unnecessary node-level permissions.

·        Protect credentials, SSH keys, service secrets, cloud credentials, Kubernetes tokens, CI/CD secrets, repository credentials, deployment secrets, and signing material through centralized secret management and short-lived identity where available.

·        Protect EDR, Linux audit, logging, telemetry forwarding, cloud agents, vulnerability scanners, container-security controls, and workload-protection services from unauthorized change.

·        Prioritize preventive controls for internet-facing workloads, Kubernetes nodes, container hosts, CI runners, build systems, repositories, signing systems, identity-adjacent services, production databases, storage systems, and privileged automation.

Detective Controls

·        Monitor suspicious shell, interpreter, compiler, build-tool, temporary-file, permission-change, executable, and rapid create-execute-delete behavior from constrained Linux contexts.

·        Monitor abnormal effective-user transition and root-owned process creation from suspicious non-root parentage.

·        Monitor unexpected SUID, setuid, setgid, privileged utility, authentication, namespace, mount, and privilege-management activity before root process creation.

·        Monitor root-level access to SSH material, service credentials, application secrets, cloud credentials, workload identities, Kubernetes service account tokens, host-mounted secrets, CI/CD credentials, repository credentials, deployment secrets, and signing material.

·        Monitor root cron creation or modification, unfamiliar scheduled scripts, temporary-path execution, encoded commands, remote communication, and recurring privileged activity.

·        Monitor EDR stops, audit-policy changes, logging changes, telemetry-forwarding disruption, cloud-agent tampering, vulnerability-scanner interference, container-security changes, and workload-protection degradation.

·        Monitor container-originated or pod-originated activity followed by host-level root execution, runtime-socket use, kubelet access, namespace entry, hostPath access, or node-resource interaction.

·        Monitor metadata access, managed identity use, role activity, secret retrieval, storage access, snapshot activity, remote commands, image activity, repository access, CI/CD activity, package-registry access, deployment changes, and signing activity after suspicious root behavior.

·        Monitor rare outbound communication, callbacks, tool retrieval, tunneling, metadata access, cloud-service access, SSH fan-out, service enumeration, and abnormal east-west expansion.

·        Require multi-signal correlation before high-confidence compromise or impact determination.

Responsive Controls

·        Isolate affected Linux hosts, containers, nodes, workloads, CI runners, build systems, or cloud instances when root compromise cannot be ruled out.

·        Preserve endpoint, audit, journal, kernel, file, authentication, container, Kubernetes, cloud, CI/CD, identity, DNS, proxy, firewall, NDR, vulnerability, and change-control evidence before cleanup or replacement.

·        Validate vulnerable-state history, process ancestry, effective-user transition, root-owned activity, sensitive-resource access, security-control state, cron state, workload-boundary interaction, identity use, and network behavior.

·        Remove unauthorized persistence, restore security controls, revoke exposed sessions, restrict cloud roles, disable compromised accounts, and block suspicious destinations.

·        Rotate administrative credentials, SSH keys, service accounts, workload identities, cloud credentials, Kubernetes tokens, CI/CD secrets, repository credentials, package-registry credentials, deployment secrets, API tokens, and signing material when exposure cannot be ruled out.

·        Rebuild or replace affected Linux hosts, cloud instances, Kubernetes nodes, container hosts, CI runners, build systems, and production workloads when forensic confidence is insufficient.

·        Review repositories, package registries, deployment systems, signing systems, cloud resources, databases, storage systems, backup platforms, and production services for downstream activity.

·        Perform legal, compliance, privacy, cyber-insurance, communications, customer-impact, partner-impact, executive, and board-level review where credential exposure, cloud compromise, Kubernetes compromise, software-delivery exposure, production disruption, or incomplete containment is suspected.

·        Confirm that host trust, workload trust, credential state, security-control health, persistence state, downstream identity activity, and post-remediation monitoring support closure.

Governance Controls

·        Maintain approved inventories for Linux assets, workloads, containers, clusters, nodes, CI runners, build systems, privileged automation, identities, credentials, repositories, deployment systems, business owners, application owners, cloud owners, and security-control owners.

·        Maintain approved workflows for administration, sudo use, package management, patching, reboot validation, configuration management, orchestration, backup, CI/CD activity, deployment activity, secret rotation, node maintenance, workload replacement, vulnerability validation, red-team activity, and incident response.

·        Require change-control for privileged-access changes, SUID changes, sudo changes, scheduled-task changes, security-control changes, image changes, node changes, cloud-role changes, Kubernetes service account changes, repository changes, deployment changes, and emergency remediation.

·        Maintain escalation criteria for abnormal privilege transition, unauthorized root activity, sensitive-resource access, security-control degradation, cron persistence, workload-boundary interaction, downstream account use, rare egress, and east-west expansion.

·        Track Linux foothold-to-root and workload-trust risk in the risk register when inventory, patching, effective-user visibility, process ancestry, sensitive-resource monitoring, security-control protection, workload mapping, cloud identity correlation, or response gaps create unresolved enterprise exposure.

Control Mapping Summary

The strongest control posture combines prevention of unnecessary privilege and trust exposure, detection of constrained-execution-to-root behavior, and response workflows that restore host trust, credential confidence, workload identity, security-control integrity, cloud and Kubernetes assurance, software-delivery trust, and business continuity. Controls should be prioritized for internet-facing Linux systems, cloud workloads, Kubernetes nodes, container hosts, CI runners, build systems, repositories, signing systems, privileged automation, identity-adjacent services, databases, storage systems, and production-critical workloads.

S36 — CyberDax Intelligence Maturity Assessment

Current Intelligence Maturity

Moderate to High

Maturity Rationale

Linux foothold-to-root privilege escalation and cloud workload trust compromise form a mature behavior-led intelligence model because the assessment is not dependent on one CVE, exploit name, kernel subsystem, package, SUID binary, proof-of-concept repository, filename, hash, syscall, or actor. Organization-specific maturity depends on whether constrained execution, exploit staging, privilege transition, root-owned activity, credential access, security-control degradation, persistence, workload-boundary interaction, cloud identity activity, CI/CD access, repository activity, and network expansion can be correlated across host, workload, identity, resource, destination, and time.

Strengths

·        The governing behavior is durable across changing Linux vulnerabilities, exploit implementations, kernel subsystems, packages, distributions, container images, cloud providers, workload types, and campaign branding.

·        The core sequence is analytically clear: constrained execution, local privilege escalation, unauthorized root-level activity, and conditional post-root credential access, security-control degradation, scheduled persistence, or downstream trust expansion.

·        Detection opportunities are strong where Linux process, audit, user-transition, file, security-control, container, Kubernetes, cloud, CI/CD, identity, and network telemetry can be correlated.

·        S25 provides behavior-led coverage across NDR, SentinelOne, Splunk, Elastic, QRadar, Sigma, AWS, Azure, and GCP, while correctly allowing zero YARA viability where artifact-driven detection would be weak.

·        Defensive controls map directly to asset governance, privilege-boundary reduction, execution restriction, credential protection, workload-boundary hardening, control-health monitoring, cloud trust reduction, software-delivery trust, and containment validation.

·        Blocks 1 through 5 remain aligned to the EXP behavior model without reverting to a single-CVE or patch-only assessment.

Maturity Gaps

·        Linux asset inventory may not reliably identify workload role, business criticality, internet exposure, vulnerable-state history, credential concentration, or downstream trust relationships.

·        Effective-user, UID, and process-ancestry fields may be missing, inconsistent, or normalized incorrectly.

·        Audit policies may not cover temporary paths, privileged execution, sensitive files, containers, CI workspaces, cron changes, or security-tool paths.

·        Endpoint visibility may be incomplete on Kubernetes nodes, container hosts, appliances, hardened systems, ephemeral workloads, or specialized Linux distributions.

·        Container-to-host and pod-to-node mappings may be incomplete or unavailable after workload replacement.

·        Sensitive-resource access may not be captured at sufficient fidelity to prove credential or secret exposure.

·        Security-control tampering may remove the telemetry required to confirm later behavior.

·        Cloud identity activity may not map reliably back to the suspected Linux workload, role, managed identity, service account, or source process.

·        CI/CD, repository, package-registry, deployment, and signing telemetry may use identities and retention periods disconnected from endpoint evidence.

·        Network telemetry may lack process, user, container, pod, or workload attribution.

·        Change-control and administrative baselines may be insufficient to separate legitimate Linux activity from attacker-driven behavior.

·        Organizations may over-rely on vulnerable-version findings, exploit artifacts, kernel warnings, isolated SUID behavior, generic root processes, or cloud anomalies.

Maturity Improvement Priorities

·        Normalize Linux asset identity, workload role, business criticality, internet exposure, owner, vulnerable-state history, patch state, image lineage, node mapping, identity mapping, and downstream trust dependencies.

·        Improve process ancestry, real-user, effective-user, UID, executable-path, working-directory, command-line, and privilege-transition visibility.

·        Improve Linux audit coverage for writable paths, privileged binaries, authentication mechanisms, sensitive resources, security controls, cron changes, containers, and CI workspaces.

·        Improve file telemetry for rapid create, compile, permission change, execute, delete, credential access, archive creation, and persistence behavior.

·        Improve security-control health monitoring and tamper protection.

·        Improve container-to-host, pod-to-node, workload-to-identity, and cloud-resource mappings.

·        Improve cloud audit, identity, metadata, secret, storage, snapshot, remote-command, image, and network-control correlation.

·        Improve CI/CD, repository, package-registry, artifact, deployment, and signing telemetry.

·        Improve DNS, proxy, firewall, NDR, east-west, and process-attributed network visibility.

·        Improve remediation evidence for host replacement, node replacement, credential rotation, control restoration, cloud-role restriction, repository review, deployment review, and post-remediation monitoring.

·        Add foothold-to-root validation steps to SOC, vulnerability management, Linux engineering, cloud engineering, platform engineering, Kubernetes operations, CI/CD operations, incident response, legal, compliance, cyber-insurance, communications, business continuity, and executive reporting workflows.

Maturity Outlook

Maturity can improve quickly when the organization prioritizes Linux asset ownership, vulnerable-state history, process ancestry, effective-user visibility, audit coverage, sensitive-resource monitoring, security-control protection, container-to-host mapping, pod-to-node mapping, cloud identity correlation, CI/CD and repository visibility, network attribution, and post-remediation assurance. The highest-value improvements are those that prove whether constrained execution became unauthorized root-level control and whether root control created broader credential, workload, cloud, software-delivery, or production trust exposure.

S37 — Strategic Defensive Improvements

Strategic improvement should focus on reducing the probability that constrained Linux access can become root-level control and reducing the amount of reusable trust available if escalation succeeds. The organization should treat Linux privilege escalation as a cross-functional resilience problem spanning vulnerability management, Linux engineering, cloud security, Kubernetes operations, container security, identity, CI/CD, repository security, detection engineering, incident response, business continuity, legal, compliance, cyber insurance, and executive governance.

Priority One — Establish Linux Trust-Tier Governance

·        Classify Linux systems by business criticality, internet exposure, workload role, credential concentration, cloud and Kubernetes privilege, CI/CD dependency, repository access, signing access, data sensitivity, and downstream trust.

·        Apply stronger patching, telemetry, privilege, credential, isolation, and rebuild requirements to high-trust systems.

·        Treat Kubernetes nodes, container hosts, CI runners, build systems, signing systems, repositories, privileged automation, identity-adjacent systems, and production databases as elevated trust tiers.

·        Require explicit ownership and restoration criteria for every elevated-trust Linux asset.

Priority Two — Reduce Privilege-Escalation Opportunity

·        Remove unnecessary SUID-root and setgid paths, standing root access, passwordless sudo, privileged utilities, local administrative accounts, compilers, interpreters, transfer tools, and writable execution paths.

·        Apply least privilege to users, service accounts, workloads, containers, CI runners, automation identities, and administrative workflows.

·        Use hardened kernels, supported distributions, timely patching, reboot validation, image replacement, node rotation, and exception governance.

·        Validate privilege-boundary controls through authorized testing without treating the test artifacts as compromise evidence.

Priority Three — Reduce Credential and Trust Concentration

·        Minimize reusable credentials, SSH keys, cloud credentials, Kubernetes tokens, CI/CD secrets, repository tokens, deployment secrets, and signing material available from any one Linux system.

·        Replace long-lived credentials with short-lived identity, managed identity, workload identity, scoped service accounts, and automated rotation where feasible.

·        Separate workload, administrative, build, deployment, repository, and signing identities.

·        Maintain rapid revocation and rotation procedures for trust material potentially exposed through root compromise.

Priority Four — Harden Cloud, Kubernetes, and Software-Delivery Boundaries

·        Restrict privileged containers, hostPath mounts, runtime sockets, kubelet access, host namespaces, metadata services, cloud roles, CI/CD privileges, repository privileges, package-registry privileges, and deployment permissions.

·        Enforce image provenance, admission control, workload policy, non-root execution, capability reduction, seccomp, AppArmor or SELinux, and read-only filesystems where feasible.

·        Separate CI runners and build systems from production trust paths.

·        Require review of cloud, Kubernetes, repository, deployment, and signing activity whenever root compromise affects a trust-bearing Linux asset.

Priority Five — Build Sequence-Based Detection and Response

·        Detect the durable sequence rather than individual artifacts: constrained execution, exploit staging, abnormal privilege transition, root-owned activity, protected-resource access, security-control degradation, persistence, workload-boundary interaction, and downstream expansion.

·        Preserve process ancestry, effective-user context, file activity, security-control health, workload mapping, identity mapping, and network attribution.

·        Route detections according to asset trust tier and business criticality without weakening evidence requirements.

·        Require investigation playbooks to distinguish failed exploitation, successful root compromise, and confirmed downstream trust abuse.

Priority Six — Make Rebuild and Trust Restoration Routine

·        Predefine when affected Linux hosts, cloud instances, Kubernetes nodes, container hosts, CI runners, build systems, or production workloads must be rebuilt or replaced.

·        Maintain trusted images, tested recovery procedures, configuration baselines, workload redeployment capability, credential rotation capability, and node replacement procedures.

·        Do not return affected systems to service solely because the vulnerability was patched or the suspicious process terminated.

·        Require explicit validation of host trust, credential state, persistence state, security-control health, workload-boundary exposure, downstream identity activity, and post-remediation telemetry.

Priority Seven — Integrate Executive and Business Decisioning

·        Define escalation thresholds for suspected root compromise on internet-facing, production-critical, regulated, cloud, Kubernetes, CI/CD, repository, signing, identity-adjacent, database, storage, backup, and privileged automation systems.

·        Maintain decision paths for customer impact, partner impact, legal review, compliance review, privacy review, cyber-insurance coordination, communications planning, production shutdown, credential rotation, and board reporting.

·        Track unresolved Linux trust, telemetry, identity, and recovery gaps in the enterprise risk register.

·        Require leadership assurance that Linux host and workload trust can be restored before normal operations resume.

Strategic Outcome

The target state is an environment in which constrained Linux execution is less likely to cross the privilege boundary, successful root compromise exposes less reusable trust, suspicious behavior can be reconstructed across host and cloud systems, affected infrastructure can be rapidly replaced, and leadership can make defensible decisions about credential exposure, workload trust, cloud and Kubernetes risk, software-delivery integrity, production impact, and return to service.

S38 — Attack Economics & Organizational Impact Model

Figure 7

Linux foothold-to-root privilege escalation changes intrusion economics by allowing an adversary with constrained access to pursue root-level control over systems that may host production applications, cloud workloads, Kubernetes nodes, container infrastructure, CI/CD pipelines, build systems, repositories, privileged automation, databases, storage services, backup platforms, credentials, workload identities, deployment secrets, or signing material. When suspicious low-privilege execution, exploit staging, abnormal privilege transition, unauthorized root-level activity, sensitive-resource access, security-control degradation, scheduled persistence, workload-boundary interaction, downstream account use, or unusual network expansion align within one investigation window, the adversary can create disproportionate business uncertainty without compromising every endpoint, user account, cloud service, cluster, repository, or production system individually.

The organization’s cost expands when responders must determine whether suspicious Linux activity remained limited to failed exploitation or approved administration, whether unauthorized root-level execution occurred, whether credentials or trust material were accessed, whether endpoint and audit controls remained reliable, whether persistence was established, whether container or Kubernetes boundaries were crossed, whether cloud or software-delivery identities were used, whether connected infrastructure was accessed, and whether affected hosts and workloads can safely return to service after remediation.

Adversary Economic Advantage

·        A constrained Linux foothold can reduce attacker friction because the adversary may begin from a compromised application, exposed service, stolen account, service account, web shell, container process, CI job, developer system, malicious dependency, or other low-privilege execution context.

·        Local privilege escalation can provide a direct path from limited access to root-level control without requiring a second remote exploit, a separate administrative credential, or individual compromise of every downstream system.

·        Root-level control can provide access to SSH material, service credentials, application secrets, cloud credentials, workload identities, Kubernetes service account tokens, host-mounted secrets, CI/CD credentials, repository credentials, deployment secrets, signing material, privileged workload interfaces, and security-control configurations.

·        Linux systems provide scalable access to high-value trust surfaces because one affected host may support cloud workloads, Kubernetes nodes, container hosts, CI runners, build infrastructure, privileged automation, repositories, databases, storage systems, backup platforms, or production services.

·        Public proof-of-concept code, repeatable vulnerable conditions, widely deployed Linux packages, exposed applications, commodity tooling, compilers, interpreters, and writable execution paths can reduce the cost of exploit staging and adaptation.

·        Normal sudo activity, package management, configuration management, orchestration, build activity, deployment activity, backup operations, vulnerability validation, troubleshooting, maintenance, red-team activity, and incident-response work can make attacker-driven behavior harder to classify quickly.

·        Ephemeral instances, containers, pods, nodes, and CI runners can reduce the likelihood that complete evidence is preserved because affected workloads may be terminated, rebuilt, rescheduled, or rotated before process, file, identity, and workload records are collected.

·        A single root-compromised Linux system with reusable credentials, cloud roles, Kubernetes access, repository access, deployment privileges, or signing capability can create disproportionate downstream exposure.

·        The adversary benefits when defenders cannot quickly determine whether root-owned activity, credential access, cron changes, security-control degradation, runtime-socket use, kubelet access, cloud activity, repository activity, or internal expansion were legitimate operations or attacker-driven behavior.

·        Downstream impact can extend into emergency patching, host isolation, workload replacement, node rotation, credential and token rotation, cloud-role restriction, repository review, pipeline suspension, signing-system review, legal assessment, compliance review, cyber-insurance coordination, communications planning, executive reporting, and host-trust restoration.

Defender Cost Expansion

·        The organization must investigate both the suspicious Linux activity and the reliability of the asset, vulnerability, endpoint, process, audit, authentication, file, security-control, container, Kubernetes, cloud, CI/CD, repository, network, change-control, remediation, and business-context evidence needed to confirm or disprove impact.

·        Response teams may need to reconstruct the initial foothold, exploit staging, process ancestry, user and effective-user transition, privileged-mechanism interaction, root-owned process creation, sensitive-resource access, security-control changes, cron persistence, workload-boundary interaction, cloud identity use, repository activity, deployment activity, and network expansion.

·        Mitigation may require emergency patching, reboot validation, host isolation, workload shutdown, node cordoning, container rescheduling, image replacement, workload rebuild, credential rotation, cloud-role restriction, Kubernetes token rotation, pipeline suspension, repository restrictions, signing-material review, security-control restoration, and post-remediation monitoring.

·        Internal exposure scoping may be required across affected Linux hosts, cloud instances, Kubernetes nodes, container hosts, CI runners, build systems, developer systems, privileged automation platforms, repositories, package registries, deployment systems, databases, storage systems, backup environments, identities, credentials, and business owners.

·        Response cost increases when asset inventory, vulnerable-state history, process ancestry, effective-user fields, Linux audit coverage, sensitive-resource monitoring, security-control health, container-to-host mapping, pod-to-node mapping, cloud identity correlation, CI/CD records, repository records, network attribution, or credential-rotation evidence are incomplete.

·        Business impact increases when defenders must determine whether root access occurred, whether credentials or tokens were exposed, whether security controls were degraded, whether persistence was established or remained active, whether workload boundaries were crossed, whether downstream identities were used, and whether affected infrastructure can safely continue operating.

·        Investigation scope expands when shared images, reusable credentials, common workload roles, centralized deployment systems, multi-region clusters, or repeated vulnerable configurations create uncertainty across multiple systems.

·        Legal, compliance, privacy, customer, partner, cyber-insurance, communications, executive, and board-level costs increase when credential exposure, regulated workload impact, software-delivery exposure, production disruption, destructive activity, or incomplete containment cannot be ruled out.

Organizational Impact Model

Linux Host and Workload Trust Impact

The organization must determine which Linux servers, cloud instances, Kubernetes nodes, container hosts, CI runners, build systems, developer systems, privileged automation platforms, identity-adjacent systems, repositories, databases, storage systems, backup platforms, and production workloads were exposed, vulnerable, affected, rebuilt, replaced, or connected to suspicious activity during the investigation window.

Constrained Execution and Privilege-Transition Impact

The organization must determine whether activity from an application user, service account, web-service process, container, CI runner, developer account, workload identity, automation account, or other constrained context remained routine execution or progressed through exploit staging, privileged-mechanism interaction, abnormal effective-user transition, root-owned process creation, or unauthorized root-level control.

Credential, Identity, and Trust-Material Impact

The organization must determine whether SSH material, service credentials, application secrets, cloud credentials, workload identities, Kubernetes service account tokens, host-mounted secrets, CI/CD credentials, repository credentials, package-registry credentials, deployment secrets, signing material, or other reusable trust resources were accessed, copied, archived, exposed, rotated, revoked, or used after suspected root compromise.

Security-Control and Evidence-Reliability Impact

The organization must determine whether endpoint protection, Linux audit, logging, telemetry forwarding, cloud agents, vulnerability scanners, container-security controls, workload-protection services, or related defensive mechanisms were stopped, disabled, modified, bypassed, degraded, restored, or rendered unreliable during the event window.

Persistence and Post-Remediation Impact

The organization must determine whether root-level cron jobs, unfamiliar scheduled scripts, exposed credentials, valid downstream accounts, modified security controls, abused workload interfaces, or other access paths allowed activity to continue after patching, process termination, workload replacement, node rotation, credential rotation, or initial containment.

Container, Kubernetes, and Workload-Boundary Impact

The organization must determine whether suspicious root-level activity remained local to the Linux host or progressed into container runtime-socket use, kubelet access, host namespace interaction, hostPath access, host-mounted secret access, node-level resource interaction, Kubernetes API activity, service account use, or broader cluster exposure.

Cloud and Software-Delivery Trust Impact

The organization must determine whether managed identities, workload identities, cloud roles, metadata services, secret-management systems, storage resources, snapshots, remote-command functions, repositories, package registries, CI/CD platforms, artifact systems, deployment platforms, or signing systems were accessed or modified through trust exposed from the affected Linux environment.

Outbound Communication and Internal Expansion Impact

The organization must determine whether affected Linux hosts, containers, Kubernetes nodes, CI runners, build systems, or cloud workloads initiated rare outbound communication, callbacks, beacon-like activity, tunneling, tool retrieval, raw-IP communication, metadata access, cloud-service access, SSH fan-out, service enumeration, repository access, package-registry access, or trust-sensitive east-west communication inconsistent with approved operations.

Production, Availability, and Business-Continuity Impact

The organization must determine whether customer-facing applications, regulated workloads, authentication services, developer platforms, repositories, deployment systems, databases, storage systems, backup platforms, production clusters, privileged automation, or critical operational services were disrupted, isolated, rebuilt, restricted, degraded, or placed at risk because host trust could not be confirmed.

Containment and Host-Trust Restoration Impact

The organization must restore host trust, workload trust, credential confidence, security-control integrity, persistence assurance, cloud and Kubernetes confidence, software-delivery trust, and business continuity through vulnerable-state validation, evidence preservation, host or node replacement, workload rebuild, credential rotation, cloud-role restriction, security-control restoration, downstream activity review, legal assessment, compliance review, cyber-insurance coordination, executive reporting, and post-remediation monitoring.

Governance Impact

Leadership may need to treat confirmed or strongly suspected Linux foothold-to-root compromise as an executive-level host-trust and infrastructure-trust incident because affected systems may support cloud workloads, Kubernetes clusters, container infrastructure, CI/CD pipelines, repositories, signing systems, privileged automation, regulated applications, databases, storage systems, backup environments, customer-facing services, and production continuity.

Economic Impact Summary

Linux foothold-to-root privilege escalation and cloud workload trust compromise create economic advantage for adversaries because constrained access can be converted into root-level control and possible exposure of credentials, workload identities, privileged interfaces, security controls, cloud resources, Kubernetes resources, software-delivery systems, and downstream infrastructure. The organization’s financial exposure grows when it cannot quickly determine whether suspicious activity remained limited to failed exploitation, whether root control was obtained, whether credentials or tokens were exposed, whether security controls were modified, whether persistence was established or retained, whether workload boundaries were crossed, whether downstream accounts were used, and whether affected hosts and workloads can safely return to operation.

S39 — Economic Impact & Organizational Exposure

Linux foothold-to-root privilege escalation and cloud workload trust compromise expand organizational exposure by increasing uncertainty around whether constrained Linux execution progressed into exploit staging, unauthorized privilege transition, root-owned execution, credential or trust-material access, security-control degradation, persistence, workload-boundary interaction, cloud or workload-identity use, software-delivery access, rare outbound communication, or internal expansion. The governing risk is not limited to GhostLock CVE-2026-43499, one Linux kernel version, one privileged utility, one exploit repository, one malware family, or one adversary. The material question is whether an existing foothold was converted into root-level control and whether that control exposed reusable organizational trust before containment.

Economic exposure rises when affected Linux systems support internet-facing services, production applications, cloud workloads, Kubernetes nodes, container hosts, CI runners, build systems, repositories, artifact registries, deployment platforms, privileged automation, identity-adjacent services, databases, storage systems, backup environments, regulated workloads, or customer-facing operations. Exposure is highest when defenders cannot separate unsuccessful exploitation from an unauthorized root transition, protected-resource access, control degradation, scheduled persistence, workload-boundary interaction, cloud-role use, Kubernetes activity, software-delivery access, rare egress, or downstream infrastructure expansion.

Estimated Economic Exposure

Estimated exposure should be treated as scenario-based rather than fixed. The most defensible enterprise estimate depends on whether activity remains limited to vulnerable-state findings, exploit-attempt behavior, suspicious writable-path execution, compilation, privileged-utility interaction, kernel faults, or failed privilege-transition activity; becomes suspected or confirmed root-level compromise; or expands into credential exposure, cloud or Kubernetes access, container-host takeover, software-delivery compromise, production disruption, destructive activity, ransomware deployment, data exposure, or multi-system trust loss.

Economic exposure increases when the organization cannot quickly determine whether suspicious activity remained limited to failed exploitation, whether a constrained process produced an unauthorized effective-root outcome, whether root-owned activity accessed protected resources, whether audit and security controls remained reliable, whether persistence was established, whether exposed credentials or tokens were reused, whether downstream cloud or Kubernetes activity originated from the affected workload, and whether endpoint, audit, identity, vulnerability, container, Kubernetes, cloud, CI/CD, repository, network, change-control, and remediation evidence can be joined into a reliable sequence.

Low Impact Scenario

Estimated $300K - $2.5M

This scenario applies when rapid investigation confirms suspicious exploit-attempt behavior, writable-path execution, compilation, privileged-utility interaction, public exploit-like artifacts, kernel warnings, short-lived files, or unusual local execution without evidence of an unauthorized root process, sensitive-resource access, credential or token exposure, security-control degradation, persistence, workload-boundary interaction, cloud identity activity, CI/CD access, rare egress, or downstream expansion. Available evidence supports a failed, contained, or non-impacting event. Response remains limited to targeted patch validation, evidence preservation, focused hunting, host isolation where necessary, administrative review, credential precaution, short-term monitoring, and executive assurance that host and workload trust were not materially affected.

Moderate Impact Scenario

Estimated $4M - $25M

This scenario applies when confirmed or strongly suspected privilege escalation affects one or more production, cloud, container, Kubernetes, CI/CD, build, identity-adjacent, privileged-automation, or high-value Linux systems and suspicious constrained execution aligns with abnormal root-owned process creation, protected-resource access, security-control degradation, persistence, rare outbound activity, cloud metadata access, runtime-socket interaction, credential access, or unusual internal expansion. The organization cannot immediately determine whether root access exposed SSH keys, service credentials, workload identities, Kubernetes tokens, cloud roles, repository credentials, deployment secrets, signing material, or downstream systems. Response may require asset review, process and audit reconstruction, root-activity analysis, sensitive-resource review, credential and token rotation, cloud and Kubernetes investigation, CI/CD and repository validation, security-control restoration, workload rebuilds, legal and compliance review, cyber-insurance coordination, executive reporting, and strengthened post-remediation monitoring.

High Impact Scenario

Estimated $30M - $150M+

This scenario applies when Linux foothold-to-root compromise becomes an enterprise-impact event involving confirmed or strongly suspected cloud-role abuse, Kubernetes node or cluster compromise, container-host takeover, CI/CD or repository access, signing-material exposure, credential reuse, privileged-automation abuse, lateral movement, production disruption, destructive activity, ransomware deployment, data exposure, or multi-system compromise. The organization may need to treat affected hosts, workload identities, SSH keys, service accounts, cloud credentials, Kubernetes tokens, deployment secrets, repository access, container images, signing material, production services, and downstream infrastructure as exposed until reliable evidence proves otherwise. Response may require broad forensic investigation, emergency workload isolation, credential and token rotation, cloud-role restriction, node and host replacement, container-image validation, pipeline suspension, repository and signing-system review, production recovery, notification analysis, legal and privacy escalation, cyber-insurance engagement, communications planning, executive and board reporting, and formal restoration of host and workload trust.

Annualized Risk Exposure

Estimated $4M - $30M+ for materially exposed enterprise environments with recurring Linux vulnerability exposure, internet-facing or production-critical workloads, cloud instances, Kubernetes nodes, container hosts, CI runners, build infrastructure, privileged automation, incomplete process lineage, unreliable effective-user fields, limited audit coverage, weak sensitive-resource monitoring, poor container-to-host mapping, incomplete cloud identity correlation, short telemetry retention, or concentrated credential and trust dependencies.

Exposure may exceed $30M - $150M+ when suspected or confirmed root compromise results in cloud-role abuse, Kubernetes compromise, container-host takeover, CI/CD or repository access, signing-material exposure, credential reuse, production disruption, destructive activity, ransomware deployment, multi-system compromise, incomplete containment, legal escalation, communications response, cyber-insurance review, or board-level reporting.

Operational Dependency

Operational dependency is high where Linux systems support production applications, cloud services, Kubernetes clusters, container infrastructure, CI/CD workflows, build and deployment platforms, repositories, privileged automation, databases, storage systems, backup environments, identity-connected services, regulated workloads, or business-critical operations. Even one affected host can create broad investigation and recovery requirements when it holds reusable credentials, assumes privileged cloud roles, operates as a Kubernetes node, manages container workloads, builds or signs software, administers downstream systems, or connects to multiple production environments.

Dependency increases when the affected system cannot be isolated, rebooted, patched, rebuilt, replaced, or removed from service without business disruption. Dependency is highest when hosts or workloads are ephemeral but identities, images, credentials, roles, repositories, artifacts, or deployment relationships persist beyond the life of the individual instance, container, pod, node, or runner.

Host and Workload Trust

Host and workload trust are reduced when the organization cannot prove that effective-user state, root-owned processes, privileged utilities, system services, cron entries, authentication configuration, audit configuration, logging configuration, endpoint security, cloud agents, runtime access, Kubernetes access, workload identities, and sensitive resources remained reliable during the activity window.

Trust is further reduced when suspicious execution originated from temporary, shared-memory, user-controlled, workspace, build, runner, mounted-volume, or container-layer paths; when a constrained process produced an unexplained root-owned process; when root activity accessed credentials or protected resources; or when controls, persistence locations, cloud identities, Kubernetes resources, repositories, deployment systems, or downstream infrastructure changed without approved administrative context.

Visibility Confidence

Visibility confidence is highest when Linux process, parent-process, effective-user, UID, file, audit, authentication, security-agent, kernel, journal, container, Kubernetes, cloud, CI/CD, repository, DNS, proxy, firewall, NDR, and network-flow telemetry can be correlated through stable host, workload, instance, node, pod, container, runner, and identity mappings.

Visibility confidence is reduced when process ancestry is incomplete, effective-user or effective-UID fields are missing, file reads are not captured, audit policy excludes temporary or sensitive paths, container-to-host or pod-to-node mapping is unavailable, ephemeral workloads are replaced before evidence preservation, security agents are degraded, cloud activity cannot be tied to the source workload, separate systems use inconsistent identities, or retention is insufficient to reconstruct the pre-remediation activity window.

S25 depends on validated effective-identity normalization, direct or credible process relationships, sensitive-resource mapping, role-aware baselines, canonical workload resolution, approved exceptions, and bounded-time correlation. It does not depend on CVE strings, malware names, actor names, exploit labels, filenames, hashes, public repository names, or isolated vulnerable-version findings.

Credential and Trust-Material Dependency

Credential and trust-material dependency is high when affected Linux systems can access SSH keys, service credentials, application secrets, cloud credentials, workload identities, Kubernetes service account tokens, host-mounted secrets, CI/CD credentials, repository tokens, package-registry credentials, deployment secrets, signing material, backup credentials, database credentials, or privileged automation accounts.

Dependency becomes materially higher when an affected host, workload, node, runner, or container can use those credentials without a second interactive authentication step; when credentials are reusable across environments; when identities possess broad cloud, cluster, repository, deployment, storage, or backup permissions; or when rotation and revocation evidence is incomplete.

Cloud, Kubernetes, and Container Dependency

Cloud, Kubernetes, and container dependency is high when constrained execution occurs on cloud Linux instances, Kubernetes worker nodes, container hosts, managed-instance-group members, CI runners, build workloads, privileged automation systems, or workloads with metadata-service or workload-identity access.

The organization must distinguish suspicious host activity from confirmed cloud or cluster compromise. Metadata access, service-account use, runtime-socket access, kubelet interaction, Kubernetes API access, secret-management activity, snapshot activity, storage access, role use, or security-control changes become materially relevant only when telemetry ties them to the affected workload, identity, node, host, or investigation window.

Software-Delivery and Repository Dependency

Software-delivery dependency is high when affected Linux systems build, test, package, sign, publish, deploy, or administer software. Root compromise on CI runners, build systems, repository hosts, artifact systems, package-registry clients, signing systems, or deployment platforms can create uncertainty around source integrity, build integrity, artifact integrity, credential exposure, release trust, and downstream deployment safety.

The organization may need to validate repository access, branch or tag changes, workflow modifications, pipeline execution, artifact publication, package-registry activity, signing-key use, deployment actions, container-image integrity, and downstream environment changes before restoring software-delivery trust.

Customer, Partner, Workforce, and Regulatory Exposure

Customer, partner, workforce, and regulatory exposure increases when suspected root compromise affects regulated workloads, customer-facing services, partner-facing systems, workforce authentication infrastructure, production clusters, repositories, signing systems, databases, storage environments, backup platforms, or systems holding sensitive credentials or data.

Exposure also increases when telemetry gaps prevent timely confirmation of whether credentials were used, data was accessed, production integrity changed, cloud or Kubernetes resources were affected, software-delivery paths were altered, customer or partner services were disrupted, or containment was complete.

Residual Economic Risk

Residual economic risk remains after patching, rebooting, process termination, host isolation, workload replacement, node rotation, credential rotation, cloud-role restriction, runtime hardening, pipeline suspension, security-control restoration, or incident-response cleanup when the pre-remediation activity window cannot be reconstructed.

Applying a kernel, package, runtime, or platform update reduces future exploitability but does not prove that exploit staging, abnormal root transition, sensitive-resource access, control degradation, persistence, credential use, cloud or Kubernetes activity, repository access, rare egress, or internal expansion did not occur before remediation. Residual risk should remain elevated until historical endpoint, audit, file, identity, vulnerability, container, Kubernetes, cloud, CI/CD, repository, network, change-control, incident-response, and remediation evidence has been reviewed.

Proof-of-Concept / KEV Behavioral Coverage Assessment

GhostLock CVE-2026-43499 is the originating anchor for this report. The vulnerability affects the Linux kernel locking subsystem and can permit a local attacker with an existing low-privilege context to pursue privilege escalation. S25 directly covers GhostLock-related activity when exploitation produces observable writable-path staging, an abnormal non-root-to-root process transition, an unauthorized root process, protected-resource access, control degradation, persistence, workload-boundary interaction, rare egress, workload-identity activity, Kubernetes interaction, or internal expansion.

Red Hat’s GhostLock bulletin also addresses CVE-2026-53166. It is not counted separately in the current direct-coverage register because the available reporting does not establish a distinct S25 coverage item beyond the shared GhostLock locking-subsystem behavior.

The model also directly covers Copy Fail CVE-2026-31431 when exploitation begins from a constrained Linux context and produces observable exploit staging, abnormal effective-root execution, root-owned activity, protected-resource access, container-to-host impact, or downstream trust activity. The governing detection relationship is the constrained-execution-to-root outcome rather than the vulnerable cryptographic-interface implementation.

CVE-2024-21626 is directly covered when a container escape produces observable host-filesystem access, host-level execution, runtime interaction, root-owned process activity, protected-resource access, or downstream expansion. A vulnerable runc version or container launch alone does not satisfy direct behavioral coverage.

CVE-2024-1086, CVE-2023-4911, CVE-2022-0847, CVE-2021-4034, CVE-2021-3156, and CVE-2016-5195 are directly covered when exploitation produces S25-visible staging, privileged-mechanism interaction, abnormal effective-root transition, root-owned execution, protected-resource access, persistence, control degradation, or follow-on network and workload behavior.

Known exploitation, KEV inclusion, exploit publication, vendor priority, scanner coverage, and vulnerable-version state are urgency and remediation inputs. They are not proof that compromise occurred in a specific environment. Local compromise assessment must remain grounded in process, identity, root activity, file activity, control health, workload, cloud, Kubernetes, CI/CD, repository, network, and incident-response evidence.

Detection Engineering Coverage Interpretation

The S25 detection content provides direct behavioral coverage when activity produces one or more of these implemented outcomes:

·        Suspicious execution or exploit staging from writable, transient, build, workspace, runner, mounted-volume, or container-layer paths

·        Affirmatively identified non-root execution followed by an unauthorized effective-root process

·        Root-owned process creation from suspicious non-administrative, writable-path, application-service, container, CI, or scripted parent context

·        Root-level access to credentials, SSH material, cloud credentials, workload identities, Kubernetes tokens, runtime sockets, CI/CD credentials, repository credentials, signing material, persistence locations, or security-control resources

·        Directly confirmed security-agent, audit, logging, or telemetry degradation

·        Rare or role-inconsistent outbound communication

·        Cloud metadata or workload-identity access followed by anomalous cloud-service or network activity

·        Abnormal east-west expansion into SSH, Kubernetes, kubelet, runtime, identity, database, storage, backup, repository, package-registry, CI/CD, deployment, orchestration, or infrastructure-management services

Detection coverage is behavior-led rather than vulnerability-led. The rules do not identify GhostLock, Copy Fail, Dirty Pipe, PwnKit, Looney Tunables, Baron Samedit, Dirty COW, or another vulnerability by name. They identify observable execution, privilege-transition, root-activity, protected-resource, control-degradation, workload, cloud, and network behavior.

Named malware and adversary coverage is procedure-led. S25 can detect a documented malware or adversary procedure when that procedure produces observable Linux execution, root-level activity, persistence modification, protected-resource access, control degradation, workload-boundary interaction, outbound communication, or internal expansion. It cannot identify the malware family or attribute the activity to an adversary from those behaviors alone.

Direct Coverage

Direct coverage applies where documented exploitation or post-compromise procedures produce observable behavior inside the S25 model.

Directly Covered CVEs

·        CVE-2026-43499 — GhostLock

·        CVE-2026-31431 — Copy Fail

·        CVE-2024-21626 — runc container escape

·        CVE-2024-1086 — Linux kernel nf_tables use-after-free privilege escalation

·        CVE-2023-4911 — Looney Tunables

·        CVE-2022-0847 — Dirty Pipe

·        CVE-2021-4034 — PwnKit

·        CVE-2021-3156 — Baron Samedit

·        CVE-2016-5195 — Dirty COW

These CVEs are directly covered at the behavioral level when exploitation produces observable staging, privileged-mechanism interaction, abnormal effective-root transition, root-owned execution, container or namespace boundary impact, protected-resource access, persistence, security-control degradation, or downstream workload, cloud, Kubernetes, identity, or network activity. Direct coverage does not mean every exploitation attempt will be detected or that an alert identifies the specific CVE.

Directly Covered Malware Procedure Sets

·        Exaramel for Linux — shell-command execution, payload transfer, persistence, and outbound operator communication

·        Skidmap — malicious kernel-module loading, rootkit-supported mining activity, persistence, and security-control interference

·        Kinsing — container-based payload execution, cryptominer deployment, external communication, and spread to additional containers or hosts

·        Hildegard — Kubernetes workload access, container expansion, payload execution, and cryptomining-related outbound activity

These entries represent coverage of the listed procedures only. They do not represent malware-family identification or complete coverage of every capability associated with the malware.

Directly Covered APT or Activity-Group Procedure Sets

·        Sandworm or TeleBots — Linux Exaramel procedures involving persistence, shell-command execution, file transfer, and operator communication

·        TeamTNT — Hildegard-related Kubernetes access, container expansion, payload execution, and cryptomining behavior

These entries represent procedure coverage only. Actor attribution requires independent intelligence concerning infrastructure, victimology, tooling, targeting, operational patterns, and incident-specific evidence.

Coverage With Adaptation

Coverage with adaptation applies where related activity falls inside the report’s behavior model but requires additional local telemetry, mappings, or correlation.

·        In-memory privilege escalation without a directly observable root child process requires kernel, audit, eBPF, memory, or alternative process-state telemetry.

·        Existing-process injection requires telemetry capable of exposing process manipulation or the resulting root-level activity.

·        Crash-only or denial-of-service triggering requires kernel-fault, journal, audit, and workload-health telemetry and cannot be treated as successful privilege escalation without root-outcome evidence.

·        Container escapes without obvious host-level process ancestry require validated container-to-host, pod-to-node, namespace, runtime, kubelet, and host-resource mappings.

·        SUID, setgid, file-capability, namespace, mount, authentication, or privileged-utility abuse requires environment-specific privileged-object baselines and approved administrative exceptions.

·        Cloud metadata or workload-identity activity requires provider-specific endpoint mappings, canonical workload resolution, role baselines, and cloud-audit enrichment.

·        Kubernetes and container-runtime activity requires local API, kubelet, runtime-socket, node, pod, service-account, and host-mounted-resource mapping.

·        Malware and adversary procedures that use approved destinations, existing root processes, living-off-the-land utilities, service managers, schedulers, orchestration tools, or legitimate automation require stronger identity, ancestry, file, command, change-control, and bounded-time correlation.

·        Repository, package-registry, CI/CD, signing, deployment, storage, backup, or infrastructure-management activity requires local service classification, identity mapping, expected-peer baselines, and business-owner context.

Non-Coverage Conditions

Non-coverage applies where activity does not produce observable exploit staging, effective-user transition, root-owned execution, suspicious parent context, protected-resource access, control degradation, persistence, workload-boundary interaction, anomalous cloud or identity activity, rare egress, or abnormal internal expansion.

Non-coverage applies when activity remains limited to:

·        Vulnerable or unpatched Linux kernel, package, utility, image, runtime, or platform state

·        CVE identifiers, scanner findings, package-version findings, kernel-version findings, or exposure-management records without behavioral evidence

·        Public proof-of-concept availability, repository references, exploit names, hashes, filenames, strings, or advisories without local execution evidence

·        Failed or crash-only triggers that produce no root transition or covered follow-on behavior

·        In-memory exploitation that produces no observable process, file, identity, control, workload, cloud, Kubernetes, or network effect

·        Injection into an existing root process when available telemetry does not expose the manipulation or follow-on activity

·        Container execution without evidence of host-level escape, runtime interaction, kubelet access, host-resource access, or host-level execution

·        Root activity that cannot be distinguished from approved administration, package management, configuration management, orchestration, deployment, backup, vulnerability validation, red-team work, or incident response

·        Cloud, network, repository, CI/CD, or downstream anomalies that cannot be tied to the affected Linux host, workload, identity, or investigation window

·        Malware-family, campaign, or actor names without observable procedures

·        Environments where process lineage, effective identity, file activity, audit records, canonical workload mapping, protected-resource classification, role baselines, approved exceptions, or required retention are unavailable

Current Coverage Count

Directly Covered CVEs: 9

·        CVE-2026-43499

·        CVE-2026-31431

·        CVE-2024-21626

·        CVE-2024-1086

·        CVE-2023-4911

·        CVE-2022-0847

·        CVE-2021-4034

·        CVE-2021-3156

·        CVE-2016-5195

Directly Covered Malware Procedure Sets: 4

·        Exaramel for Linux

·        Skidmap

·        Kinsing

·        Hildegard

Directly Covered APT or Activity-Group Procedure Sets: 2

·        Sandworm or TeleBots

·        TeamTNT

The three counts remain separate because CVEs, malware procedures, and actor procedures are different coverage units. No combined coverage total should be used.

Coverage Qualification

Coverage is strongest where suspicious constrained execution can be joined with affirmative non-root identity, direct or credible process lineage, an unauthorized effective-root outcome, root-level protected-resource activity, directly confirmed control degradation, persistence, runtime or Kubernetes interaction, rare egress, metadata or workload-identity activity, or abnormal internal expansion.

Coverage is weaker for in-memory exploitation, existing-process injection, missing effective-user fields, incomplete ancestry, short-lived artifacts, ephemeral workloads, invisible link-local metadata traffic, shared egress, service-mesh or overlay ambiguity, incomplete file-read telemetry, missing container-to-host mapping, missing pod-to-node mapping, approved cloud services, legitimate schedulers, expected orchestration, and environments where endpoint, audit, identity, workload, cloud, Kubernetes, CI/CD, repository, and network telemetry cannot be joined.

The report does not claim universal GhostLock detection, universal Linux privilege-escalation detection, universal container-escape detection, universal Kubernetes detection, universal cloud-compromise detection, malware-family identification, complete adversary coverage, universal KEV coverage, or standalone attribution. Detection confidence depends on telemetry completeness, field mapping, effective-identity fidelity, process-lineage integrity, protected-resource classification, asset inventory, canonical workload resolution, role-aware baselines, approved exceptions, query validation, retention, performance testing, false-positive testing, and SOC triage readiness.

Executive Exposure Statement

The organization’s economic exposure is highest when constrained Linux execution creates uncertainty around whether host, workload, credential, cloud, Kubernetes, CI/CD, repository, signing, and downstream infrastructure trust remained intact. The strategic risk is not only that GhostLock or another privilege-escalation vulnerability exists, public exploit code is available, or a scanner identified an affected system. The material risk is that an adversary may have converted a low-privilege foothold into root-level control, accessed reusable trust material, weakened defensive evidence, established persistence, crossed workload boundaries, used cloud or Kubernetes identities, affected software-delivery systems, communicated externally, expanded internally, or undermined confidence in production infrastructure.

S40 — References

Vendor and Platform Security Advisories

·        Red Hat — RHSB-2026-010 Locking Subsystem Privilege Escalation, Linux Kernel, CVE-2026-43499 and CVE-2026-53166, GhostLock — hxxps://access[.]redhat[.]com/security/vulnerabilities/RHSB-2026-010

·        Red Hat — RHSB-2026-002 Cryptographic Subsystem Privilege Escalation, Linux Kernel, CVE-2026-31431, Copy Fail — hxxps://access[.]redhat[.]com/security/vulnerabilities/RHSB-2026-002

·        Open Container Initiative — runc Security Advisory, Several Container Breakouts Due to Internally Leaked File Descriptors, CVE-2024-21626 — hxxps://github[.]com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv

·        Red Hat — Dirty COW Linux Kernel Local Privilege Escalation, CVE-2016-5195 — hxxps://access[.]redhat[.]com/security/vulnerabilities/DirtyCow

Government Vulnerability and Exploitation Records

·        NVD — CVE-2026-43499 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-43499

·        NVD — CVE-2026-31431 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-31431

·        NVD — CVE-2024-21626 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2024-21626

·        NVD — CVE-2024-1086 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2024-1086

·        NVD — CVE-2023-4911 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2023-4911

·        NVD — CVE-2022-0847 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2022-0847

·        NVD — CVE-2021-4034 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2021-4034

·        NVD — CVE-2021-3156 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2021-3156

·        NVD — CVE-2016-5195 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2016-5195

·        CISA — Known Exploited Vulnerabilities Catalog — hxxps://www[.]cisa[.]gov/known-exploited-vulnerabilities-catalog

Threat Technique Framework

·        MITRE ATT&CK — hxxps://attack[.]mitre[.]org/

Original Security Research and Threat Analysis

·        Qualys Threat Research Unit — Looney Tunables: Local Privilege Escalation in the glibc ld.so, CVE-2023-4911 — hxxps://www[.]qualys[.]com/2023/10/03/cve-2023-4911/looney-tunables-local-privilege-escalation-glibc-ld-so.txt

·        Qualys Threat Research Unit — PwnKit: Local Privilege Escalation in Polkit pkexec, CVE-2021-4034 — hxxps://www[.]qualys[.]com/2022/01/25/cve-2021-4034/pwnkit.txt

·        Qualys Threat Research Unit — Baron Samedit: Heap-Based Buffer Overflow in Sudo, CVE-2021-3156 — hxxps://www[.]qualys[.]com/2021/01/26/cve-2021-3156/baron-samedit-heap-based-overflow-sudo.txt

·        CM4all — Dirty Pipe: The Dirty Pipe Vulnerability, CVE-2022-0847 — hxxps://dirtypipe[.]cm4all[.]com/

·        Notselwyn — Universal Local Privilege-Escalation Proof of Concept for CVE-2024-1086 — hxxps://github[.]com/Notselwyn/CVE-2024-1086

·        ESET — Sandworm: A Tale of Disruption Told Anew, Including Linux Exaramel — hxxps://www[.]welivesecurity[.]com/2022/03/21/sandworm-tale-disruption-told-anew/

·        Trend Micro — Skidmap Linux Malware Uses Rootkit Capabilities to Hide Cryptocurrency-Mining Payload — hxxps://www[.]trendmicro[.]com/en_us/research/19/i/skidmap-linux-malware-uses-rootkit-capabilities-to-hide-cryptocurrency-mining-payload.html

·        Aqua Security — Kinsing Malware Attacks Targeting Container Environments — hxxps://www[.]aquasec[.]com/blog/threat-alert-kinsing-malware-container-vulnerability/

·        Palo Alto Networks Unit 42 — Hildegard: New TeamTNT Cryptojacking Malware Targeting Kubernetes — hxxps://unit42[.]paloaltonetworks[.]com/hildegard-malware-teamtnt/