PaperlayerView exact revision on arXiv

Source-linked AI summary

MARS: Detecting Unauthorized Variable Manipulations in Multi-Application PLC Runtimes

Syed Ghazanfar Abbas, Dongyan Xu

arXiv:2609.06306v1cs.CR

TL;DR

Multi-application PLCs share control variables, but conventional defenses do not establish which application made a write or whether it was authorized. MARS profiles and validates application writes on virtual PLCs, then uses shadow execution evidence to assess live changes, including changes absent from the shadow. Across three industrial testbeds, it detected all evaluated modifications and uniquely attributed 93.3% of live-PLC-only executions while preserving ambiguity when evidence was insufficient.

  • Problem

    Multi-application PLCs allow applications to access shared control variables, while commodity runtimes generally do not expose writer identity for diagnosing manipulations.

    Source: §1 · pp. 1–2

  • Method

    MARS recovers application-labeled writes on instrumented vPLCs and uses bounded shadow-vPLC execution evidence to detect and attribute live-PLC-only modifications without modifying the live controller.

    Source: §1 · p. 2

  • Results

    Across three industrial testbeds, MARS detected all evaluated unauthorized modifications and uniquely attributed 93.3% of live-PLC-only executions while preserving ambiguity when evidence was insufficient.

    Source: §9 · p. 13

  • Takeaways & Limitations

    Application-origin awareness complements existing ICS defenses for detecting unauthorized variable writes in multi-application PLC runtimes.

    Source: §9 · p. 13

    MARS targets cross-application authorization violations and does not detect malicious use of a write privilege an application legitimately possesses.

    Source: §7 · p. 12

Abstract

from arXiv · show

Programmable Logic Controllers (PLCs) increasingly run multiple applications alongside the main control program, with shared access to PLC variables. Yet, Industrial Control System (ICS) defenses primarily detect malicious updates by checking whether variable values violate expected bounds, without considering which application performed the update. A malicious application can exploit this gap by modifying variables within normal bounds while still driving the physical process toward an unsafe state. Even when such manipulation is detected, operators cannot identify the responsible application because PLCs do not associate variable updates with application identity. We present MARS, an automated framework for application-level authorization and attribution of PLC variable manipulations. MARS profiles applications on an isolated virtual PLC (vPLC) to derive application-specific variable-access policies and uses a shadow vPLC during operation to attribute production-PLC updates to individual applications without instrumenting the production controller. MARS also detects manipulations that occur only on the production PLC and therefore have no corresponding update on the shadow vPLC. We evaluate MARS on manufacturing, chemical, and water-treatment systems against attacks in which unauthorized applications manipulate PLC variables while remaining within normal bounds. Our results show that MARS detects these manipulations and identifies the responsible application.

1 Introduction

Multi-application PLC runtimes let co-running applications access control variables, but conventional defenses focus on values rather than the identity and authority of the writer. MARS profiles application writes on virtual PLCs, validates them against operator-supplied policies, and uses shadow execution evidence to detect and attribute unauthorized modifications.

1 Introduction

  • Multi-application runtimes place vendor and third-party applications alongside the control program, and those applications can access variables used in control decisions.A compromised application can change such a variable without altering the control program, which may then consume the manipulated value.Source: §1 · p. 1
  • Conventional defenses assess values or process behavior, so a legitimate value does not establish that its writer was authorized.Co-running applications can have different authorization scopes for the same variable.Source: §1 · p. 1
  • MARS profiles application-labeled writes on an instrumented vPLC and checks them against an operator-supplied policy before deployment.The policy specifies which applications may modify each monitored variable.Source: §1 · p. 2
  • For live-PLC-only modifications, MARS uses bounded shadow-vPLC execution evidence to identify a writer when supported and preserve ambiguity otherwise.The technique does not require modifying the production controller.Source: §1 · p. 2
  • MARS detects all 15 evaluated attacks and uniquely attributes 140/150 live-PLC executions (93.3%), reporting the remaining 10 as ambiguous with no incorrect unique attribution.It produces no false unauthorized-write alerts across 59,810 benign updates and has 24.3–32.7 ms median decision latency across three platforms.Source: §1 · p. 2

2 Threat Model

The threat model considers a compromised runtime application able to access reachable PLC variables, while the operator controls the authorization policy and trusted components are specified.

2 Threat Model

  • The operator or security engineer supplies the write-access policy and can run the authorized project and application packages on isolated vPLCs.The policy may draw on engineering configuration, site policy, documentation, and operator knowledge; profiling traces cannot silently expand authority.Source: §2 · pp. 2–3
  • The attacker may execute code in a compromised application, read or write reachable variables, choose in-range values, and time writes without changing the main control program.In the live-only setting, malicious behavior may be triggered only on the plant PLC while normal execution continues on the shadow.Source: §2 · p. 3
  • MARS trusts the control program, operator policy, vPLC/shadow environment, and external MARS host, and assumes the plant and shadow contain the same application set.Physical field-device attacks, compromise of trusted components, and malicious use of an already-authorized write are outside scope; unknown plant-only software cannot be assigned a known shadow identity.Source: §2 · p. 3

3 Motivation

The manufacturing example shows how a diagnostic application can write a valid shared variable without authorization, changing the control program’s routing decision before the authorized result arrives.

3 Motivation

  • The manufacturing runtime shares NFC_Result among the control program, an NFC application, and a diagnostic application.The NFC application may update the variable, while the diagnostic application is authorized only to read it.Source: §3 · p. 3
  • During classification, the compromised diagnostic application changes NFC_Result from WAIT to DISCARD before the NFC application produces its result.The control program accepts DISCARD and routes the valid workpiece to the discard station before the later VALID classification arrives.Source: §3 · p. 3
  • The attack uses a legitimate value, so value-only monitoring cannot distinguish the diagnostic application’s unauthorized write from an authorized NFC write.The source and timing of the write distinguish the attack, not the value DISCARD alone.Source: §3 · p. 3
  • The physical consequence depends on when the unauthorized write occurs, but the modification violates the write policy regardless of a later change in outcome.Here, the control program consumes the terminal classification while waiting for the NFC result.Source: §3 · p. 3

4 MARS Overview

MARS uses instrumented virtual PLCs to validate application writes before deployment and a shadow PLC during operation to assess live modifications, including writes absent from the shadow.

4 MARS Overview

  • MARS has pre-deployment and post-deployment validation phases and recovers application-labeled writes and execution information on an instrumented vPLC.During operation, an instrumented shadow vPLC runs alongside the live PLC, which remains unchanged.Source: §4 · pp. 3–4
  • For each monitored variable, the operator-supplied policy Wv specifies the applications permitted to modify it.MARS uses these constraints to distinguish observed application behavior from authorized behavior.Source: §4 · p. 4
  • For a live-only change, MARS uses applications observed in the corresponding and, when needed, adjacent shadow cycles as attribution candidates.A unique application is reported only when one candidate remains; otherwise, MARS reports the remaining candidate set.Source: §4 · p. 4
  • MARS profiles application-labeled writes and execution structure, then checks each observed write against the operator-supplied policy before deployment.Source: §4 · p. 4
  • During operation, MARS aligns live and shadow control cycles and validates transitions with corresponding shadow writes as well as live-only transitions.The live PLC supplies variable snapshots after each cycle, while the shadow supplies application-level information.Source: §4 · p. 4

5 MARS Design

MARS profiles application writes and execution on an instrumented vPLC, then uses policy checks and live–shadow evidence to validate and attribute PLC-variable changes. It aligns controllers by control cycle and preserves ambiguity when the evidence cannot identify one writer.

5.1 Step 1: Profiling Variable Writes

  • Profiling collects application-labeled writes and runtime-application executions, while dynamic resolution maps monitored variables to their current vPLC addresses.The read-only resolver obtains addresses without modifying monitored values.Source: §5.1 · pp. 4–5, Figure 4 · p. 5

5.2 Step 2: Pre-Deployment Validation

  • Before deployment, MARS checks each directly identified writer against the operator-supplied authorization policy; profiling never expands that policy.An unauthorized write exercised during profiling is reported rather than learned as legitimate behavior.Source: §5.2 · p. 5

5.3 Step 3: Aligning Live and Shadow PLCs

  • MARS localizes live changes to control-cycle intervals and searches the corresponding shadow interval, then adjacent cycles, to tolerate execution displacement.The live PLC does not expose the writer or the order of multiple writes within an interval.Source: §5.3 · pp. 5–6

5.4 Step 4: Post-Deployment Validation

  • For each live transition, MARS first seeks a matching labeled shadow write; absent a match, it uses applications executing in the bounded window as candidates.It reports a unique writer only when one candidate remains; otherwise it preserves ambiguity, reports only the supported authorization conclusion, or leaves the transition unattributed when no candidate exists.Source: §5.4 · pp. 6–7

6 Evaluation

MARS is evaluated on three industrial testbeds using application-level attacks designed to keep written values within legitimate domains. In pre-deployment validation, it detects all 15 unauthorized writes because the vPLC exposes the writer identity and the policy specifies permitted writers.

6.1 Experimental Setup

  • The evaluation spans manufacturing, chemical-processing, and water-treatment testbeds and 15 manually validated attacks with legitimate-domain values and measurable control or physical effects.The attacks include categorical substitutions, in-range setpoint changes, premature status updates, actuator or configuration changes, and operating-mode changes.Source: §6.1 · p. 7
  • The same attacks are tested during isolated-vPLC profiling and in live-PLC-only runs, with ten launch timings per attack yielding 150 live-PLC-only runs.The setup distinguishes authorization detection from unique, ambiguous, wrong, and unattributed attribution outcomes.Source: §6.1 · p. 7

6.2 Pre-Deployment Detection (RQ1)

  • MARS detects all 15 unauthorized writes in pre-deployment validation, although each manipulation uses a legitimate-domain value.The decision uses the vPLC-observed application identity and the independently supplied policy, not the replacement value’s validity.Source: §6.2 · p. 8

6.3 Live-PLC-Only Attack Attribution (RQ2)

For live-PLC-only writes, MARS can establish authorization violations using bounded shadow-vPLC execution evidence while preserving ambiguity when it cannot uniquely identify a writer. The evaluations also compare defenses, benign-operation alerts, latency, and design choices.

6.3 Live-PLC-Only Attack Attribution (RQ2)

  • 140/150 (93.3%) live-PLC-only runs receive correct unique attribution; all 150 violations are identified, and the remaining ten stay ambiguous without incorrect unique attribution.When a candidate set contains both authorized and unauthorized applications, MARS reports ambiguous origin and authorization rather than making an unsupported decision.Source: Table 4 · p. 9, §6.3 · p. 9

6.4 Comparison with Existing ICS Defenses (RQ3)

  • 15/15 attack classes are detected by MARS, versus 4/15 for SAIN and 3/15 for network-command correlation, showing complementary coverage rather than a general defense ranking.MARS checks whether the application associated with a variable modification is authorized, including when values remain in legitimate domains and external commands appear normal.Source: Table 5 · p. 9, §6.4 · p. 9

6.5 False Positives on Benign Operation (RQ4)

  • 59,810 benign PLC-variable updates produce no false unauthorized-write alerts.For live updates without a matching shadow write, MARS uses bounded application candidates and avoids assigning an unsupported unique writer.Source: §6.5 · pp. 9–10, Table 6 · p. 10

6.6 Monitoring-to-Decision Latency (RQ5)

  • 24.3–32.7 ms median application-aware decision latency, with 95th-percentile decision latency below 56 ms across all three testbeds, includes shadow correlation and policy evaluation.Median transition latency ranges from 12.6 to 16.9 ms.Source: Table 7 · p. 10, §6.6 · p. 10

6.7 Design Analysis (RQ6)

  • 140/150 (93.3%) correct unique attributions fall to 98/150 (65.3%) with exact-cycle evidence; historical-write candidates yield 4/150 (2.7%).With exact-cycle evidence, 43 runs are unattributed because the responsible application's shadow execution occurs in an adjacent control-cycle interval.Source: Table 8 · p. 10, §6.7 · p. 10
  • At w = 1, MARS achieves 140/150 (93.3%) correct unique attributions; widening to w = 2 and w = 3 increases ambiguity from 10 runs to 18 and 27 without adding candidate coverage.The w = 0 window leaves 43 runs unattributed because the responsible application's shadow execution falls outside the corresponding control cycle.Source: Table 9 · p. 10, §6.7 · p. 10
  • 30 writes to variables with online-changing addresses are all missed by fixed offsets, while MARS misses none after re-resolving addresses.This experiment evaluates monitoring robustness separately from application attribution.Source: Table 10 · p. 11, §6.7 · p. 11
  • MARS uses the same attribution and policy-validation procedure across three evaluated PLC stacks, but the results do not establish equivalent virtualization or instrumentation capabilities on every PLC runtime.Platform-specific instrumentation is confined to the vPLC side.Source: §6.7 · p. 11

6.8 Attribution under Application Concurrency (RQ7)

MARS’s live-only attribution becomes less specific as runtime concurrency or live/shadow jitter increases. In the evaluated runs, lost specificity appears as ambiguity or no attribution, not an incorrect unique attribution.

6.8 Attribution under Application Concurrency (RQ7)

  • Concurrency tests varied active applications from one to four or five across 200 live-only attack runs; the independent variable was active application count, not final candidate-set size.Depending on scheduling, only a subset of active applications executed inside the bounded shadow window.Source: §6.8 · p. 11
  • Unique attribution fell from 100% with one active application to 70% with four or five; all 28 lost unique attributions were ambiguous, with no incorrect unique attribution in 200 runs.With two active applications, MARS uniquely attributed 46/50 runs (92%); with three, it attributed 41/50 (82%).Source: Table 11 · p. 11, §6.8 · p. 11

6.9 Robustness to Live/Shadow Scheduling Jitter (RQ8)

  • 93.3% (140/150) unique attribution at J=0 fell to 50.7% (76/150) at ±5-cycle jitter, with no incorrect unique attribution across tested bounds.At ±1-cycle jitter, unique attribution was 133/150 (88.7%); at ±3 cycles, it was 103/150 (68.7%).Source: §6.9 · pp. 11–12, Table 12 · p. 12
  • A wider attribution window can recover more jittered executions but admits more unrelated applications, trading candidate coverage against attribution discrimination.The evaluated configuration used a fixed w = 1 window.Source: §6.9 · p. 12

7 Discussion and Limitations

MARS assesses whether an application is authorized to write a variable, independently of whether the value is legitimate. Its conclusions depend on the supplied policy and bounded evidence, and its live-PLC observation and attribution have stated limits.

7 Discussion and Limitations

  • MARS does not detect malicious use of a write privilege the application legitimately holds, so this behavior requires complementary process- or behavior-aware mechanisms.MARS targets cross-application authorization violations and complements process-, state-, and value-aware defenses.Source: §7 · p. 12
  • A singleton shadow-execution candidate supports evidence-based attribution, not direct causal provenance from the live PLC; MARS provides no formal guarantee of causal writer provenance.MARS preserves ambiguity when more than one candidate remains.Source: §7 · p. 12
  • When a candidate set contains both authorized and unauthorized applications, MARS cannot determine the write’s authorization status and preserves ambiguity.Reported live-only detection results apply to evaluated executions, not every possible candidate set.Source: §7 · p. 12
  • Because MARS observes modifications between control-cycle observations, a transient unauthorized value completely overwritten within one interval may remain unseen.Detecting such writes would require finer-grained live-PLC observation or instrumentation.Source: §7 · p. 12
  • MARS assumes the operator-supplied write policy is correct and that live and shadow PLCs contain the same applications and remain sufficiently aligned.Policy construction remains a deployment task; inventory verification, attestation, and synchronization are complementary mechanisms.Source: §7 · p. 12
  • A future PLC runtime could expose authenticated writer identity and enforce per-variable permissions, rejecting unauthorized writes before the control program consumes them.The paper identifies this as a next step toward enforceable application-level least privilege.Source: §7 · pp. 12–13

8 Related Work

MARS addresses authorization by evaluating application-level evidence against a per-variable write policy, a different question from whether values or behavior deviate from expected operation. Its use of a shadow vPLC for execution evidence also differs from reference-based validation and complements application isolation.

7 Related Work

  • Prior ICS defenses use process models, invariants, program semantics, and data-driven methods to detect deviations in values, control states, or physical behavior [22].MARS instead checks whether the application associated with a modification is authorized under an explicit per-variable policy.Source: §8 · p. 13
  • MARS does not require live-PLC modifications to be reproduced on the shadow; nearby shadow-vPLC application executions provide bounded candidate evidence, which MARS evaluates against the write policy.Application isolation is complementary: it protects execution domains, while MARS validates application-level write authorization for shared PLC variables.Source: §8 · p. 13

9 Conclusion

MARS uses runtime-application identity to assess write authorization in multi-application PLC runtimes, recovering application-level evidence without modifying the live PLC. Across three industrial testbeds, it detected all evaluated unauthorized modifications and uniquely attributed 93.3% of live-only executions while preserving ambiguity when evidence was insufficient.

9 Conclusion

  • MARS detects unauthorized PLC-variable modifications in multi-application runtimes by using runtime-application identity for write authorization.It recovers application-level evidence with instrumented vPLCs and a shadow vPLC without modifying the live PLC.Source: §9 · p. 13
  • Across three industrial testbeds, MARS detected all evaluated unauthorized modifications and uniquely attributed 93.3% of live-PLC-only executions.It preserved ambiguity when evidence was insufficient.Source: §9 · p. 13
  • The results support application-origin awareness as a complement to existing ICS defenses for detecting unauthorized variable writes in multi-application PLC runtimes.Source: §9 · p. 13

Ethical Considerations

MARS was evaluated on controlled research testbeds, not operational third-party industrial systems. The study examined realistic application-level attacks while avoiding risk to production infrastructure and external users.

Ethical Considerations

  • Experiments were confined to research testbeds under the authors’ control, not operational third-party industrial systems.The evaluated attacks were limited to the experimental environments described in Section 6.Source: Ethical Considerations · p. 14
  • The controlled setup enabled study of realistic application-level attacks and physical effects without exposing production infrastructure or external users to risk.Source: Ethical Considerations · p. 14
  • MARS is intended defensively to identify unauthorized application-level writes and provide evidence about their origin.Source: Ethical Considerations · p. 14
Loading 2609.06306v1…