AI Detection for OT: Stop VNC Attacks on Critical Ops

A single exposed remote-access port can turn a water plant’s control room into a public livestream.

That’s not a metaphor. Federal agencies are warning that pro‑Russia hacktivist groups have been breaking into Internet-facing OT environments through minimally secured VNC and using HMI screens to change setpoints, disable alarms, and force hands-on operator intervention. So far, the impact has often been “opportunistic” and uneven—but the pattern is consistent, repeatable, and scalable.

This post sits squarely in our “AI in Defense & National Security” series because critical infrastructure cyber defense now looks a lot like national security: adversaries don’t need zero-days when they can find exposed remote management and guess a password. The good news is that this is also exactly where AI in cybersecurity earns its keep—by detecting behavior that doesn’t match how real operators, real vendors, and real maintenance windows normally behave.

What the feds are warning about (and why it’s not “just hacktivism”)

Federal partners (including the FBI, CISA, and NSA) have publicly called out multiple pro‑Russia-aligned groups and affiliates—Cyber Army of Russia Reborn (CARR), Z‑Pentest, NoName057(16), and Sector16—for targeting US critical infrastructure, with emphasis on water and wastewater, food and agriculture, and energy.

Here’s the uncomfortable reality: labeling these actors “unsophisticated” can be misleading. Their tools may be basic, but their target selection is strategic. They’re aiming at the kind of environments where disruption is expensive, time-sensitive, and sometimes physically dangerous.

A second uncomfortable reality: “hacktivist” branding can be cover. Analysts have assessed that at least some of these personas may mask direct or indirect state support. In practical security terms, that means defenders should plan as if:

• the intrusion is real,
• the actor is learning and iterating,
• and the campaign won’t stop just because one facility hardens.

The OT playbook: exposed VNC → HMI control → real-world disruption

The attack chain being reported is painfully straightforward. That’s what makes it so operationally important.

Step-by-step: how these VNC intrusions typically work

The pattern looks like this:

1. Scan for Internet-facing devices with open VNC ports (often in OT networks or poorly segmented “gray” networks).
2. Spin up a temporary VPS to reduce attribution and speed up scanning and brute forcing.
3. Brute-force credentials or test default/weak passwords.
4. Use VNC to reach HMI hosts, confirm the control interface, and interact with the graphical system.
5. Record screens or take screenshots to claim access publicly (and to learn the process).
6. Modify parameters—commonly:
   • device names
   • usernames/passwords
   • instrument settings
   • alarm configurations (including disabling alarms)
7. Induce loss of view, forcing on-site operator work, and sometimes restart or shut down devices.

In OT, “loss of view” is not a minor inconvenience. It’s a safety and reliability problem. It also creates the kind of operational chaos that attackers love because it consumes staff attention and increases the chance of mistakes.

Why this matters more in winter and at year-end

It’s December 2025. Many organizations are running with:

• reduced staffing during holidays
• deferred maintenance windows pushed to Q1
• vendor support teams operating at partial capacity
• extra pressure to keep uptime stable through cold-weather demand spikes (energy) and seasonal load variability (water)

Attackers don’t need to be clever to take advantage of that. They just need to be early.

Why traditional defenses miss “opportunistic” OT intrusions

Most companies get this wrong: they apply IT security assumptions to OT and then wonder why the alerts don’t line up with reality.

OT environments tend to have:

• long-lived systems that can’t be patched on IT timelines
• fragile protocols and legacy HMIs
• vendor remote access that’s “temporary” but quietly becomes permanent
• limited telemetry from controllers and engineering workstations
• change control that lives in binders or spreadsheets, not systems

That combination makes signature-based detection and generic correlation rules underperform. A VNC brute-force attempt might look like background noise—until it suddenly becomes a process upset.

What works better is focusing on behavioral truth: how operators and systems actually behave when things are normal.

Where AI helps: anomaly detection that understands OT “normal”

AI isn’t magic in OT security. But it’s very good at one job that matters here: detecting deviations from baseline behavior across messy, partially observed environments.

Think of AI-driven anomaly detection as a layer that answers:

“Does this remote access session look like the way remote access normally happens here?”

That’s a more practical question than “Is this a known bad IP?” because opportunistic actors rotate infrastructure and credentials constantly.

The OT signals AI can learn (even when you don’t have perfect logs)

You don’t need perfect visibility to get value. Start with what you can reliably collect:

• Remote access patterns
  • unusual VNC sessions outside maintenance windows
  • new client fingerprints or geographies
  • sudden spikes in authentication failures
• HMI interaction patterns
  • abnormal click/command tempo (human operators tend to be consistent)
  • new navigation paths (e.g., jumping between unrelated screens)
  • screen capture behavior paired with control actions
• Control and safety signals
  • alarm suppression events
  • unexpected setpoint changes that don’t match the process state
  • rapid toggling (restart/shutdown loops)
• Network segmentation “leaks”
  • VNC traffic originating from subnets that shouldn’t initiate OT control sessions
  • lateral movement attempts immediately after first access

AI models can score these behaviors in near real time and escalate the ones that don’t fit your environment’s baseline.

A concrete example: catching the VNC intrusion before it becomes downtime

Here’s a realistic detection storyline:

• A VNC service becomes reachable from the Internet due to a firewall rule drift.
• Brute-force attempts begin from a short-lived VPS.
• A successful login happens at 2:17 a.m.
• The session immediately navigates to alarm configuration screens and disables an alert.

Traditional tooling may generate separate alerts (if any): failed logins, a remote session, a configuration change. AI-driven detection can connect them as one story: this sequence doesn’t match any legitimate remote support workflow. That’s the difference between “investigate tomorrow” and “stop it now.”

Practical mitigations (and how to prioritize them for leads and outcomes)

If you own or secure OT, you already know the advice: reduce exposure, improve authentication, segment networks. The problem is sequencing. Here’s what I’ve found works when you need measurable risk reduction quickly.

1) Remove OT remote access from the public Internet—aggressively

If VNC must exist at all, it shouldn’t be Internet-facing.

Do this first:

• eliminate direct exposure of VNC/RDP from public IP space
• enforce access through hardened jump hosts or brokered remote access
• restrict by allowlist and time-bound approvals

Outcome to measure: number of OT assets with direct Internet exposure should be zero.

2) Make “default credentials” impossible to survive

These intrusions succeed because weak authentication persists.

Minimum bar:

• unique credentials per device and per site
• password vaulting for shared accounts
• MFA where feasible (especially for remote access brokers)

Outcome to measure: percentage of OT remote access accounts covered by strong auth controls.

3) Turn HMI actions into security events (not just operator events)

In many facilities, HMI changes are operationally logged but not treated as security telemetry.

Promote to security monitoring:

• alarm enable/disable changes
• user creation, privilege changes
• setpoint changes outside approved windows

Outcome to measure: time-to-detect for “unsafe” HMI actions.

4) Use AI to baseline and alert on sequences, not single events

This is where AI in cybersecurity fits naturally in critical infrastructure: it reduces the need for brittle, one-off rules.

Implement:

• anomaly scoring on remote access sessions
• detection of unusual HMI navigation and control patterns
• correlation across identity, network, and process data

Outcome to measure: reduction in false positives while maintaining detection of high-risk behaviors.

5) Build an OT-specific response playbook for “loss of view”

Attackers have been disabling alarms and inducing loss of view because it forces chaos.

Your response plan should specify:

• who is authorized to switch to local control
• how to validate process state when HMI visibility is compromised
• how to isolate remote access fast without shutting down operations blindly

Outcome to measure: time-to-isolate remote access and restore operator visibility.

“People also ask” for OT leaders evaluating AI-driven security

Can AI really work in legacy ICS environments?

Yes—if you scope it correctly. You don’t need agents on PLCs. You need network telemetry, remote access logs, HMI/SCADA audit events, and enough context to learn baselines.

Will AI create too many alerts for a small OT team?

It will if it’s deployed like an IT SIEM. The better pattern is risk scoring and suppression based on stable baselines. OT teams can’t chase noise; AI has to reduce it.

What’s the fastest win against these VNC-style attacks?

Remove Internet exposure and fix authentication. AI adds the next layer: it catches misconfigurations, policy drift, and abnormal sessions that still happen in real life.

The national security angle: defending infrastructure is defending society

This campaign isn’t just about nuisance intrusions. It’s about pressure. When attackers can force local intervention at water facilities or disrupt energy operations, the effect spreads beyond the plant to the community.

AI won’t replace fundamental OT hygiene. But it does something defenders desperately need in critical infrastructure: it shortens the time between “something feels off” and “we’re containing this.” That time gap is where minor access turns into real downtime and physical impact.

If you’re responsible for OT security—whether you sit in a utility SOC, a manufacturing security team, or a national-level program office—treat these opportunistic VNC intrusions as a rehearsal for the next phase. The actor may change, but the weakness they’re exploiting is the same: visibility gaps and remote access sprawl.

What would happen in your environment if an attacker got HMI access for 20 minutes tonight—and would your team know before an operator does?