AI vs. OT Hacktivists: Stop VNC Intrusions Fast

A surprising number of industrial incidents still start the same way: an Internet-facing remote access port, a weak password, and nobody noticing until operators lose visibility on a human-machine interface (HMI). That’s not a hypothetical risk—US agencies are warning that pro-Russia hacktivist groups have been actively probing and breaking into critical infrastructure environments by targeting exposed VNC connections.

Most companies get this wrong. They treat “unsophisticated” attackers as “low priority,” then act shocked when a brute-forced remote desktop session turns into altered setpoints, disabled alarms, and emergency call-ins. Opportunistic groups don’t need advanced malware if the front door is open.

This post (part of our AI in Cybersecurity series) explains what the new wave of OT intrusions looks like, why it’s hitting water/wastewater, energy, and food/ag so often, and how AI-driven threat detection can spot and stop these attacks earlier than traditional alerting.

What the feds are warning about—and why it matters

Federal agencies have identified several pro-Russia hacktivist groups and affiliates (including Cyber Army of Russia Reborn (CARR), Z-Pentest, NoName057(16), and Sector16) as active threats against US critical infrastructure. The pattern they’re exploiting is painfully familiar: minimally secured, Internet-facing OT access paths, especially remote screen-sharing services like VNC.

The operational impact isn’t just “cyber.” In OT, the same session that lets a remote operator view a process can also be used to change instrument settings, modify device names, alter credentials, disable alarms, or force a shutdown/restart. Even when physical harm hasn’t occurred, disruption creates real costs—downtime, emergency response labor, contractor support, and prolonged remediation.

Here’s the part leaders should take seriously: “Low sophistication” doesn’t mean “low consequence.” The playbook is simple, but it targets systems where visibility and control are the business.

Why these attacks are showing up now

Late 2025 is a particularly noisy period for critical infrastructure defenders. Geopolitical tension remains high, and hacktivist ecosystems have matured: groups share tools, trade access tips, and amplify one another’s claims online. That collaboration matters because it increases the pace of iteration.

Also, many critical infrastructure environments still carry technical debt:

• Legacy OT devices that weren’t designed for Internet exposure
• Remote access “temporary exceptions” that became permanent
• Incomplete asset inventories (“we’re not sure what’s reachable”)
• Shared local accounts and weak authentication on HMIs

Attackers don’t need zero-days when defenders haven’t closed 20-year-old doors.

How the VNC-to-HMI intrusion chain actually works

The consistent intrusion chain described by authorities is a great example of why AI in cybersecurity is so valuable for OT: the individual steps look mundane, but the sequence is highly suspicious.

Step-by-step: from scanning to operator impact

At a high level, these attacks often follow this progression:

1. Scan for Internet-facing devices with open VNC ports
2. Spin up a temporary VPS to mask origin and rotate infrastructure
3. Brute-force credentials (or log in if there’s no password/default creds)
4. Open a VNC session to confirm access and map what the screen controls
5. Interact with the HMI: record screens, take screenshots, test controls
6. Change parameters (accounts, names, instrument settings)
7. Disable alarms / create loss of view to force hands-on intervention
8. Disconnect and pivot: look for other reachable networks post-intrusion

This is exactly the kind of “simple” attack that bypasses teams relying on a narrow set of signatures or a once-a-day review of logs.

Why OT environments struggle to catch it

In many industrial networks, traditional detection fails for predictable reasons:

• VNC traffic is seen as “normal remote ops,” so it’s not flagged
• Authentication telemetry is limited on older devices
• Logs are siloed (IT sees the perimeter; OT sees the process; nobody correlates)
• Alerts don’t express risk: 300 failed logins looks like noise until it’s not

The reality? You don’t need perfect logging to detect this. You need better correlation. That’s where AI earns its keep.

Where AI-driven threat detection helps most in OT

AI doesn’t magically “secure ICS.” What it does well—when implemented correctly—is detect abnormal patterns across messy data and surface the incidents that humans would otherwise miss.

1) Detect exposed-remote-access abuse faster than rule-based alerts

Rules are useful, but attackers adapt quickly:

• They throttle brute-force attempts to avoid thresholds
• They rotate IPs via VPS providers
• They time activity for shift changes or weekends

An AI-driven model can score risk based on combined signals like:

• First-time-seen external IP establishing VNC sessions
• Unusual authentication failure patterns (rate + timing + account targeting)
• New remote access at odd hours for a site with stable operating routines
• Sudden changes in device configuration events after remote session start

A single signal might be explainable. The combination usually isn’t.

2) Catch “loss of view” and process anomalies as security events

One of the most telling details in these incidents is the attacker behavior: disable alarms and create loss of view—forcing a local operator to intervene. Many organizations treat that as a reliability problem, not a security one.

Modern AI-based monitoring can correlate:

• HMI session activity (remote access)
• Alarm state transitions
• Operator acknowledgment patterns
• Process variable shifts that don’t match historical control behavior

That correlation turns “weird plant behavior” into an actionable security incident.

3) Reduce false positives with OT-aware baselines

Security teams often avoid deep OT alerting because of noise. AI helps by building baselines that reflect how a specific site operates:

• Which vendors normally remote in
• What “normal” session duration looks like
• Which HMIs are used by which shifts
• How often setpoints change in steady-state operations

The payoff is practical: fewer alerts, higher confidence, faster response.

4) Speed triage when every minute affects operations

When a water treatment facility or energy operator sees disruption, response time isn’t measured in days. It’s measured in minutes.

AI-assisted triage can:

• Summarize what changed (accounts, setpoints, alarm states)
• Identify other assets with similar exposure (other VNC endpoints)
• Prioritize containment actions based on likely blast radius

This matters because OT responders can’t “just isolate everything” without consequences.

The OT security controls that matter (and how AI fits in)

AI is most effective when it sits on top of solid fundamentals. If your environment has exposed VNC and shared passwords, AI will still alert you—but you’re playing defense with the parking brake on.

Quick wins to reduce VNC-driven OT risk

If you own or operate OT networks, these are the controls I’d push first:

1. Remove OT assets from the public Internet

   • No direct exposure for HMIs, engineering workstations, or control interfaces

2. Replace ad-hoc remote access with controlled pathways

   • Centralized access with approvals, logging, and session recording

3. Eliminate default/weak passwords and shared accounts

   • Use unique credentials and strong authentication wherever possible

4. Segment networks so remote access can’t become a pivot

   • Restrict which hosts can talk to control devices

5. Enable separation of “view” vs. “control”

   • If a role only needs monitoring, it shouldn’t be able to change setpoints

6. Harden the HMI layer

   • Reduce privileges, lock down configuration tools, and secure backups

Where AI should sit in the architecture

For critical infrastructure, the best pattern is:

• Prevention controls (segmentation, access gateways, strong auth)
• Continuous monitoring (network + identity + process telemetry)
• AI-based detection and correlation to prioritize real threats
• Response automation that’s OT-safe (contain without breaking operations)

A practical stance: use AI to shrink detection time, then use playbooks to shrink response time.

A simple OT incident playbook for VNC intrusion attempts

If your team wants something concrete to operationalize, use this as a starting point. It’s intentionally short so it’ll actually get adopted.

When you see scanning or brute-force attempts

• Block or rate-limit at the edge (where safe)
• Confirm whether the target asset should be reachable externally (it shouldn’t)
• Identify exposed services across the site (asset inventory + scanning)
• Add AI-driven correlation rules: repeated VNC auth failures + new external IP

When you confirm an active VNC session to an HMI

• Shift to incident mode: record timestamps, screenshots, session details
• Contain via remote access gateway controls (don’t yank power unless necessary)
• Validate alarm status, operator visibility, and last known good configurations
• Check for credential changes and revoke affected accounts

After containment

• Restore from known good configs (HMI/project files, not just OS images)
• Hunt for lateral movement indicators (new routes, new remote tools, new users)
• Add detections for the exact sequence observed (scan → brute-force → VNC → changes)

This is where AI helps again: once you teach the system the sequence, it can find near-misses across other sites.

What security leaders should do before the next advisory

The groups named by the government may change, but the underlying lesson won’t: opportunistic threats keep winning against exposed OT remote access. The fastest way to reduce risk is to combine non-negotiable hygiene (no Internet-facing HMIs) with monitoring that’s smart enough to catch the subtle early steps.

If you’re evaluating AI for OT security, pressure-test it with real questions:

• Can it distinguish “normal vendor access” from suspicious remote sessions?
• Can it correlate IT-side signals (edge logs, identity events) with OT telemetry?
• Can it explain why an alert matters in operational terms (alarms disabled, loss of view)?
• Can it support response actions that won’t break production?

Critical infrastructure security isn’t about chasing perfect. It’s about shrinking the time between first strange signal and containment.

The next 30 days are a good time to run a targeted exercise: assume an attacker finds an exposed VNC endpoint and reaches an HMI. How quickly would your team know—and what would they do first?