Skip to main content

Generate a water treatment SITREP on the spot and identify the size and scope of the adversarial cyberattack in minutes.

AI doesn’t just analyze evidence—it decides how to analyze it. RemiFetch adapts forensic methodology in real time based on detected patterns, automatically applying the right techniques—correlation, artifact extraction, behavioral analysis, and timeline reconstruction—to match the investigation.

By linking signals across systems and evolving its approach as new evidence emerges, AI reveals relationships and attack paths that static workflows cannot. This enables deeper insight, faster investigations, and defensible, evidence-driven conclusions.

REMI supports both OT & IT event logs

REMI analyzes evidence from both enterprise incident response and water treatment OT/IT environments, including endpoint activity, VPN and identity records, firewall logs, SCADA activity, HMI actions, PLC/RTU events, historian data, alarms, vendor access, and maintenance records.

By connecting these records across IT and water operations, REMI helps investigators see whether a cyber incident stayed inside enterprise systems or moved toward treatment, pumping, chemical-feed, distribution, or water-quality 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 Events

Unusual sign-ins
New locations, impossible travel, off-hours access, failed MFA, token reuse, or abnormal login patterns.
Endpoint activity
Unexpected processes, scripts, malware paths, dropped files, persistence, hashes, and device telemetry.
Network movement
Internal traffic, external callbacks, DNS activity, VPN sessions, ports, protocols, and lateral movement paths.
Privilege and access changes
Admin role changes, permission updates, group membership changes, service accounts, and token activity.
Cloud and SaaS activity
Storage access, mailbox activity, API calls, app credentials, file sharing, downloads, and data movement.
Data exfiltration indicators
Large transfers, unusual downloads, external sharing, archive creation, USB activity, and abnormal outbound traffic.
Insider threat indicators
After-hours access, unusual file access, policy bypasses, removable media use, deleted logs, or access outside job role.
Inside assistance indicators
Shared credentials, approved access used at abnormal times, suspicious vendor coordination, unlocked remote tools, or access enabled before activity.

OT Events

SCADA and HMI logs
Operator screens, commands, acknowledgments, setpoint changes, overrides, and control-room activity across treatment and distribution systems.
PLC and RTU event logs
Controller events, logic edits, downloads, forced values, mode changes, pump controls, valve activity, and device status records.
Historian and water process data
Trend values, tag changes, flow, pressure, tank levels, reservoir levels, pump status, chemical-feed rates, and process-state records.
Alarm and event records
Alarm floods, silenced alarms, acknowledgments, resets, threshold changes, quiet periods, and abnormal treatment or distribution states.
Engineering workstation logs
Project file changes, HMI edits, PLC/RTU tool activity, controller uploads/downloads, scripts, diagnostics, and remote sessions.
Vendor maintenance access logs
VPN sessions, jump hosts, maintenance accounts, vendor diagnostics, source IPs, approved work windows, and support activity.
Water quality records
Chlorine, pH, turbidity, fluoride, residuals, sample records, sensor readings, threshold violations, and lab or field-test records.
Distribution system records
Reservoirs, valves, pressure zones, booster stations, lift stations, storage tanks, downstream effects, and service-area impact records.

REMI IS TRAINED TO RECOGNIZE ADVANCED ADVERSARIAL CYBER BEHAVIORS IN water treatment ENVIRONMENTS

REMI analyzes evidence from both enterprise incident response and water treatment OT/IT environments, including endpoint activity, VPN and identity records, firewall logs, SCADA activity, HMI actions, PLC/RTU events, historian data, alarms, vendor access, and maintenance records.

By connecting these records across IT and water operations, REMI helps investigators see whether a cyber incident stayed inside enterprise systems or moved toward treatment, pumping, chemical-feed, distribution, or water-quality 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.

How REMI See's It

Triggered behavior: New-source VPN login
Finding: REMI identified c.arden logging in from 203.0.113.44 at 1:14:08 AM on July 13, 2026 in the IT VPN authentication logs.
Triggered behavior: Internal access immediately after VPN authentication
Finding: REMI identified access to 10.77.18.25 at 1:14:21 AM on July 13, 2026 in the IT firewall flow records.
Triggered behavior: Off-hours operations desktop activity
Finding: REMI identified activity on OPS-DT-07 at 1:15:04 AM on July 13, 2026 in the IT endpoint and Windows event logs.
Triggered behavior: Engineering workstation activity outside the maintenance window
Finding: REMI identified activity on WATER-ENG-04 at 1:17:16 AM on July 13, 2026 in the engineering workstation logs.
Triggered behavior: Water operations records active outside expected workflow
Finding: REMI identified historian, pump-station, and chemical-feed support records at 1:21:22 AM on July 13, 2026 in the OT historian and SCADA support logs.

How REMI Explains It

REMI identified the first flagged behaviors in the water OT/IT evidence when the VPN, identity, firewall, historian, and operations records were reviewed together. The activity showed a remote-access session by c.arden from 203.0.113.44, followed by internal access to 10.77.18.25 and later movement toward systems used to support water operations.

The detection phase did not decide the full cause of the incident. It established the first evidence-backed view of what happened: which accounts appeared, which systems were touched, which operational records did not line up with the expected activity window, and which records needed to move into correlation for the incident story to form.

What REMI is Looking For

Chemical dosing changes — chlorine, pH, fluoride, polymer, feed-rate, or dosing changes outside expected patterns.
Pump and lift anomalies — abnormal starts, stops, tank levels, pressure shifts, or flow changes.
PLC and RTU activity — logic edits, controller downloads, setpoint changes, forced values, or mode changes.
HMI and operator actions — unusual commands, overrides, screen access, or alarm acknowledgments.
Historian and alarm gaps — missing telemetry, alarm floods, quiet periods, resets, or altered trends.
Vendor remote access — VPN sessions, jump hosts, diagnostics, maintenance accounts, and source IPs.
Water quality indicators — turbidity, residuals, sensor readings, sample records, or threshold violations.
Distribution impact — reservoirs, valves, pressure zones, booster stations, storage tanks, or downstream effects.

CORRELATION IS WHERE THE INCIDENT STORY STARTS TO FORM

Flagged Behaviors Connect to Networks, Devices, and User Accounts. That’s Where the Story Starts to surface.

After flagged behaviors are detected, REMI correlates the records that share evidentiary links: accounts, devices, IP addresses, timestamps, commands, alarms, configuration changes, vendor access, and affected systems. This is where isolated findings begin forming a structured incident story.

Correlation shows investigators what connected to what, where activity began, how it moved, which systems were touched, and what remains unproven. It does not force conclusions beyond the evidence. It builds the evidence-backed storyline that Analysis can explain and the SITREP can turn into action.

REMI connects scattered flagged behaviors into the first clear view of how malware activity connects to operational disruption.

How REMI See's It

Stolen laptop → VPN access
REMI connected WATER-LT-18 to c.arden VPN activity from 203.0.113.44, linking device history to the remote-access event.
VPN access → business network
The session reached 10.77.18.25 inside the water utility business network 13 seconds after login.
Business network → operations desktop
The same session moved from 10.77.18.25 to OPS-DT-07 43 seconds later.
Operations desktop → engineering support
OPS-DT-07 connected toward WATER-ENG-04, crossing from business access into water engineering support.
Engineering support → operations records
WATER-ENG-04 aligned with historian, pump-station, and chemical-feed records, completing the evidence path.

How REMI Explains It

How REMI Explains the Connections

REMI connected the stolen-laptop record, VPN login, source IP address, account activity, and internal network traffic into one evidence path. The first connection showed that WATER-LT-18 was tied to c.arden, and that the same account was used to establish a VPN session from 203.0.113.44 one week after the laptop had been reported stolen.

The second connection showed that the VPN session did not stop at authentication. Within 13 seconds, the session reached 10.77.18.25 inside the water utility business network. REMI then connected that internal destination to later activity on OPS-DT-07, showing that the remote session moved from external access into a usable operations desktop environment.

From there, REMI connected OPS-DT-07 to traffic toward WATER-ENG-04 inside the water engineering support environment. That mattered because WATER-ENG-04 was not just another workstation. It was tied to engineering support records used for treatment and distribution operations.

The final connection linked WATER-ENG-04 to historian, pump-station, and chemical-feed support records. That gave investigators a clear path from stolen device history, to VPN access, to business-network entry, to operations desktop activity, to engineering support, and finally to water operations records.

Analysis Explains How the Attack Happened

REMI turns correlated evidence into the supported explanation of what allowed the incident to occur.

After Correlation links the flagged behaviors, REMI Analysis examines the evidence path to explain how the incident unfolded. It reviews access records, user activity, vendor sessions, system events, commands, configuration changes, alarms, affected assets, and supporting source records to determine what conditions allowed the activity to progress.

Analysis shows how access was achieved, how the activity moved, which systems were affected, what controls failed or were bypassed, what evidence supports the explanation, and what remains unresolved.

How REMI Analysis Explains the Remote VPN Path

Analysis determined that the incident was allowed to progress because vendor_maint_02 successfully established a remote VPN session from 203.0.113.44 and reached the office network at 192.165.43.18. From there, the same account and session window aligned with movement toward the engineering network, where ENG-WS-04 and related control-support records appeared in the evidence.

REMI's Assessment

The alarm bells did not ring early because the activity used a valid account and moved through systems that already had trusted access paths between the office and engineering environments. The VPN login, office-network connection, and later engineering-network traffic were each visible in separate records, but they did not become a clear incident story until REMI connected them across account, IP address, timestamp, destination system, and network path.

RENI Thinks Like an Investigator

Access path — how the account entered and which systems it reached first.
Movement path — how activity moved from office systems toward engineering or OT assets.
Control gaps — which safeguards, approvals, segmentation, or monitoring failed to stop it.
Missed signals — why separate alerts, logs, or events did not become an obvious incident sooner.
Operational impact — which systems, processes, records, or service areas were affected.
Evidence support — which source records prove each part of the explanation.

REMI Generates the “What Now?” Response Plan

The “What Now?” plan is where REMI turns the investigation into action. After identifying what happened and which systems, accounts, files, processes, and connections were involved, REMI shows investigators what to do next.

It separates confirmed issues from open questions, identifies when more data is needed, lists the questions to ask IT or system owners, and prioritizes which artifacts should be preserved, sandboxed, removed, or remediated.

SAMPLE REMI CYBER SITREP EXCERPT

Malware Path Removal

1 Preserve VPN evidence first
Preserve VPN logs, MFA records, firewall flows, EDR telemetry, and session details for vendor_maint_02 before deleting files or disabling accounts.
2 Isolate systems reached from VPN
Isolate 192.165.43.18 and ENG-WS-04 if logs show malware execution, callbacks, script activity, or movement toward engineering systems.
3 Remove staged scripts and dropped files
After preservation, remove C:\Temp\stage.ps1, C:\ProgramData\svc-loader.bat, and C:\Users\Public\update-task.vbs if tied to the VPN session.
4 Disable persistence
Remove rogue services, startup entries, registry run keys, scheduled tasks, and unauthorized remote tools created during or after the VPN session.
5 Block related indicators
Block confirmed hashes, file paths, command patterns, callback domains, and source IPs connected to the VPN-to-engineering malware path.
6 Reset exposed access
Disable or reset vendor_maint_02, rotate exposed credentials, revoke active tokens, review MFA settings, and confirm the vendor account is still required.
7 Verify cleanup
Confirm no re-execution, file re-creation, outbound callback traffic, new scheduled tasks, or repeat VPN activity appears after containment.

What’s Included in the SITREP

Detection report — flagged water OT/IT behaviors, including abnormal SCADA, HMI, PLC/RTU, alarm, pump, dosing, vendor, identity, and security activity.
Correlation analysis narrative — explains how flagged behaviors connect across accounts, devices, IPs, sessions, timestamps, commands, alarms, vendor access, and affected systems.
Correlation analysis workbook — structured evidence tables showing linked events, shared indicators, source records, timelines, systems, and unresolved connection gaps.
Analysis narrative — explains how the incident happened, what allowed it to progress, which systems were affected, and what evidence supports the findings.
Analysis workbook — detailed analysis tables for access paths, affected assets, operational impact, control gaps, supporting evidence, confidence, and follow-up data needs.

REMI turns findings into immediate action: what to ask, what to collect, what to preserve, what to sandbox, and what to remediate.

REMI separates what the evidence proves from what still needs confirmation.

Unresolved questions are not guesses or weaknesses in the report. They are the specific answer gaps REMI identifies when the available evidence does not fully prove part of the story. Instead of forcing a conclusion, REMI shows investigators exactly what is known, what remains open, and which records or people can close the gap.

Example:

REMI can show that vendor_maint_02 logged in through VPN, reached 192.165.43.18, and later aligned with traffic toward the engineering network. If the case data does not include the maintenance ticket, MFA approval record, vendor assignment, or asset-owner confirmation, REMI flags those as unresolved questions and asks for that specific data before labeling the activity as approved work, credential misuse, or unauthorized movement.

Was the VPN login approved? Get VPN session logs, maintenance tickets, vendor work orders, and change approvals to confirm whether vendor_maint_02 was expected.
Who used the VPN account? Get identity records, MFA approval details, vendor assignment records, and account-owner history to identify who was behind the session.
Was the source location normal? Get VPN source-IP history, geolocation records, prior vendor access logs, and remote-access baselines for 203.0.113.44.
What did the VPN reach first? Get firewall logs, VPN tunnel records, DHCP/DNS logs, and endpoint telemetry to identify the first internal systems reached.
Why did it reach the office network? Get routing records, access-control rules, firewall policy logs, and asset-owner details for 192.165.43.18.
How did it move toward engineering? Get jump-host logs, firewall flows, EDR process activity, authentication logs, and engineering-network access records.
Which alerts fired or failed? Get firewall, EDR, identity, VPN, SIEM, and segmentation-alert records from the same session window.
Was malware staged after access? Get endpoint file activity, process execution logs, script history, command history, hashes, and sandboxable artifacts from affected hosts.
What evidence closes the gap? Get missing VPN, MFA, firewall, EDR, ticketing, asset-owner, and vendor records needed to confirm the full access path.

View Our Use Cases

At 6:10 AM, the morning operator at a water treatment facility noticed that several historian values from the north pump station looked out of sequence. Nothing was fully down, but the pattern was wrong: a pump showed a short start-stop cycle that did not match the shift log, and an engineering workstation appeared to have been active overnight even though no overnight maintenance was scheduled.


  • Vendor-Infected Firmware Update at Pump Station

At 7:35 AM, the distribution supervisor at North Valley Water Treatment Plant noticed that the east pressure zone was cycling more than expected. Nothing had failed, but the pattern was wrong: the East Ridge pump station showed repeated short starts, the pressure trend dipped during normal demand, and the local controller reported a firmware version that did not match the maintenance record


  • AI-Spawned Malware Controllers and Vendor OT Setting Changes

At 4:42 AM, the treatment supervisor at North Valley Water Treatment Plant noticed that chlorine feed values from the south chemical room were drifting outside the normal morning range. The plant was still operating, but the pattern was wrong: a dosing value had changed without a matching operator note, and the historian showed a short burst of controller activity during a window when no chemical-feed adjustment was scheduled.