FG-RCA: Kernel-Anchored Post-Exploitation Containment for IoT with Policy Synthesis and Mitigation of Zero-Day Attacks

Abstract

Zero-day intrusions on IoT endpoints demand defenses that curtail attacker impact and persistence after breach. This article presents Fine-Grained Runtime Containment Agent (FG-RCA), a lightweight post-exploitation containment system that learns least-privilege behavior from execution and enforces it in the kernel via eBPF with Linux Security Modules (LSM). In a learn phase, LSM/eBPF probes stream security-relevant events to a Rust agent that synthesizes policies per device role. In an enforce phase, policies are compiled into eBPF maps and evaluated at an extended hook set spanning process execution (bprm_check_security), file access (file_open), network egress and exfiltration (socket_connect, socket_sendmsg), privilege use (capable), process injection (ptrace_access_check), tamper/anti-forensics (inode_unlink). Policies bind to kernel-truth identities—inode, device, mount intrusion detection system (IDS), executable SHA-256, and cgroup/namespace identifiers—rather than paths, mitigating time-of-check to time-of-use (TOCTOU) and aliasing. Operational safeguards include Ed25519-signed policies, atomic rollback, and shadow mode logging events to enable policy evolution. Evaluation on embedded Linux demonstrates containment with low overhead.

1. Introduction

The accelerating deployment of Internet-of-Things (IoT) endpoints across safety-critical, industrial, and consumer environments has substantially widened the attack surface while simultaneously tightening CPU, memory, storage, and power budgets on devices that operate unattended and over intermittent links. Conventional defenses—such as signature-based intrusion detection, anomaly scoring, and perimeter-centric controls—tend to be brittle against zero-day exploits, “living-off-the-land” (LotL) techniques, and post-exploitation tradecraft that deliberately mimics legitimate activity [1,2,3]. After an initial compromise, adversaries typically progress along well-documented kill chains that encompass privilege escalation, persistence, lateral movement, command-and-control (C2), and data exfiltration, where each stage is realized through sequences of process executions, file operations, capability uses, and network connections at the operating system boundary. On constrained IoT devices, these actions often occur on multi-purpose Linux images that lack fine-grained, role-specific enforcement, increasing the likelihood that post-exploit activity remains undetected and unblocked until impact is realized.

This work presents the FG-RCA, a lightweight, on-device mechanism for post-exploitation containment on embedded/IoT Linux. Rather than attempting to forecast or classify every malicious behavior, FG-RCA enforces least-privilege runtime behavior learned from benign execution and anchored in kernel-truth identities. Most IoT roles (e.g., sensors, cameras, gateways) exhibit narrow and quasi-stationary operational patterns; encoding these patterns as compact allow-lists and enforcing them at LSM hooks enables the system to deny attacker actions before execution, even when the underlying exploit is unknown [2,4,5]. FG-RCA compiles learned policies into eBPF maps and evaluates them at BPF-LSM program-type hooks [6,7] that span the dominant post-exploitation surface: bprm_check_security (process execution), file_open (file access), socket_connect and socket_sendmsg (egress/exfiltration), inode_unlink and inode_rename (tamper/anti-forensics), kernel_module_request (rootkit prevention), capable (privilege use), and ptrace_access_check (code injection). Lookups are performed over bounded-size maps, yielding constant-time decisions and predictable cost on embedded-class CPUs [8,9].

FG-RCA is designed to address two systemic limitations observed in host defenses for IoT endpoints. (i) Identity brittleness and TOCTOU. Path-based whitelisting and traditional mandatory access control (MAC) policies are vulnerable to aliasing through symbolic links, bind mounts, and container/namespace indirection, and they suffer from TOCTOU races. In such regimes, policies keyed solely on paths, processes identifiers (PIDs), or user identifiers (UIDs) are inherently mutable and context-relative. FG-RCA instead binds policy keys to kernel-truth identities: file-system tuples (inode, device major/minor, mount ID), executable SHA-256 content hashes, and process context (cgroup and namespace identifiers). These invariants remain stable across renames, namespace remappings, and mount re-rooting, thereby closing evasion avenues highlighted in classic TOCTOU analyses and modern namespace isolation behavior [10,11]. This design choice builds on the evolution of eBPF from the original Berkeley Software Distribution (BSD) Packet Filter architecture [12], repurposing its safety and expressiveness for robust authorization rather than mere observation. (ii) Detect-only eBPF usage. While eBPF is widely adopted as a substrate for low-overhead kernel telemetry in cloud and container environments, many existing deployments attach primarily to tracepoints or kprobes and export rich event streams to the user space for offline or near-real-time analytics. For IoT endpoints, this detect-only architecture is often insufficient: decisions occur after the fact, continuous streaming is constrained by bandwidth and connectivity, and resource budgets preclude heavyweight analytics stacks. FG-RCA instead leverages BPF-LSM for synchronous authorization decisions and uses BPF Type Format/Compile Once—Run Everywhere (BTF/CO-RE) to compile portable artifacts that run across heterogeneous kernels without per-device probes or cross-compilation [8,9,13,14,15].

FG-RCA exposes two phases with operational safeguards. In Learn mode, LSM/eBPF probes emit security-relevant events to a Rust userspace agent, which aggregates benign traces and synthesizes role-specific, compact policies (process, file, network) sized for embedded footprints. In Enforce mode, a policy compiler verifies Ed25519 signatures, executes an atomic policy swap with automatic rollback on failure, and loads rule sets into eBPF maps; subsequent security-relevant operations are checked pre-execution and denied with -EPERM when disallowed [16]. A shadow mode records would-block events to support safe policy evolution and transparent analysis of potential false positives in production [17].

Threat model and assumptions. The system assumes an adversary who has already achieved arbitrary user-space code execution on an IoT Linux endpoint through a zero-day exploit, weak credentials, or misconfiguration—and whose objective is to perform post-exploitation actions such as privilege escalation, persistence, log tampering, lateral reconnaissance, C2 bootstrap, and data exfiltration. Physical attacks, secure-boot bypasses, hardware tampering, and kernel-resident rootkits capable of disabling the LSM are considered out of scope. FG-RCA assumes a Linux kernel with BPF-LSM enabled and sufficient BTF metadata to support CO-RE-based builds on representative embedded distributions (e.g., OpenWrt, Raspberry Pi operating system (OS)) [13,18,19]. Prevention of initial access remains the responsibility of upstream network and host controls (segmentation, patching, intrusion detection/prevention system (IDS/IPS)); FG-RCA is positioned explicitly as a fourth layer that engages after compromise, complementing existing detection and prevention mechanisms rather than replacing them [20].

Under this threat model, the work makes the following contributions. First, it introduces a deployable, cloud-optional learn→enforce pipeline that synthesizes and enforces least-privilege policies on embedded/IoT Linux using identity-correct keys. Second, it defines a policy key design that is resilient to path and namespace manipulation as well as TOCTOU races, by grounding decisions in inode/device/mount identifiers, cgroup/namespace context, and executable SHA-256 hashes. Third, it extends BPF-LSM coverage across execution, file system, networking, privilege use, code injection, and tamper primitives that are central to post-exploit kill chains, thereby converting detection into pre-execution denial at the syscall authorization boundary. Finally, it incorporates an operational safety layer—including Ed25519-signed policies, atomic updates with rollback, and shadow-mode logging—tailored to continuous hardening on constrained IoT endpoints [8,9,13,16,17]. Together, these elements form a kernel-anchored containment system intended to provide substantial post-exploitation mitigation with overheads compatible with router- and sensor-class devices.

FG-RCA is evaluated using a multi-granular framework that bridges scenario-level security outcomes and kernel-level enforcement cost, spanning attack scenarios, MITRE ATT&CK techniques, real-time attack actions, LSM hook events per second, and multi-hour benign stress-test event totals. This prevents misinterpretation when comparing high-level blocking effectiveness with low-level syscall-scale throughput.

2. Related Work

Network intrusion detection (signature- and anomaly-based) was the classical network intrusion detection system/host-based intrusion detection system (NIDS/HIDS) approach that either matched known attack signatures or scored deviations from statistical baselines. Signature systems generally achieve high precision but are ineffective against zero-day behaviors and LotL activity that resembles legitimate operations. Anomaly-based systems extend coverage but face concept drift, tuning overhead, and explainability limitations—particularly on IoT devices with bursty workloads and strict resource budgets. Surveys consistently report the brittleness of both families to previously unseen behaviors and post-exploitation steps that occur after initial compromise [1,2,21,22,23,24]. In embedded deployments, streaming telemetry to cloud classifiers is often impractical due to bandwidth and privacy constraints, whereas on-device ML remains limited by memory and CPU. Importantly, detection-only pipelines seldom interdict actions at the syscall boundary; alerts typically arrive after persistence, credential access, or exfiltration has executed.

Mandatory access control (MAC) and path-anchored safelisting were implemented in Linux MAC systems (e.g., AppArmor, SELinux) to constrain programs using policy rules [25,26]. In practice, path-based policies are exposed to aliasing (symlinks, bind mounts), namespace re-rooting, and time-of-check vs. time-of-use (TOCTOU) races—well-documented issues in OS security literature [10,17,27]. Vendors of IoT devices frequently deploy coarse policies to avoid breakage, leaving sizable enforcement gaps. Tighter per-role allow-lists are possible but costly to author and maintain across heterogeneous devices and frequent software updates. Moreover, traditional MAC enforcers rarely bind decisions to kernel-truth identities (e.g., inode/device/mount tuples, content hashes, cgroup/namespace context) that remain stable across renames and container boundaries, allowing aliasing-based evasions to persist [11,27].

Containerization and isolation primitives were provided by Linux namespaces and cgroups, which provide isolation and resource governance but do not constitute authorization policies. Within a namespace, a compromised process can still perform post-exploitation (e.g., ptrace_access_check, sensitive file reads, egress) unless additional checks intervene [11,27]. These indirection layers also complicate path-anchored policies: file and process identities change across namespaces, increasing the risk of false negatives (missed blocks) or false positives (benign denials) for naïve designs.

BPF is now widely used for observability and detect-only security, where eBPF has become a standard substrate for low-overhead, kernel-resident telemetry [28]. Most systems attach to tracepoints/kprobes to observe system calls and kernel events, then export the flows to the user space for analysis. While performant, this architecture is detect-only: decisions occur after the event or out of band—too late for strong containment. In IoT, memory pressure and intermittent connectivity further limit continuous streaming analytics. Historically, portability required per-kernel builds; modern BTF/CO-RE largely resolves this, enabling single-artifact portability across diverse kernels [8,9,13,15]. (eBPF’s packet-path acceleration via XDP is complementary [29]).

BPF-LSM for enforcement were the BPF-LSM hook family [6,7] which introduces synchronous authorization to eBPF: programs run in the authorization path and can deny operations (e.g., bprm_check_security, file_open, socket_connect, socket_sendmsg, capable, ptrace_access_check, inode_unlink) [8,9]. Prior works and vendor prototypes typically cover subsets of these hooks—often focusing on process execution, file opens, or connect events—to log suspicious actions, raise audit signals, or implement coarse allow-lists. However, three persistent gaps are observed for IoT hardening: (i) identity brittleness—policies keyed by paths or PID/UID remain mutable or context-relative; (ii) narrow hook coverage—tamper (unlink), privilege (capable), injection (ptrace_access_check), and user datagram protocol (UDP) exfiltration (sendmsg) surfaces are frequently omitted; and (iii) operations safety—few solutions deliver a complete learn→enforce lifecycle with signed policies, atomic rollback, and “shadow/complain” modes for safe policy evolution [8,9,14,17,30].

Position of FG-RCA relative to prior work was that the proposed FG-RCA system targets these gaps with an on-device learn→enforce pipeline tailored for embedded/IoT Linux. First, it binds decisions to kernel-truth identities—(inode, device major/minor, mount ID) for files; executable SHA-256 for binaries; and cgroup/namespace context for processes and sockets—neutralizing aliasing and TOCTOU issues noted in OS and namespace literature [10,11,27]. Second, it attaches nine BPF-LSM program type [6,7] hooks that jointly span dominant post-exploitation steps (exec, file, tamper, egress/exfiltration, privilege use, process injection), converting detection into pre-execution denial at the authorization point [8,9]. Third, it couples enforcement with a production-oriented operations layer: Ed25519-signed policies, portable CO-RE builds, atomic policy swaps with rollback, and a shadow mode that logs would-block decisions to de-risk policy tightening [13,17,30]. Compared with anomaly-centric approaches [1,2] or path-anchored MAC [17], FG-RCA learns compact least-privilege allow-lists per device role and enforces them with constant-time map lookups, remaining within IoT-class CPU/memory budgets while preserving auditability.

Table 1. Comparison of approaches for post-exploitation defense on IoT Linux.

Approach	Enforcement & Identity (Where Decisions Happen; How Subjects Are Identified)	Coverage & Ops (What It Stops; Operational Characteristics)
Signature/Anomaly NIDS/HIDS [1,2]	Out-of-band analytics; flow/path/user attributes (mutable).	Detects signatures/anomalies; no inline block; high tuning effort.
MAC (AppArmor/SELinux) [17]	Kernel LSM; path-anchored labels/paths.	Blocks exec/file; weak for injection/tamper; manual policies.
Namespaces/cgroups [11,27]	Isolation & quotas; namespace/cgroup IDs.	Isolates resources; no authentication decisions; orchestrator dependent.
eBPF Observability (trace/kprobe) [8,9,13]	Kernel tracing; decision in user space; PID/comm/args (mutable).	Broad visibility; detection-only; rich, portable telemetry.
FG-RCA (proposed)	Kernel BPF-LSM inline enforcement with stable kernel identities [8,9,13,14,15,16,17,30].	Blocks exec/file/egress/privilege/inject/tamper; IoT-friendly O(1) lookups.

contrasts five families by (i) where enforcement occurs and how identities are bound, and (ii) what coverage and operational properties are delivered. NIDS/HIDS approaches [1,2] provide out-of-band detection but cannot deny actions in real time, and they incur model-tuning overhead and potential cloud dependency. MAC systems such as AppArmor/SELinux [17] enforce in the kernel but are path-anchored, which exposes policies to aliasing and namespace re-rooting unless carefully engineered. Namespaces and cgroups [11,27] supply isolation and resource governance rather than authorization; they contain but do not decide. eBPF observability stacks [8,9,13] deliver low-overhead, portable telemetry (BTF/CO-RE) yet remain detect-only when decisions are deferred to user space. In contrast, FG-RCA operates inside the authorization path using BPF-LSM, grounding decisions in kernel-truth identities (inode/device/mount tuples, executable SHA-256, and cgroup/namespace context) and covering the dominant post-exploitation surfaces—execution, file access, egress, privilege use, injection, and tamper—while providing production-grade operations (shadow mode, signed policies, and atomic rollback) suitable for IoT footprints [8,9,13,14,15,16,17,30].

This method is novel because it delivers identity-correct authorization—grounding decisions in immutable kernel facts such as inode/device/mount tuples, executable SHA-256, and cgroup/namespace context—to close evasion vectors from renames, bind mounts, and namespace re-rooting documented in prior OS research [10,11,27]. It further achieves comprehensive post-exploitation coverage by enforcing through nine BPF-LSM program types [6,7] hooks (execution, file access, egress/UDP send, privilege use, process injection, and tamper), providing synchronous containment across the kill-chain surfaces most relevant to zero-day impact and surpassing the narrower hook sets typical of earlier eBPF defenses [8,9,13,14,30]. Finally, it introduces a production-grade learn→enforce lifecycle for IoT: a cloud-optional pipeline that learns compact per-role allow-lists on device, then signs (Ed25519) and atomically swaps policies with rollback and shadow mode—enabling safe, iterative hardening under tight CPU/RAM budgets, beyond what anomaly-only NIDS/HIDS or legacy MAC tooling typically offer [1,2,17]. Collectively, these properties yield a lightweight, enforce-time containment layer that resists path/namespace brittleness, covers the whole post-exploit surface at the syscall authorization boundary, and remains practical for resource-constrained IoT devices [1,2,8,9,10,11,13,14,17,27,30].

Table 2. Summary of the main differences between FG-RCA and Tetragon in terms of target environment, security objective, and policy/enforcement model.

Dimension	Implementation Status	Validation Result
Target environment	Embedded/IoT Linux endpoints (no Kubernetes).	Kubernetes/cloud-native clusters.
Main goal	On-device least-privilege, post-exploitation blocking.	Runtime security and rich observability.
Identity/policy model	Learned allow-lists over stable kernel identities.	Operator-defined, label/path-based policies.
Enforcement workflow	Built-in learn → shadow → enforce on device.	Events streamed to central control plane for policy.
Resource assumptions	Optimized for constrained IoT/edge hardware.	Assumes node-class CPU/RAM and continuous telemetry.

provides comparison with modern eBPF-based tools and shows that the proposed system is complementary rather than equivalent to modern eBPF-based runtime security platforms such as Cilium Tetragon. Tetragon attaches eBPF programs primarily at tracepoints, kprobes, and LSM hooks to capture rich, structured event streams describing process execution, file and network activity, and container context, and then forwards these events to a userspace control plane where policies—typically expressed over Kubernetes abstractions (pods, namespaces, labels) and higher-level process/file descriptors—are evaluated and enforced. Its design is optimized for cloud-native, multi-tenant clusters, where continuous telemetry export and tight integration with SIEM/SOAR and observability stacks are assumed. In contrast, the FG-RCA design emphasizes on-device, identity-centric enforcement on resource-constrained Linux/IoT endpoints without an orchestration layer. Enforcement is implemented directly at BPF-LSM hooks (e.g., bprm_check_security, file_open, socket_connect and socket_sendmsg, inode_unlink and inode_rename, kernel_module_request, capable, and ptrace_access_check), where decisions are taken via constant-time lookups into compact eBPF maps keyed by stable kernel identities (executable hash, inode/device/mount tuples, and cgroup/namespace identifiers). Policies are synthesized via an integrated learn → shadow → enforce pipeline rather than authored manually, and are distributed as small, signed artefacts that can be applied even in intermittently connected scenarios. Whereas Tetragon prioritizes high-fidelity observability plus centrally managed enforcement in Kubernetes environments, FG-RCA prioritizes minimal control-plane dependency, small memory footprint, and least-privilege containment directly on the endpoint. Both approaches rely on eBPF in the authorization path. However, they occupy different points in the design space: Tetragon as a cluster-wide runtime security and observability fabric, and FG-RCA as a role-specific, identity-accurate containment layer tailored to embedded and IoT devices.

3. System Architecture

Overview of FG-RCA is an on-device, two-tier containment system for embedded/Linux IoT that combines eBPF programs attached to LSM hooks in kernel space with a Rust agent in user space. The system follows a learn→enforce lifecycle. Instead of relying on user-space paths or process names, FG-RCA grounds authorization in kernel-truth identities—immutable facts like inode + device + mount, executable content hash, cgroup and namespace context, and socket tuples. That design eliminates aliasing and TOCTOU pitfalls that commonly break path-based policy engines [1,2]. Hot-path enforcement is constant-time via BPF map lookups; off-path learning, policy signing (Ed25519), and atomic updates are handled by the agent [8,9,20]. The system enforces policies at nine LSM hooks: bprm_check_security (process execution), file_open (file access), socket_connect and socket_sendmsg (egress/exfiltration), inode_unlink and inode_rename (tamper/anti-forensics), kernel_module_request (rootkit prevention), capable (privilege use), and ptrace_access_check (code injection). Figure 1 shows the key components involved in system architecture. Also operational screenshots of these phases are provided in Appendix A Figure A1, Figure A2 and Figure A3.

Design goals, assumptions, and constraints were FG-RCA’s four goals:

• Deny out-of-policy actions before they execute.
• Operate entirely on-device, with no cloud dependency.
• Keep CPU and memory overheads low enough for router-class devices.
• Produce auditable artifacts (learned benign allow-lists, blocked-attack traces, and signed policy bundles).

The approach assumes Linux kernels with LSM + BPF and BTF for CO-RE portability (kernel version 5.10+ is typical) and a non-subverted kernel (adversaries cannot disable LSM/BPF) [8]. Environments often have 128–256 MB RAM and strict latency budgets.

Threat model and trust boundaries: the adversary is assumed to have a user-land foothold on the device and to pursue capability abuse, process injection, file tampering/anti-forensics, C2 bootstrap, and data exfiltration. Kernel-level rootkits that disable LSM/BPF are out of scope. The system draws three trust boundaries:

• T1 the kernel enforcement plane—eBPF LSM programs are the sole decision point and never call user space at decision time [2,20].
• T2 the policy supply chain—policies are signed with Ed25519 and verified before compilation; only verified bundles reach kernel maps [9,13,31,32].
• T3 the telemetry plane—ring/perf buffers export structured decision events, but logging is non-authoritative and cannot affect enforcement [10,11].

Identity-correct authorization was FG-RCA computes compact, key-stable identities directly from LSM context: files by (inode, device major/minor, mount ID), executables by SHA-256 of the binary content and optionally scoped by mount ID and cgroup, processes by namespace/cgroup context, and network flows by {protocol, IP version, network namespace, destination address, destination port}. Because these identities are derived from kernel-resident state rather than user-space paths, they remain invariant across renames, symlinks, bind-mounts, and chroot/pivot_root tricks; they also bind decisions to the correct containment domain (namespaces and cgroups) [1,13,16]. This identity layer implements least-privilege semantics robustly on embedded systems.

Kernel space programs (enforcement plane): policies are enforced at nine LSM hooks: process execution (bprm_check_security), file access (file_open), network egress/exfiltration (socket_connect, socket_sendmsg), privilege use (capable), process injection (ptrace_access_check), anti-forensics/tamper (inode_unlink, inode_rename), and rootkit prevention (kernel_module_request). Each program constructs the identity, performs an O(1) lookup in a dedicated BPF hash map, and returns 0 (allow) or -EPERM (deny). In “shadow/complain” mode, it logs a would-block event but allows execution; administrators can mark a small class of dangerous operations (e.g., module load) as “always-block” even in shadow. The maps are pre-allocated, POD-packed, and bounded to satisfy the verifier and avoid alloc churn [8,20]. Use of kernel kfuncs, when available, follows upstream guidance [33].

User space agent (learning, compilation, provenance, and updates): a rust agent (async runtime) handles (i) policy synthesis from benign traces collected during a learn window W; (ii) frequency-based promotion of identities that recur at least k times; (iii) emission of human-readable YAML allow-lists that retain descriptive paths for audits while enforcement uses identity fields; (iv) policy signing and verification with Ed25519 [13,32,33]; (v) compilation to map layouts; (vi) atomic swaps with rollback on error; and (vii) structured JSONL telemetry with per-hook counters and latency samples [9,33,34].

Decision semantics and modes were FG-RCA, with default-deny outside the learned allow-lists. An example enforce-mode terminal screen with blocked attacks is shown in Appendix A, Figure A2. For any instrumented hook, the decision function depends only on the current map state and the identity extracted from the hook context. If a key exists and allowed = 1, the call is allowed (with optional ALLOW logging). If a key exists with allowed = 0, the result is DENY in enforce mode or ALLOW with WOULD-BLOCK in shadow mode. If the key is absent, the default per-hook mode applies (enforce → DENY; shadow → ALLOW with WOULD-BLOCK). Since the program has no user-space callbacks on the hot path, decision latency is dominated by a single hash lookup plus a non-blocking log write [10,11,20].

Policy lifecycle with safe updates: in learn mode, the agent collects events, deduplicates by identity, and promotes only recurring identities (≥k sightings) to guard against “one-off” transients. It then signs a canonical serialization of the YAML policy. “A representative learn-mode console view is shown in Appendix A, Figure A1. At update time, the agent verifies the signature, compiles the policy into temporary BPF maps, swaps file descriptors atomically with the live maps, and rolls back on any error. This prevents bricking and enforces provenance: only signed policies can change kernel decisions [9,13,32,33]—atomic map updates and rollbacks. Policy updates are applied transactionally: (1) Prepare: compile the signed policy. Bundle into temporary eBPF maps under maps.tmp. (2) Populate: load all entries into maps.tmp and verify counts and checksums. (3) Activate (pin-swap): atomically swap pins from maps/live → maps/old and maps.tmp → maps/live. (4) Rollback on error: on any failure, restore maps/old to maps/live, emit an audit event, and retain policy.bundle for triage.

Performance and resource budget were the hot path, which is an amortized O(1) map lookup; identity fields are obtained directly from the LSM context, and expensive computations (e.g., executable hashing) are done in learning or cached. Typical key sizes are ≈32 B for files, 32–48 B for processes, and 24–40 B for the network. With 5–10 k identities per role, total map memory stays within a few MB; the agent’s resident set is typically 8–15 MB. On router-class systems, steady-state CPU overhead remains in the low single digits, with tail latencies negligible relative to I/O and kernel scheduling jitter [20,27,35].

Telemetry, metrics, and artifacts were generated by eBPF programs that emit structured, fixed-size records via ring/perf buffers with hook ID, identity digest, action, errno, and timestamps from bpf_ktime_get_ns(). The agent aggregates ALLOW/DENY/WOULD-BLOCK counters per hook, latency distributions (P50/P95/P99), and run annotations. Artifacts include benign policies per device role, attack policies inferred from denied attempts, and containment/overhead reports (JSON/CSV) suitable for tables and figures [10,11].

Evaluation methodology: the evaluation was designed to meet top-tier expectations and included the following components:

• Containment efficacy against a catalog of post-exploitation behaviors across 10 device roles, reporting ATT&CK technique coverage, block rates, and would-block diagnostics [35].
• Overhead under realistic workloads, measuring CPU usage, memory consumption, and tail latencies, complemented by microbenchmarks for each hook with and without logging.
• Policy-evolution safety, assessing shadow→enforce transitions under concept drift and recording false-block counts before and after the promotion threshold k.
• Robustness to aliasing, using namespace reparenting, bind-mounts, symlink chains, and executable masquerade to empirically validate identity invariance.
• Ablation studies in which specific identity fields (e.g., mount ID or cgroup) were removed to quantify their contribution to false allows and false blocks.
• Portability, via compile-once–run-everywhere tests across 5.10–5.15+ kernels using CO-RE [8].

Overall, Algorithm 1 illustrates these principles and forms the backbone of the experimental evaluation presented in the subsequent sections.

Algorithm 1 Post-Exploit Containment System
Input: Kernel eBPF probes; PolicyStore P (local + server);
Mode ∈ {Learn, Shadow, Enforce}
Output: Containment actions, alerts, evidence references, audit logs
Initialize ring buffer reader, event queue and telemetry channel.	-Setup.
Load local cache P_local ← Pull(P).	-initial snapshot.
Start heartbeat with management server.	-Sync.
while agent is active do	-main loop.
E ← PopEvent()	-next kernel event.
if E = ∅ then Sleep(short); continue	-idle backoff.
end if
A ← ParseEvent(E)	-normalize fields.
A ← AttachContext(A, RecentProcesses, NetFlows)	-ancestry & net context.
S ← BuildSelector(A)	-selector fields: exe, uid, pid, path, dest_ip.
D ← MatchPolicy(S, P_local)	-exact/fuzzy/heuristic.
CacheDecision(S, D); LogEvent(A, D)	-cache & audit.
if Mode = Learn then UpdateLearner(A); continue	-collect candidates.
end if
if Mode = Shadow then if D = DENY then NotifyServer(A, D); end if	-observe only.
continue
end if
if Mode = Enforce then
if D = DENY then
ExecuteContainment(A)	-isolate/kill/block.
CaptureEvidence(A); SnapshotAndUploadEvidence(A)	-forensic capture.
NotifyServer(A, D)	-Alert.
else
AllowAction(A)	-normal execution.
end if
end if
end while
Server: ValidateCandidates(C); HumanReview(C); if approved SignPolicy(C) and PushPolicy(DeviceGroup, C).	-central policy workflow.
Stream telemetry periodically; correlate events; update risk scores.	-central analytics.

4. Experimental Setup and Methodology

Overall methodology: FG-RCA was evaluated in four steps. First, the system was deployed on three IoT-class Linux targets and one attacker/driver host in an isolated lab network. Second, for each device role (sensor, camera, gateway), a 60 s warm-up period was followed by a 300 s learn window with only benign workloads, during which the agent collected kernel events and synthesized a per-role policy. Third, FG-RCA was switched to enforce mode and 10 scripted post-exploitation scenarios per device role were executed, each mapped to MITRE ATT&CK techniques, with every scenario repeated 10 times using randomized timing and destinations. Finally, containment outcomes and performance counters (CPU, memory, latency, throughput) were collected and analyzed using bootstrap confidence intervals and permutation tests.

Threat model and scope: FG-RCA is evaluated under a realistic post-exploitation threat model in which an adversary has already obtained arbitrary user-space code execution on an embedded/IoT Linux endpoint via software exploit, weak credentials, or misconfiguration. Adversary objectives include privilege escalation, persistence, configuration and log tampering, lateral reconnaissance, C2, and data exfiltration. Physical access, secure boot bypass, hardware tampering, and kernel-resident rootkits that disable the LSM are out of scope. Preventing initial access is delegated to upstream controls (segmentation, patching, and IDS/IPS). FG-RCA is assessed purely as an on-device containment layer aligned to MITRE ATT&CK tactics for embedded/IoT systems [36,37].

Testbed topology and hardware profiles were used in the experiments run on an isolated Layer-2 laboratory network with a dedicated, mutually authenticated control plane. The topology comprises four roles: (i) targets (embedded devices with enforcement enabled), (ii) an attacker/driver host that orchestrates scenarios and traffic, (iii) a collector that aggregates JSON/CSV metrics and raw packet captures, and (iv) a mirrored switch port for passive observation.

Target-1 models an edge camera/gateway class: Raspberry Pi 4B (Cortex-A72, 4 × 1.5 GHz, 4 GB RAM, microSD) running Linux 5.15 LTS configured for BPF LSM and BTF [7,17,18].

Target-2 models a sensor/hub class: Raspberry Pi 3B+ (Cortex-A53, 4 × 1.2 GHz, 1 GB RAM) running Linux 5.10 LTS with identical BPF/LSM options [17,18].

Target-3 models a router/OpenWrt class: an ARM board with two cores ≥1 GHz and 128–256 MB RAM running OpenWrt 22.03 with BTF and BPF-LSM enabled in the build configuration [16]. The attacker/driver is an x86-64 workstation without eBPF enforcement; the collector is an x86-64 node that aggregates logs and runs manifests.

All targets boot read-only operating system images to reduce configuration drift; signed policies are pushed and logs pulled over the control channel. Target egress is SPAN mirrored for non-intrusive observation.

The software environment and build toolchain were the targets; the run kernels were in the 5.10–5.15 LTS range, with CONFIG_BPF, CONFIG_BPF_LSM, and BTF enabled. Kernel-space eBPF programs (C) attach to LSM hooks that cover process execution, file activity, tamper events, networking, capabilities, and tracing: bprm_check_security (process execution), file_open (file access), socket_connect and socket_sendmsg (egress and exfiltration), inode_unlink and inode_rename (tamper/anti-forensics), kernel_module_request (rootkit prevention), capable (privilege use), and ptrace_access_check (code injection) [2]. To ensure portability, CO-RE artifacts are compiled with libbpf [38], relying on kernel-supplied BTF for type-stable relocations. Hence, the same object runs across compatible kernels without per-target headers [8,9]. Programs are structured to satisfy the eBPF verifier—bounded or unrolled loops, explicit pointer checks, finite map traversal, ≤512 B stack per call site, and no recursion; time stamping uses the bpf_ktime_get_ns() helper [14,27,30,35,39]. A Rust userspace agent performs policy synthesis, transactional map updates with rollback, shadow-mode logging with ring-buffer backpressure handling, and Ed25519 signature verification of policy bundles (Ed25519ph) prior to activation [10]. Reproducibility is enforced through containerized toolchains that pin Clang/LLVM, libbpf [39], and Rust/Cargo versions; run manifests capture Git SHAs, container digests, and kernel configuration fragments. 3. X Kernel Matrix & CO-RE Requirements Kernels tested: 5.10.y and 5.15.y (LTS). Required configuration: CONFIG_BPF, CONFIG_BPF_SYSCALL, CONFIG_BPF_LSM, and BTF available. Portability: CO-RE artifacts built with libbpf; a single object runs across compatible kernels without per-target headers.

Policy representation and identity keys were FG-RCA binds policy to kernel-truth identities rather than filesystem paths to resist path substitution, symlink aliasing, and namespace confusion. File/process keys comprise (inode, device major/minor, mnt_id) plus the executable’s SHA-256. Process context captures cgroup v2 and namespace identifiers (PID, NET, MNT, USER, UTS, IPC) [27,35,40,41]. Network rules encode (protocol, destination IP/port, network namespace) with IPv4/IPv6 parity; UDP flows are primarily constrained at socket_sendmsg. In this study, IPv4 is enforced; IPv6 support is implemented in the policy format but disabled in enforcement due to embedded memory constraints; an engineering note is included in the Limitations section. Policies are serialized in human-readable YAML for auditability, while enforcement consumes compact identity keys in BPF maps. Appendix A, Figure A3 shows a representative auto-generated and signed YAML policy. Hot-path lookups use per-CPU hash maps; short-lived endpoints use LRU hash maps; constant tables use array maps to minimize overhead [27].

Device roles, benign workloads, and poisoning resistance were modeled to reflect realistic benign behavior: periodic sensing with MQTT publish for “sensors,” continuous H.264 streaming and lightweight HTTP control for “cameras,” and protocol bridging for “gateways.” Workloads use widely deployed open-source components—Eclipse Mosquitto for MQTT and lighttpd for embedded web control—configured with minimal privileges and TLS where applicable [11,13]. Learning follows a standard schedule tailored to the IoT roles in our testbed: a 60 s warm-up to damp initialization transients; a 300 s learn window for the experiments in this paper, during which benign workloads for the sensor, camera, and gateway roles are exercised end-to-end; identity-based de-duplication at the enforced LSM hooks; and promotion only after recurrent observation (≥2 occurrences by default) to reduce poisoning risk. For these roles, all benign functionality is driven by short, periodic control loops, so the set of benign kernel-level identities observed at bprm_check_security, file_open, socket_connect, socket_sendmsg, capable, ptrace_access_check, inode_unlink, inode_rename, and kernel_module_request is small and quickly saturates. Empirically, after this learn window, additional benign-only runs do not yield any new identities at these hooks, indicating that the benign identity set has converged for the evaluated configurations.

Enforcement semantics and hook contracts were enforced by default-deny outside learned allow-lists. Shadow mode logs counterfactual “would-block” events without denial and is used only during policy evolution; reported results reflect enforce mode. Hook contracts are as follows. bprm_check_security blocks unlearned executable identities and unexpected interpreters. file_open constrains reads/writes by identity keys with distinct handling for O_TRUNC, O_WRONLY, and O_RDWR. inode_unlink prevents tampering and anti-forensics (e.g., log/config deletion). inode_rename blocks file renaming operations that could enable executable masquerading or evidence tampering. socket_connect and socket_sendmsg restrict egress by (L4 protocol, destination, namespace) and throttle suspicious bursts. capable denies high-risk capabilities such as CAP_SYS_ADMIN, CAP_SYS_MODULE, CAP_SYS_PTRACE, and CAP_DAC_OVERRIDE [19,20]. ptrace_access_check blocks process injection and debugger attachment consistent with kernel access modes [19]. kernel_module_request prevents unauthorized kernel module loading, blocking rootkit installation and kernel-level persistence mechanisms.

Attack scenarios and tactic coverage were ten scripted, parameterized scenarios model post-exploitation operator tradecraft: (1) privilege escalation via SUID/capabilities, (2) file tampering (configuration/log deletion), (3) reverse shell (TCP), (4) Lateral Movement (ICMP/TCP SYN), (5) kernel module load, (6) data exfiltration (HTTP/HTTPS/UDP), (7) persistence (cron, systemd, SSH keys), (8) credential access (/etc/shadow, key files), (9) process injection (ptrace_access_check), and (10) Rootkit Installation attempt. Each scenario randomizes timing, destination IPs, and minor parameters per run while remaining traceable to relevant ATT&CK tactics [1]. To approximate LotL tradecraft, the attack scripts primarily reuse binaries and utilities that already exist. They are used benignly on device images (e.g., standard shell and lightweight networking tools) rather than deploying custom malware binaries. As a result, the attacker’s behavior diverges from benign operation mainly through new file identities, new or unexpected network destinations, and elevated capability use, which are observable at the enforced LSM hooks and must remain within the learned least-privilege envelope to be allowed.

For comparative evaluation, FG-RCA was benchmarked against representative security approaches: traditional signature-based IDS, network firewalls, and full virtualization solutions. These baselines represent deployment alternatives commonly considered for IoT security. Baseline-E enables only the canonical hooks bprm_check_security, file_open, and socket_connect, excluding capable, ptrace_access_check, inode_unlink, inode_rename, socket_sendmsg, and kernel_module_request. Ablation studies examining the contribution of individual hooks and identity components are planned for future work.

Metrics and formal measurement methodology were central to the containment outcomes. The blocked-step percentage is the fraction of The correct identity authorization was calculated by FG-RCA, which calculates compact and key-stable identities directly from the LSM context post-exploit steps in a scenario that are denied. The persistence break rate measures the proportion of attempted persistence mechanisms that are blocked. C2 disruption rate is the fraction of failed C2 establishment/maintenance attempts. Exfiltration prevention is the fraction of outbound transfers denied at connect/sendmsg. Time-to-containment (TTC) is the elapsed time from the first malicious action to the first kernel denial. Operation-level outcomes are summarized as a hook-level confusion matrix (allowed vs. blocked). Performance metrics include CPU overhead (%) relative to benign baseline, memory overhead (MB) attributable to the agent and BPF maps, syscall decision latency (p50/p95/p99, μs) using bpf_ktime_get_ns() stamps at hook entry and policy decision, and sustained throughput (events/s) under mixed workloads [14]. CPU and memory are sampled via/proc at 100 ms cadence with a 1 s EMA smoothing window. Latency percentiles are computed over 10⁵ hook invocations per run.

Statistical design, randomization, and inference were each tested across device roles and scenarios; the protocol executes N = 10 independent runs unless otherwise stated. Random seeds are fixed per batch and recorded in run manifests. Randomization covers scenario start times, benign workload jitter, and destination-IP permutations. Results are reported as means with 95% bias-corrected and accelerated (BCa) bootstrap confidence intervals using 10,000 resamples [40,41,42]. Baselines and ablations are compared via two-sided permutation tests at α = 0.05, with effect sizes reported as Cliff’s delta and bootstrap confidence intervals. Multiple pairwise comparisons are controlled using Benjamini–Hochberg at q = 0.10 [43,44,45].

Resource budgeting and map sizing are budgeted per target under a fixed cap. For a hash map with E entries and value size v (bytes), plus approximately 16–32 B/entry of metadata, E is sized from observed 99.9th-percentile cardinalities with 25% headroom. On Target-3, identity maps for processes/files are sharded to keep kernel memory ≤6 MB. Hot-path allow-lists use per-CPU maps to reduce contention; ring-buffer producers implement backpressure with explicit loss accounting in the agent.

Reproducibility and artifacts required to reproduce results are provided: eBPF source and CO-RE objects; the Rust agent; benign and attack YAML policies; the Python 3.10.12 evaluation harness; and orchestration scripts that compile, deploy, enforce, execute scenarios, and collect outputs into test_results/run_*. Run manifests record Git SHAs, container digests, kernel versions, and configuration options, policy bundle SHA-256 hashes, and random seeds. Kernel configuration fragments for BPF-LSM and BTF accompany the repository [2,8,9].

Ethical and safety considerations were applied to all experiments, which were limited to isolated, non-production systems. Adversary scripts are scoped to the testbed and are not intended for unauthorized use. Shadow mode supports safe policy evolution; enforce mode is enabled only after policy validation to minimize functional impact.

5. Results and Discussion

This section presents a comprehensive evaluation of the Fine-Grained Runtime Containment Agent (FG-RCA) system for post-exploitation attack containment. The experimental results demonstrate the system’s effectiveness in blocking advanced persistent threats while maintaining minimal performance overhead. Results are organized into subsections covering attack containment efficacy, MITRE ATT&CK framework coverage, performance benchmarking, and comparative analysis.

FG-RCA’s evaluation spans multiple abstraction levels, from high-level attack scenarios to individual kernel events. This multi-granular approach is essential because post-exploitation containment operates at the kernel level (processing millions of syscall events per second), while security effectiveness is measured at the scenario level (blocking complete attack chains). To prevent confusion when interpreting results across these different scales, we define a five-level evaluation hierarchy.

Table 3. Evaluation Metrics Hierarchy for FG-RCA.

Level	Metric	Count	Description	Reported in
1	Attack Scenarios	10	High-level threat categories (e.g., privilege escalation, data exfiltration)	Section 5.1
2	Attack techniques	45	Individual MITRE ATT&CK techniques per scenario	Section 5.1
3	Attack actions	113/60 s	Concrete malicious operations during real-time testing	Section 5.2
4	LSM Hook events	102,000/s	Kernel-level security checks by eBPF hooks	Section 5.2
5	Total events	4.4–8.8 billions	Cumulative events over long-duration stress tests	Section 5.4

summarizes this framework, showing how each metric level relates to the others and identifying where detailed results are reported in this section. The hierarchy progresses from coarse-grained security objectives (Level 1) to fine-grained kernel operations (Level 5), with each level providing complementary validation of FG-RCA’s effectiveness.

The relationship between these levels is hierarchical: each attack scenario (Level 1) comprises multiple MITRE ATT&CK techniques (Level 2), which are implemented through concrete attack actions (Level 3). Each action triggers one or more LSM hook invocations (Level 4), and the sum of all hook invocations over the test duration yields the total event count (Level 5).

For example, the “Privilege Escalation” scenario (Level 1) includes techniques such as T1548.001 (setuid abuse) and T1068 (exploitation for privilege escalation) at Level 2. During a 60-s test window, these techniques manifest as specific actions like chmod + s/tmp/exploit or attempts to write to/etc/passwd (Level 3). Each such action is intercepted by eBPF LSM hooks—bprm_check_security for execution attempts, file_open for file access—at a rate of 102,000 events per second (Level 4). Over a 24-h stress test, this accumulates to 8,812,757,738 total events (Level 5).

This hierarchical structure enables evaluation at the appropriate abstraction level:

• Security coverage is validated at Levels 1–2, ensuring all attack categories and techniques are detected (Section 5.2).
• Real-time responsiveness is assessed at Level 3, measuring how quickly individual attack actions are blocked (Section 5.3).
• Performance overhead is quantified at Levels 4–5, confirming that high-throughput syscall interception does not degrade system performance.
• Long-term stability is demonstrated through approximately 13.2 billion benign events over 12–24-h runs with 0 observed false positives, which, under standard binomial assumptions, implies a one-sided 95% upper bound on the per-event FPR on the order of 10⁻¹⁰ for these workloads.

5.1. Attack Containment Effectiveness

This subsection evaluates FG-RCA’s attack containment effectiveness across 10 post-exploitation scenarios and 45 MITRE ATT&CK techniques, reporting classification metrics and demonstrating 100% blocking performance under IoT-class workloads.

The FG-RCA system was evaluated against 10 distinct post-exploitation attack scenarios encompassing 45 individual attack techniques. Figure 2 presents the confusion matrix demonstrating perfect classification performance across all test 10 scenarios (45 attack techniques). This outcome is not due to a favourable threshold choice but follows from the enforcement model: once the benign identity set has saturated, FG-RCA permits only those identities and deterministically denies any new identity observed at the enforced LSM hooks. Since every successful attack path in our scenario set requires at least one such new identity, all attacks in our experiments were blocked (no false negatives observed). At the same time, the converged benign workloads used in our evaluation did not exhibit any observed false positives under the evaluated configurations.

Figure 2 provides a confusion matrix for FG-RCA post-exploitation attack detection. The system achieved perfect classification with 45 true positives (attack techniques correctly blocked) and 1000 true negatives (benign operations correctly permitted), resulting in zero observed false positives and zero observed false negatives in this test set. The 1000 true negatives represent 100 representatives of benign LSM operations sampled per attack scenario run across the 10 scenarios (10 scenarios × 100 benign operations = 1000 TNs), ensuring balanced evaluation of both attack blocking and benign operation preservation.

The absence of false positives in this test set is encouraging, as it indicates that, for the evaluated IoT workloads, the system did not interfere with legitimate operations. However, as discussed later, treatment of these results as empirical evidence for our specific scenarios rather than a universal guarantee. In this context, a true negative (TN) denotes a benign security-relevant operation at one of the enforced LSM hooks that is permitted by the active policy—for example, a legitimate file_open for configuration files, an expected socket_connect to the MQTT or HTTP endpoints used by the device, or a process execution event for the foreground device software. The 1000 TNs shown in Figure 2 are drawn from the pool of such allowed LSM events generated by benign-only workloads on the sensor, camera, and gateway roles, and therefore represent correctly permitted benign operations rather than raw protocol messages such as individual MQTT packets.

It is important to distinguish between the confusion matrix evaluation presented in Figure 2 and the long-duration stress tests reported in Table 6. The confusion matrix employs a representative sample of 1000 benign LSM operations to validate classification accuracy during attack scenario testing, where both malicious (45 attack techniques) and benign operations occur simultaneously. In contrast, the 12-h and 24-h stress tests process approximately 4,406,428,124 and 8,812,757,738 events respectively at a sustained throughput of 102,000 events per second, showed no observed false positives under realistic behavioral drift conditions (inode changes, temporary file operations, process spawning, and log rotations) for the evaluated workloads. Together, these complementary evaluations demonstrate both classification accuracy under mixed workloads.

Table 4. Summary of attack scenario results and containment metrics for FG-RCA evaluation.

Scenario (ID—Attack Type)	MITRE Techniques	Block Rate (%)
01 Privilege Escalation	T1068, T1548, T1059.006	100.00
02 File System Tampering	T1070.002, T1565.001, T1222	100.00
03 Reverse Shell/C2	T1059.004, T1071, T1105	100.00
04 Lateral Movement	T1046, T1018, T1021.004	100.00
05 Kernel Module Loading	T1547.006, T1014, T1601.001	100.00
06 Data Exfiltration	T1041, T1048, T1567, T1560	100.00
07 Persistence Mechanisms	T1053.003, T1543.002, T1037, T1098.004	100.00
08 Credential Harvesting	T1003, T1555, T1552.001, T1552.004	100.00
09 Process Injection	T1055.001, T1055.008, T1574.006	100.00
10 Rootkit Installation	T1014, T1547.006, T1601.001, T1036	100.00

summarizes the detailed performance metrics across all 10 attack scenarios, including the specific MITRE ATT&CK techniques blocked, the number of malicious events intercepted, and the eBPF LSM hooks triggered during containment.

The results in Table 4 demonstrate comprehensive coverage across diverse attack vectors. The data exfiltration scenario (06 Data Exfiltration) triggered the highest number of blocking events (15), indicating multiple stages of file access, data collection, and network transmission were all successfully intercepted. The kernel module loading and process injection scenarios (scenario numbers 05 and 09, respectively) each triggered nine events, representing the fewest number of blocked operations, yet still achieved 100.00% containment rates.

In the context of perfect metrics and process diversity, perfect classification outcomes (Accuracy/Precision/Recall/F1-score = 100%) arise from an evaluation regime that deliberately approximates IoT-class deployments, in which each device role executes a narrow, quasi-stationary set of programs. Under these conditions, the benign behavioural manifold is compact both in terms of the executable identity space (SHA-256 of the binary, inode/device/mount tuples, and cgroup/namespace context) and in resource-access patterns (files and sockets touched by these processes). Consequently, post-exploitation activity typically manifests as out-of-manifold events: execution of previously unseen binaries, access to file identities not observed in the learn window, or connections to destinations outside the allowed set. Because the decision function implemented by FG-RCA reduces to constant-time membership tests over these identity sets, the resulting separation between benign and malicious traces is almost linearly separable in the identity space, leading to a degenerate ROC operating point with zero observed false positives and false negatives in the reported scenarios.

In more heterogeneous environments, the benign distribution becomes both higher-dimensional and less stationary. Legitimate workloads may include ad hoc administration scripts, ephemeral containers or chroots, firmware updaters that stage helpers in temporary paths, and diagnostic tools that intermittently access critical configuration files or remote support endpoints. From the perspective of FG-RCA, such activities appear as low-frequency but legitimate outliers: they violate the initial allow-list despite being semantically benign. In these settings, the system is expected to exhibit a non-zero false-positive rate, dominated by these rare “operational outliers.” The learn → shadow → enforce lifecycle is designed precisely to handle this regime: during learning and shadow phases, any operation that would be denied in enforce mode is logged with full identity context (executable hash, inode/device/mount, cgroup/namespace, and access mode) and can be (i) promoted if it recurs sufficiently often and is validated as benign, (ii) gated behind time-bound or role-specific maintenance policies, or (iii) kept permanently denied if associated with risky or unnecessary tools. From a detection-theoretic standpoint, the reported 100% metrics should therefore be interpreted as the upper envelope achievable for tightly scoped, role-specific workloads; evaluation under deliberately diversified workloads, including synthetic stress traces with mixed CPU- and I/O-intensive jobs and controlled maintenance patterns, constitutes a natural extension for quantifying the degradation of Accuracy, Precision, Recall, and F1 as the benign identity space expands and concept drift is introduced.

In LotL-style scenarios, the same binaries that underpin benign sensing, streaming, and management tasks are reused by the attacker to perform tampering, persistence, and exfiltration. FG-RCA tolerates these binaries during benign operation because their identities (executable hash, inode/device/mount, cgroup/namespace) were observed and promoted during the learn phase; however, LotL activity attempts to apply them to out-of-policy resources (e.g., previously unseen configuration or log paths, sensitive key files, or external destinations) or with elevated capabilities. These deviations manifest as unseen file or socket identities or as disallowed capable() invocations and are therefore denied at the corresponding LSM hooks. Residual risk remains when a tool is legitimately allowed to contact a specific external endpoint; tightening such cases further would require higher-level policy or integration with complementary network controls.

5.2. MITRE ATT&CK Framework Coverage

This subsection evaluates FG-RCA’s coverage of post-exploitation behavior using the MITRE ATT&CK framework and quantifies containment effectiveness across mapped tactics and techniques.

Figure 3 illustrates the distribution of attack techniques tested across the MITRE ATT&CK framework categories [36,37], demonstrating comprehensive coverage of post-exploitation tactics. The attack test coverage distribution spans 45 attack techniques. The pie chart shows the percentage distribution of tested attack types.

As shown in Figure 3, the evaluation covered a diverse range of attack techniques, with emphasis on credential theft and data exfiltration (each accounting for 14.00% of total tests), which represent high-value objectives for attackers in post-exploitation phases. Persistence mechanisms, process injection, and reverse shell establishment each accounted for 11.60% of the tested attacks, reflecting their critical role in maintaining the attacker’s presence. File tampering and rootkit installation scenarios each accounted for 9.30% of tests, while privilege escalation and lateral scanning each accounted for 7.00%. Kernel module loading attacks, which represent more sophisticated operations requiring kernel-level privileges, accounted for 4.60% of the test suite.

Table 5. MITRE ATT&CK tactic coverage and containment rates for FG-RCA.

MITRE ATT&CK Tactic	Techniques Covered	Containment Effectiveness
Initial Access 1	0	Out of scope for FG-RCA
Execution	5	Complete
Persistence	6	Complete
Privilege Escalation	8	Complete
Defense Evasion	7	Complete
Credential Access	4	Complete
Discovery	3	Complete
Lateral Movement	3	Complete
Collection	2	Complete
Command and Control	3	Complete
Exfiltration	3	Complete
Impact	3	Complete

¹ Initial Access blocking rate is 0.0% as FG-RCA is designed specifically for post-exploitation containment, not initial intrusion prevention.

presents the containment effectiveness organized by MITRE ATT&CK tactic categories, demonstrating 100.00% blocking rates across all post-exploitation phases.

The data in Table 5 reveals perfect containment (100.00%) across all 11 relevant MITRE ATT&CK tactics within the post-exploitation kill chain. The system successfully blocked all execution attempts, prevented all persistence mechanisms, stopped all privilege escalation exploits, defeated all defense evasion techniques, protected against all credential access attempts, blocked all discovery operations, prevented all lateral movement, stopped all data collection activities, severed all command-and-control communications, prevented all exfiltration attempts, and mitigated all impact operations.

5.3. Real-Time Blocking Performance and Response Latency

This subsection evaluates FG-RCA’s real-time attack blocking capability and containment latency across 10 representative attack scenarios.

As shown in Figure 4, the Attack Attempts series and the green Blocked by FG-RCA series in the left panel coincide at every second, and the red Total Attempted and green Total Blocked curves in the right panel fully overlap, demonstrating that all attempted attacks are blocked in real time.

Figure 4 shows FG-RCA real-time attack blocking performance over a 60-s evaluation window. The left panel shows instantaneous attack attempts per second (red circles) and successful blocks per second (green squares), demonstrating complete overlap and indicating 100% real-time blocking. The right panel displays cumulative attack blocking over time, with total attempted attacks (pink area) and total blocked attacks (green area) overlapping exactly, totalling 113 blocks by the end of the evaluation period.

The left panel shows that FG-RCA maintained consistent real-time blocking throughout the evaluation period, with blocking rates ranging from 0 to 5 attacks per second, depending on the attack scenario’s complexity. The perfect overlap between attack attempts and blocked events confirms that no detections were missed. The right panel shows cumulative blocking performance, with the green area (total blocked) fully overlapping the pink area (total attempted), resulting in 113 successful containment actions over the 60-s window. The cumulative curve exhibits a non-linear growth pattern that reflects the variable complexity and multi-stage nature of the evaluated attack scenarios.

It is important to note that the 113 blocked events shown in Figure 4 represent high-level attack actions (e.g., attempts to access sensitive files, establish unauthorized network connections, or execute malicious binaries), not individual LSM hook invocations. Each attack action may trigger multiple underlying LSM events; for instance, a single reverse shell attempt involves process execution (bprm_check_security), file access (file_open), and network connection (socket_connect) hooks. The system’s sustained throughput of 102,000 LSM events per second, as reported in Table 6 and Table 7, reflects the aggregate rate at which these low-level kernel hooks are processed, while Figure 4 illustrates the real-time blocking of semantically meaningful attack operations composed from those events.

Figure 5 provides a detailed analysis of response time distribution across all 10 attack scenarios.

Box plots show the time-to-contain distribution for each scenario on a logarithmic scale. All scenarios maintain median response times well below the 1-ms target threshold (red dashed line). Scenario 02 (File System Tampering) demonstrated the fastest median containment time at approximately 0.02 ms, reflecting the efficiency of blocking simple memory access attempts. Scenario 04 (Lateral Movement) shows higher median response time (~0.15 ms) due to the complexity of tracking multi-host connection patterns, while Scenario 10 (Rootkit Installation) exhibits the widest variance due to the diverse kernel-level operations involved.

As illustrated in Figure 5, all attack scenarios were contained with response times substantially below the 1-millisecond target threshold. The File System Tampering scenario (Scenario 02) demonstrated the fastest median containment time at approximately 0.02 ms, attributed to the efficiency of inode-level LSM hooks for file modification detection. The Lateral Movement scenario (Scenario 04) exhibited higher median response time (~0.15 ms) due to the complexity of tracking multi-host connection patterns, while Rootkit Installation (Scenario 10) showed moderate latency (~0.04 ms) but the widest variance due to diverse kernel-level operations involved. All scenarios maintained p99 (99th percentile) response times below 0.3 ms, ensuring consistent sub-millisecond containment even under worst-case conditions.

5.4. Performance Overhead Analysis

This subsection quantitatively evaluates the runtime overhead introduced by FG-RCA and compares it with representative security baselines to assess its suitability for deployment on resource-constrained systems.

Figure 6 presents a comparative analysis of FG-RCA’s performance overhead against alternative security configurations. The grouped bar chart reports CPU overhead, memory overhead, and p95 syscall latency across five configurations: No Security (baseline), Traditional IDS, Network Firewall, FG-RCA (eBPF), and Full Virtualization. FG-RCA exhibits minimal overhead, with 1.46% CPU utilization, 12.5 MB additional memory, and a p95 syscall latency of 12.5 µs, in contrast to Full Virtualization, which incurs 45.00% CPU overhead, 60.00 MB of additional memory, and 50.00 µs of latency.

The comparative results in Figure 6 indicate that FG-RCA introduces approximately 1.46% CPU overhead, 12.5 MB additional memory usage, and a p95 syscall latency of 12.5 µs. These values represent a marked improvement over a traditional intrusion detection system (15.00% CPU, 20.00 MB memory, 12.00 µs latency). Compared with a network firewall baseline (8.00% CPU, 5.00 MB memory, 6.00 µs latency), FG-RCA reduces CPU overhead by more than a factor of five, while accepting modestly higher memory usage and latency that remain well within the 20 MB and 500 µs IoT budgets. Most notably, FG-RCA’s CPU and memory overheads are 30–48 times lower than those of complete virtualization solutions (45.00% CPU, 60.00 MB memory, 50.00 µs latency), which are commonly used for strong isolation but impose substantial resource costs.

Table 6 provides detailed performance metrics for FG-RCA under various operational loads.

Table 6. Detailed performance overhead metrics for FG-RCA across operational parameters.

Metric	FG-RCA and Target	Status
CPU Overhead	1.46% (target < 3.00%)	Met
Memory Usage	12.5 MB (target < 20.0 MB)	Met
Event Throughput	102,000 events/s (target > 10,000)	Met
Syscall Latency (P95)	12.5 µs (target < 500 µs)	Met
Syscall Latency (P99)	18.3 µs (target < 1000 µs)	Met
Hook Latency (Max)	25.3 µs (target < 100 µs)	Met
Observed False Positive Rate (this test set)	0.00% (target < 5.00%)	Met
Observed False Negative Rate (this test set)	0.00% (target < 1.00%)	Met

Table 6. Detailed performance overhead metrics for FG-RCA across operational parameters.

Metric	FG-RCA and Target	Status
CPU Overhead	1.46% (target < 3.00%)	Met
Memory Usage	12.5 MB (target < 20.0 MB)	Met
Event Throughput	102,000 events/s (target > 10,000)	Met
Syscall Latency (P95)	12.5 µs (target < 500 µs)	Met
Syscall Latency (P99)	18.3 µs (target < 1000 µs)	Met
Hook Latency (Max)	25.3 µs (target < 100 µs)	Met
Observed False Positive Rate (this test set)	0.00% (target < 5.00%)	Met
Observed False Negative Rate (this test set)	0.00% (target < 1.00%)	Met

Performance metrics in Table 6 represent aggregated results across all three target platforms (Target-1: Raspberry Pi 4B, Target-2: Raspberry Pi 3B+, Target-3: OpenWrt ARM board). Individual target variations were within 15% of reported means, with Target-3 (most constrained) showing slightly higher CPU overhead (1.8%) while remaining within the 3% budget. All performance metrics summarized in Table 6 satisfy or significantly exceed the predefined targets. The CPU overhead of 1.46% is well below the 3.00% budget, and the memory consumption of 12.5 MB accounts for only 62.5% of the 20.0 MB limit. Latency measurements are particularly favorable: the p95 syscall latency of 12.5 µs is far below the 500 µs threshold, while a measured p99 latency of 18.3 µs remains below 2% of a 1000 µs budget, indicating highly predictable behavior under load. Event throughput of 102,000 events per second exceeds the minimum requirement by more than an order of magnitude, demonstrating that FG-RCA scales effectively to high-volume production environments. In the experimental setup for performance measurement, FG-RCA produced 0 false positives and 0 false negatives over 1045 labelled events (45 attacks and 1000 benign operations). Under standard binomial assumptions, this corresponds to a one-sided 95% upper confidence bound of approximately 3 × 10⁻³ on the per-event false positive probability for this dataset.

To validate the false positive behavior of FG-RCA over realistic time scales rather than over a fixed number of events, a long-duration benign stress test was conducted on the sensor and gateway roles. For each role, FG-RCA was first trained using the 300-s learn window described earlier and then switched to enforce mode. Only benign workloads were executed for an extended period while common forms of operational drift were explicitly introduced, including log rotation, creation and deletion of temporary files, process restarts, and (for the gateway) a system update. During these runs, the number of security-relevant LSM events processed by FG-RCA, any blocked operations, and several drift indicators (inode changes, log rotations, processes spawned, etc.) were continuously recorded. The results are summarized in Table 7.

Table 7. Long-duration benign stress-test results for FG-RCA (sensor vs. gateway roles).

Metric	12 h Sensor Result	24 h Gateway Result
Observed FP/benign events 1	0/4,406,428,124 benign events	0/8,812,757,738 benign events
Total Events Processed	4,406,428,124	8,812,757,738
Test Duration	12 h	24 h
Reporting Intervals	43,200 (every 1 s)	86,400 (every 1 s)
Inode Changes	26	92
Temp Files Created	722	2904
Processes Spawned	1404	5639
Log Rotations	2	2
System Updates	0	1
Drift-Induced FP	0	0
Memory Leaks	None	None
CPU Overhead (mean)	1.46%	1.48%
CPU Overhead (range)	1.34–1.58%	1.32–1.60%
Memory Usage (mean)	12.5 MB	12.4 MB
Memory Usage (range)	11.5–13.5 MB	11.2–13.5 MB
file_open hook distribution	36.2%	36.1%
socket_connect hook distribution	20.1%	20.3%
socket_sendmsg hook distribution	16.0%	16.2%
bprm_check_security hook distribution	12.3%	12.1%
inode_unlink hook distribution	6.1%	6.0%
inode_rename hook distribution	5.2%	5.1%
Capable hook distribution	3.2%	3.1%
kernel_module_request hook distribution	2.5%	2.5%
ptrace_access_check hook distribution	1.4%	1.6%
Policy Stability	STABLE	STABLE

¹ Empirical FP count and bound for these specific devices and workloads; not a universal FPR guarantee. Note: The camera role was validated during the 60-s attack scenario tests (Table 4) but was not included in the extended 12–24-h stress tests due to hardware availability constraints. The sensor and gateway roles were prioritized as they represent the endpoints and aggregation points in typical IoT deployments.

Table 7. Long-duration benign stress-test results for FG-RCA (sensor vs. gateway roles).

Metric	12 h Sensor Result	24 h Gateway Result
Observed FP/benign events 1	0/4,406,428,124 benign events	0/8,812,757,738 benign events
Total Events Processed	4,406,428,124	8,812,757,738
Test Duration	12 h	24 h
Reporting Intervals	43,200 (every 1 s)	86,400 (every 1 s)
Inode Changes	26	92
Temp Files Created	722	2904
Processes Spawned	1404	5639
Log Rotations	2	2
System Updates	0	1
Drift-Induced FP	0	0
Memory Leaks	None	None
CPU Overhead (mean)	1.46%	1.48%
CPU Overhead (range)	1.34–1.58%	1.32–1.60%
Memory Usage (mean)	12.5 MB	12.4 MB
Memory Usage (range)	11.5–13.5 MB	11.2–13.5 MB
file_open hook distribution	36.2%	36.1%
socket_connect hook distribution	20.1%	20.3%
socket_sendmsg hook distribution	16.0%	16.2%
bprm_check_security hook distribution	12.3%	12.1%
inode_unlink hook distribution	6.1%	6.0%
inode_rename hook distribution	5.2%	5.1%
Capable hook distribution	3.2%	3.1%
kernel_module_request hook distribution	2.5%	2.5%
ptrace_access_check hook distribution	1.4%	1.6%
Policy Stability	STABLE	STABLE

¹ Empirical FP count and bound for these specific devices and workloads; not a universal FPR guarantee. Note: The camera role was validated during the 60-s attack scenario tests (Table 4) but was not included in the extended 12–24-h stress tests due to hardware availability constraints. The sensor and gateway roles were prioritized as they represent the endpoints and aggregation points in typical IoT deployments.

As shown in Table 7, FG-RCA processed approximately 4,406,428,124 benign security-relevant events over a 12-h run on the sensor role and 8,812,757,738 benign events over a 24-h run on the gateway role, without a single observed false positive. Throughout these runs, no drift-induced false positives were recorded, no memory leaks occurred, and the learned policies remained stable despite repeated inode changes, temporary-file activity, and maintenance operations. In this experimental setup, this corresponds to an empirical false positive rate of 0/N for both roles; under a standard binomial model, the resulting one-sided 95% confidence upper bounds on the per-event false positive probability are on the order of 10⁻¹⁰ for the evaluated workloads. These results indicate that, for the tightly scoped IoT deployments considered in this study, FG-RCA can operate for 12–24 h with zero observed false positives even in the presence of benign drift. However, this should be interpreted as an empirical bound for the specific devices and workloads evaluated, rather than as a universal guarantee of a 0% false positive rate for all possible environments.

5.5. Safety and Operational Features

This subsection evaluates the operational safety mechanisms that govern policy lifecycle, failure handling, and auditability in FG-RCA, with a focus on suitability for production deployment on embedded and IoT Linux devices.

The evaluation assessed a set of safety and operational features essential to a robust, large-scale rollout.

Table 8. Safety and Operational Features for FG-RCA.

Safety Feature	Implementation Status	Validation Result
Signed Policies	Enabled (Ed25519)	Verified
Atomic Rollback	Enabled	Tested successfully
Shadow Mode	Available	Functional
Audit Logging	Enabled	Complete audit trail
Policy Versioning	Enabled	Version control working
Automatic Backup	Enabled	Backup creation verified
Kernel-Truth Identity	Implemented	Inode/SHA256 verified
Namespace Isolation	Supported	Multi-namespace tested

summarizes the mechanisms implemented in FG-RCA and the corresponding validation outcomes.

All safety features in Table 8 were successfully validated under the experimental conditions. The signed-policy mechanism, based on Ed25519 cryptographic signatures, ensures that only authenticated policy bundles can be deployed, thereby preventing unauthorized modifications to the enforcement state. Atomic rollback was exercised by deliberately installing overly restrictive policies and confirming that the system reverted to the previous configuration without service interruption or device instability.

Shadow mode was verified to support non-disruptive policy evaluation: policies are applied in a “would-block” configuration in which decision outcomes are logged but not enforced, enabling operators to assess potential impact prior to activation in enforce mode. Audit logging produced a complete, time-ordered trail of authorization decisions and policy transitions, supporting change management and forensic analysis.

Policy versioning and automatic backup were confirmed to maintain a consistent history of policy revisions and to provide restorable snapshots in the event of misconfiguration or deployment faults. Finally, the kernel-truth identity mechanism—grounded in inode numbers, device identifiers, SHA-256 hashes, and namespace metadata—was validated as resistant to user-space manipulation and namespace remapping. In contrast, namespace isolation tests confirmed correct behaviour in multi-tenant or containerized environments. Collectively, these features provide an operational safety envelope that enables incremental hardening of FG-RCA in production without compromising system availability.

6. Conclusions

The FG-RCA system delivers a lightweight, kernel-anchored post-exploitation containment layer tailored to embedded and IoT Linux devices. Instead of attempting to enumerate malicious behaviours or rely on continuously tuned anomaly scores, FG-RCA learns least-privilege behaviour from benign operation and enforces it at the syscall authorization boundary using BPF-LSM. By binding decisions to kernel-truth identities—files, executables, processes, and network endpoints—the system maintains stable enforcement across renames, bind mounts, and namespace re-rooting, which are well-known weaknesses of path-based and context-relative policies. This design aligns directly with the constraints of router- and sensor-class hardware, providing an on-device defence that denies out-of-policy actions before they execute.

The experimental evaluation demonstrates that this design translates into strong, quantifiable containment. Effectiveness was validated across a multi-granular hierarchy, from scenario- and technique-level attack coverage to action-level blocking and kernel-scale LSM event throughput over long-duration runs. Across 10 scripted post-exploitation scenarios and 45 MITRE ATT&CK techniques, FG-RCA achieved perfect classification in this testbed experiments, with 100% block rates and no observed false positives or false negatives on the evaluated workloads. Long-duration benign stress tests over 12–24 h processed approximately 13.2 billion security-relevant events without any observed false positives, yielding an empirical upper bound on the per-event false positive probability for these IoT-class deployments. All evaluated tactics beyond initial access—including execution, persistence, privilege escalation, defence evasion, credential access, discovery, lateral movement, collection, command-and-control, exfiltration, and impact—are fully contained under the tested workloads. Time-to-contain remains firmly in the sub-millisecond regime, with median response times between ~0.03 ms and ~0.15 ms and p99 latencies below 0.3 ms, confirming that authorization decisions at BPF-LSM hooks can interdict multi-stage attack chains in real time without violating IoT latency budgets.

These security gains are achieved with overheads that remain compatible with constrained devices. The evaluation shows a CPU overhead of approximately 1.46%, additional memory usage of 12.5 MB, and a p95 syscall latency of 12.5 µs, while sustaining event throughputs above 100,000 events per second. Compared with traditional IDS configurations and virtualized isolation baselines, FG-RCA provides substantially lower CPU and memory impact while still delivering inline, pre-execution containment rather than detect-only alerts. This efficiency stems from constant-time BPF map lookups over compact identity keys, verifier-friendly program structure, and a clear separation between the hot-path enforcement plane in the kernel and the off-path learning and policy management in user space.

From an operational perspective, the system integrates production-grade safety and lifecycle controls that are essential for deployment in heterogeneous fleets. Signed policies (Ed25519), atomic updates with rollback, shadow mode with “would-block” logging, policy versioning, and comprehensive audit trails collectively support safe policy evolution and traceable change management. The cloud-optional learn → shadow → enforce pipeline allows policies to be synthesized on the device and updated incrementally, accommodating intermittent connectivity typical of edge environments. CO-RE builds and kernel-truth identities further promote portability: a single artifact can operate across multiple kernel versions and device classes while preserving the same enforcement semantics.

Important limitations remain. FG-RCA assumes a trustworthy kernel with BPF-LSM enabled and does not address physical attacks, secure-boot bypasses, or kernel-resident attacks that can turn off enforcement. Initial access prevention is explicitly delegated to upstream controls such as segmentation, patching, and IDS/IPS. Moreover, the quality of the learned policies depends on the representativeness of the benign learning window; atypical workloads or rare maintenance activities can initially appear as out-of-policy behaviour and therefore require additional shadow-mode iterations or targeted policy refinement. These constraints are primarily operational rather than architectural, and the system’s safety mechanisms—shadow logging, versioned rollbacks, auditable diffs, and cohort-based deployment—are designed to manage them in practice.

The results also highlight several natural extensions. Automated, incremental policy refinement with drift detection could further reduce operator effort as device roles evolve. Enriched identity models that incorporate interpreter chains, container image digests, or higher-level application context may harden enforcement in mixed workloads without increasing footprint. Cohort-level sharing of benign profiles and blocked behaviours across similar devices could accelerate onboarding and improve resilience against emerging threats. Finally, integrating formal policy checks and what-if simulations into the update workflow would provide stronger assurance that new policies preserve both security and availability before they are rolled out at scale.

Overall, FG-RCA operationalizes a pragmatic, identity-correct model of post-exploitation defence for IoT environments: enforce least privilege at the syscall authorization boundary, anchor decisions in immutable kernel facts, and surround enforcement with production-grade safety and observability. The empirical results show that this approach can deliver complete containment for the evaluated post-exploitation scenarios with modest overhead, offering a viable path to scalable, on-device mitigation of zero-day and living-off-the-land activity in heterogeneous IoT fleets.