Generate an Electric Utility Cyber SITREP and in minutes identify the size and scope of the adversarial cyber attack.
REMI analyzes electric utility IT/OT evidence across SCADA, HMI, RTU records, relay events, substation logs, historian data, alarms, firewall flows, VPN activity, identity records, EDR telemetry, vendor access, maintenance records, engineering workstations, and relay-setting files.
Instead of manually comparing SIEM alerts, endpoint logs, VPN sessions, identity records, firewall flows, SCADA events, RTU activity, relay records, historian trends, alarm data, engineering workstation events, and substation records one source at a time, REMI analyzes the full evidence package together. It reconstructs what happened, how access was achieved, which systems were touched, what changed, where relay or grid-support activity occurred, what remains unresolved, and which records support the sequence.
REMI Supports Both IT and Electric OT Event Logs
REMI analyzes evidence from both enterprise incident response and electric utility OT/IT environments, including endpoint activity, VPN and identity records, firewall logs, SCADA activity, HMI actions, relay events, RTU records, historian data, alarms, vendor access, and maintenance records.
By connecting these records across IT and electric operations, REMI helps investigators see whether a cyber incident stayed inside enterprise systems or moved toward substations, relay settings, breaker operations, feeder equipment, grid-support systems, or outage-related processes. It reconstructs what happened, which systems were touched, what changed, what evidence supports the findings, and what records are still needed to close the gaps.
IT Event Logs
OT Event Logs
Operator screens, supervisory commands, acknowledgments, switching actions, setpoint changes, overrides, and control-room activity.
Remote terminal events, device status records, mode changes, forced values, control commands, and substation automation activity.
Protection settings, trip logic, coordination values, pickup thresholds, timing changes, relay events, and configuration baselines.
Voltage, frequency, current, load, breaker status, feeder activity, transformer readings, power factor, and trend records.
Alarm floods, silenced alarms, acknowledgments, resets, outage events, feeder trips, breaker operations, and abnormal grid states.
Relay project files, configuration tools, settings uploads/downloads, scripts, diagnostics, remote sessions, and engineering user activity.
VPN sessions, jump hosts, maintenance accounts, vendor diagnostics, source IPs, approved work windows, and substation support activity.
Substations, feeders, breakers, transformers, reclosers, capacitor banks, circuits, switching records, and downstream service effects.
REMI Is Trained to Recognize Advanced Adversarial Cyber Behaviors in Electric Grid Environments
REMI is trained to recognize advanced adversarial cyber behaviors in both enterprise incident response and water treatment environments.
OT Behavioral Detection
Protection settings, trip logic, coordination values, pickup thresholds, or timing changes outside approved patterns.
Unexpected opens, closes, reclosing activity, feeder trips, load shifts, or abnormal switching behavior.
Remote commands, controller events, setpoint changes, forced values, mode changes, or device status records.
Operator commands, overrides, screen access, alarm acknowledgments, switching actions, or supervisory control activity.
Missing telemetry, alarm floods, quiet periods, resets, altered trends, or gaps in voltage, frequency, and load data.
VPN sessions, jump hosts, diagnostics, maintenance accounts, engineering access windows, and source IPs.
Voltage, frequency, load, current, power factor, relay status, outage records, or threshold violations.
Substations, feeders, breakers, transformers, reclosers, capacitor banks, circuits, or downstream service effects.
IT Behavioral Detection
New locations, impossible travel, off-hours access, failed MFA, token reuse, or abnormal login patterns.
Unexpected processes, scripts, malware paths, dropped files, persistence, hashes, and device telemetry.
Internal traffic, external callbacks, DNS activity, VPN sessions, ports, protocols, and lateral movement paths.
Admin role changes, permission updates, group membership changes, service accounts, and token activity.
Storage access, mailbox activity, API calls, app credentials, file sharing, downloads, and data movement.
Large transfers, unusual downloads, external sharing, archive creation, USB activity, and abnormal outbound traffic.
After-hours access, unusual file access, policy bypasses, removable media use, deleted logs, or access outside job role.
Shared credentials, approved access used at abnormal times, suspicious vendor coordination, unlocked remote tools, or access enabled before activity.
Correlation Is Where the Incident Story Starts to Form
REMI connects scattered flagged behaviors into the first clear view of how malware activity connects to operational disruption.
Flagged behaviors become connected evidence paths across accounts, devices, networks, sessions, engineering workstations, substations, relays, and grid records.
REMI connects related activity across utility IT, SCADA, RTU, relay, historian, alarm, vendor, maintenance, and substation records so responders can see how separate events fit together. One system may show remote access, another may show operations desktop activity, another may show relay engineering traffic, and another may show substation or feeder records. REMI correlates those records by time, account, device, IP address, process, session, destination, relay event, setting file, and repeated behavior.
How REMI Explains the Connections
REMI connected the VPN login, source IP address, account activity, operations desktop activity, relay engineering records, and substation evidence into one evidence path. The first connection showed that **vendor_grid_07** established a VPN session from **203.0.113.44** during an off-hours window.
The second connection showed that the VPN session did not stop at authentication. Within **11 seconds**, the session reached **10.55.18.25** inside the utility network. REMI then connected that internal destination to later activity on **GRID-DT-12**, showing that the remote session moved from external access into a usable operations desktop environment.
From there, REMI connected **GRID-DT-12** to traffic toward **RELAY-ENG-04** inside the relay engineering environment. That mattered because **RELAY-ENG-04** was tied to relay support records used for substation configuration and feeder protection work.
The final connection linked **RELAY-ENG-04** to substation records and a feeder relay setting change. That gave investigators a clear path from VPN access, to utility-network entry, to operations desktop activity, to relay engineering, and finally to grid-support records.
How REMI See's It
REMI connected GRID-LT-18 to c.arden VPN activity from 203.0.113.44, linking device history to the remote-access event.
The session reached 10.55.18.25 inside the electric utility business network 13 seconds after login.
The same session moved from 10.55.18.25 to GRID-DT-12 43 seconds later.
GRID-DT-12 connected toward RELAY-ENG-04, crossing from business access into electric engineering support.
RELAY-ENG-04 aligned with relay-setting, SCADA, breaker, and feeder records, completing the evidence path.
ANALYSIS EXPLAINS HOW THE ATTACK HAPPENED
REMI turns correlated evidence into the explanation of how the incident happened and why the warning signs were missed.
REMI turns correlated evidence into the supported explanation of how the activity unfolded and why the warning signs did not become obvious sooner.
Analysis uses the connected evidence path to explain how access was achieved, how activity moved, which systems were affected, why alerts or controls did not tell the full story, what evidence supports each conclusion, and what remains unresolved.
How REMI Analysis Explains the Remote VPN Path
Details: EGRID-LT-18 was tied to c.arden, whose VPN login came from 203.0.113.44 one week after the laptop was reported stolen.
Why it matters: The same engineer’s device history and account activity are now linked to the remote-access event.
Details: The c.arden VPN session reached 10.77.18.25 inside the utility business network 13 seconds after login.
Why it matters: The remote session did not stop at authentication; it reached an internal network destination.
Details: The same session moved from 10.77.18.25 to OPS-DT-07 43 seconds later.
Why it matters: The activity moved from network entry into a usable internal operations environment.
Details: OPS-DT-07 connected toward EGRID-ENG-04 inside the grid engineering support environment 2 minutes 12 seconds later.
Why it matters: The path crossed from business-network access toward engineering systems used to support grid operations.
Details: EGRID-ENG-04 activity aligned with relay-setting and SCADA-support records 2 minutes 38 seconds later.
Why it matters: The engineering workstation path is now connected to grid-support records tied to substation operations.
REMI’s Assessment
The alarm bells did not ring early because the activity used the valid vendor account vendor_grid_07, passed through trusted remote-access infrastructure, and moved through existing paths between the utility network 10.55.18.25, the operations desktop GRID-DT-12, the relay engineering workstation RELAY-ENG-04, and related substation records.
The VPN login at 3:22:14 AM, MFA activity, source IP 203.0.113.44, firewall flow records, GRID-DT-12 session activity, RELAY-ENG-04 workstation activity, relay support records, and feeder setting records became clear only after REMI connected them across the same account, device, IP address, timestamp, destination system, network path, and grid-support activity.
on-the-spot Reporting
Advanced Cyber Attacks On Nuclear Power Facilities
REMI generates both electric-utility-specific reports and broader incident response reports from the same evidence package. For electric environments, the reports focus on utility, substation, engineering, vendor, security, and grid-control activity, including SCADA/HMI events, historian records, relay-setting changes, RTU activity, vendor maintenance access, portable-media activity, and grid-adjacent IT/OT behavior.
Reporting Package
What happened, what substations, feeders, relays, workstations, or utility systems were affected, and what needs attention.
Flagged grid behaviors, affected sources, first observed activity, relay events, SCADA activity, and utility-network indicators.
Remote access, unusual command activity, relay-setting changes, engineering workstation activity, persistence, tool spawning, and disruption patterns.
Event-by-event sequence showing when activity began, moved through utility systems, reached engineering, and touched grid-support records.
Connects accounts, devices, IP addresses, sessions, relay records, SCADA events, breaker activity, feeder records, and network activity across sources.
Related users, vendors, machines, tools, accounts, substations, feeders, relays, RTUs, and grid-support systems involved in the event.
Touched utility devices, engineering workstations, relays, RTUs, SCADA nodes, substations, feeders, and configuration records.
Files, paths, logs, scripts, binaries, hashes, relay settings, SCADA records, firewall flows, and evidence to preserve.
Size, scope, findings, open questions, affected grid systems, preservation targets, and prioritized responder actions.
SitRep
The evidence-backed sequence of events from first activity through affected systems.
Accounts, devices, networks, systems, vendors, files, sessions, and source records.
Entry point, connection path, lateral movement, trusted access paths, and systems touched.
Account use, approvals, shared access, vendor activity, or open remote tools tied to the evidence.
Findings supported by source records, timestamps, logs, artifacts, and system activity.
Open questions where the current evidence does not yet prove the full answer.
Logs, approvals, asset-owner records, vendor records, source files, or telemetry needed to close each gap.
Preserve, isolate, sandbox, remove, remediate, verify, escalate, or request additional records.
Story Gaps
Question: Was the VPN login approved?
Event logs needed: Maintenance ticket, vendor work order, change approval, and MFA approval record.
Question: Was this source location expected?
Event logs needed: VPN source-IP history, identity sign-in logs, geolocation records, and vendor access baseline.
Detail gap: Was this an approved intermediate host?
Event logs needed: Asset inventory, firewall flow logs, DHCP/DNS records, system owner records, and approved remote-access path records.
Question: Which engineering actions were performed?
Event logs needed: EDR telemetry, engineering workstation logs, project-file access records, tool execution logs, and jump-host records.
Question: Who used the VPN account?
Event logs needed: MFA device record, identity provider logs, account-owner record, vendor assignment record, and privileged-access logs.
Actionable items
Preserve logs for vendor_maint_02, source IP 203.0.113.44, internal host 192.165.43.18, desktop OPS-DT-07, and engineering workstation ENG-WS-04 before removal.
Isolate OPS-DT-07 and ENG-WS-04 from the network. Firewall and EDR records show the VPN path moved through these systems.
Search ENG-WS-04 for C:\Users\Public\update-task.vbs, C:\Temp\stage.ps1, and C:\ProgramData\svc-loader.bat.
Search OPS-DT-07 for C:\Users\j.martinez\AppData\Roaming\sysrunner.exe and preserve a forensic copy for sandboxing.
After preservation, remove C:\Temp\stage.ps1, C:\ProgramData\svc-loader.bat, and C:\Users\Public\update-task.vbs from affected hosts.
Disable vendor_maint_02, revoke active VPN sessions, rotate credentials, reset MFA, and review vendor access tied to 203.0.113.44.
Review and remediate project folders on ENG-WS-04, including D:\Engineering\Projects\NorthPump and related control-support files touched during the session.
Check OPS-DT-07, ENG-WS-04, 192.165.43.18, and VPN logs for new callbacks, scheduled tasks, repeated processes, reopened sessions, or restored persistence.
Use Case:
how REMI turns event logs and source records into a cyber SITREP
Modified Relay Settings After Vendor Maintenance
At 6:22 AM, the protection engineering lead at North Valley Electric noticed that the feeder protection profile for BRK-17 did not match the approved post maintenance baseline. The relay was online, but the pattern was wrong: SEL-451-2F showed a new active settings group, the upload timestamp came after the approved vendor window, and the breaker event record did not line up with the signed relay-setting package.
...
Download: remi_electric_relay_setting_manipulation_sitrep_use_case.pdf
Quiet Movement and Pre-Positioning Inside the Grid
At 4:18 AM, the transmission control-room operator at North Valley Electric noticed that breaker-status changes from three substations did not line up with the overnight operating plan. Nothing was fully offline, but the pattern was wrong: East Ridge, Mill Creek, and South Yard each showed short command-and-acknowledgement bursts within the same twenty-minute window.
Download: remi_nuclear_ai_logic_package_sitrep_use_case.pdf
Stolen Engineering Laptop Used for Remote VPN Access
At 5:48 AM, the distribution control-room operator at North Valley Electric noticed that feeder status values from the East Ridge substation did not line up with the morning switching schedule. Nothing was fully offline, but the pattern was wrong: a breaker status changed without a matching operator note, relay communication showed overnight activity, and a substation engineering workstation appeared active outside the approved maintenance window.
Download: remi_nuclear_ai_logic_package_sitrep_use_case.pdf