Living Off the Land in Cyber-Physical Systems: Why Process Awareness Matters

Industrial control systems are no longer isolated networks with clear perimeters. They are interconnected environments where digital actions translate directly into a physical output. In this context, attackers no longer have to rely on traditional malware or external disruptive tooling. Instead, they increasingly use living-off-the-land (LOTL) techniques within OT, leveraging legitimate system tools, services, credentials, and workflows to achieve their objectives. The result is an attack path that often slips past traditional cybersecurity detection controls, particularly those focused solely on network activity.

This trend was highlighted in the recent Poland energy attack, where coordinated activity against distributed energy sites involved extended periods of unauthorized reconnaissance and control interactions without conspicuous malware. Because the adversaries operated within the bounds of legitimate engineering workflows and tools, network-centric monitoring alone was insufficient to reveal the threat and malicious activity. What this makes clear to us is that understanding behaviour at the process layer—the actual states and dynamics of the physical system—is not optional: it is necessary to detect and mitigate such sophisticated threats.

What Makes LOTL Unique in CPS Environments

In a living-off-the-land scenario, attackers exploit:

• Legitimate remote access channels (e.g., VPN, RDP to engineering stations)
• Standard vendor tools and administrative utilities already present in the environment
• Approved engineering workflows, such as configuration management or controller programming
• Control and historian system interactions that appear normal in isolation
  

Because these actions don’t involve recognizable malware or overtly malicious packets, many conventional solutions, particularly those solely focused on network traffic analysis, are unable to detect such activity, generate no meaningful alerts, or rely solely on high-confidence signatures that were never designed to catch engineering-layer manipulation.

In the Poland energy case, attackers were inside operational networks for months without triggering typical intrusion detection systems. They conducted credential harvesting, enumerated control systems, and interacted with Remote Terminal Unit (RTU) and programmable logic controller (PLC) configurations all while deploying code and tools that, by design, blended seamlessly into legitimate engineering activity. The first visible anomaly was subtle: a deviation in process behaviour and control states that could only be observed at the engineering layer. That deviation triggered a cascading event series of alerts and incidents which ultimately allowed the detection of the sabotaging activity. In our view, this is the clearest real-world demonstration yet of why process-layer visibility is needed.

Why Engineering Intelligence Is Required

To detect LOTL attacks in cyber-physical systems, defenders must shift from isolated network-centric visibility to engineering-aware observability. This means correlating cyber activity with process behaviour and physical system states. We believe this is the critical gap that most OT security strategies are currently missing.

LOTL Analysis

The following key elements can enable this shift to engineering-aware observability.

1. Contextual Mapping of Critical Assets

Unlike traditional static asset inventories, engineering-layer mapping links hardware and software to:

• Control functions
• Safety instrumented functions (SIFs)
• Physical process relationships
• Protection relay dependencies

Detecting suspicious activity requires understanding what each component controls and correlating how a compromise could affect the system and its baseline behaviour. Without the engineering context, even good detections may lead to poor decisions.

2. Logic Integrity Monitoring

LOTL adversaries often interact with legitimate control logic and system functions. Detecting unauthorized or anomalous changes to logic requires:

• Continuous verification of PLC/DCS/SIS program state
• Comparison against approved baselines and change tickets/records
• Detection of checksum deviations or unplanned edits

Without this, configuration drift may go unnoticed until damage occurs.

3. Historian and Process Correlation

Network traffic alone does not reveal the consequences of engineering actions. To determine whether a control action reflects normal operations or an active threat, defenders must look deeper. By correlating the following data sources, defenders can gain insight into whether a control action has a legitimate physical outcome or is part of a reconnaissance or manipulation pattern:

• Historian tag behaviour
• Alarms and events
• Engineering workstation activity

Without this correlation, defenders are left interpreting cyber alerts without the operational context needed to act decisively.

4. Safety Barrier Exposure Tracking

LOTL attacks often aim to degrade safety layers without triggering alarms. Tracking safety bypasses, override conditions, and parameter deviations in safety instrumented functions provides early warning of escalating physical risk. This is an area we feel is consistently underweighted in conventional OT security programmes.

5. Dynamic Risk Indexing

Instead of counting alerts, risk must be measured in terms of operational consequence. Techniques that combine asset criticality, process impact, and control integrity produce a risk score that reflects real business and physical exposure.

Beyond the Poland Case: Broader Implications

The Poland energy attack illustrates a broader class of threats that we anticipate will become more, not less, common. The tactics, techniques, and procedures observed reflect a repeatable playbook that adversaries can and will apply across similar industrial environments. When we examine what made this attack possible and difficult to detect, three realities emerge:

1. Distributed energy systems with similar technology and control stacks across multiple sites are repeatable targets.
2. Credential misuse and reconnaissance are as damaging as conventional exploits.
3. Legitimate and built-in engineering tools provide adversaries with the means to probe and influence physical equipment.

Detecting these threats requires visibility into how a system is supposed to operate and interact, as well as how its physical processes should behave. Network packet inspection alone can only see connections, not consequences.

Engineering Intelligence: The Next Layer of CPS Defence

A threat-informed defence strategy that incorporates engineering intelligence is the necessary next layer for effective CPS defence. Without it, security teams are flying blind, reactive to alerts they don’t fully understand in environments they’ve never modelled. This threat-informed defence strategy incorporates engineering intelligence to bridge the gap between traditional security thinking and operational reality. This strategy includes:

• Integrating safety and cybersecurity data
• Mapping control logic and process functions
• Correlating historian trends with cyber events
• Measuring risk in terms of physical impact

This approach does not replace traditional security tools. Rather, it augments them with a deeper understanding of how the process works and what constitutes abnormal behaviour.

As adversaries adopt LOTL techniques in OT, defenders must move beyond perimeter and isolated monitoring to process-aware detection and response. We see this as essential for safeguarding critical infrastructure in an era where digital activity can directly and consequentially influence physical systems.

For a detailed technical analysis of the Poland energy attack, including engineering layer insights and defensive recommendations, read the article: Lessons from the Poland Energy Attack.