A recently disclosed weakness in the AVEVA PI to CONNECT Agent can leak proxy connection details — including proxied URLs and embedded credentials — via Windows event logs, and operators must treat this as an urgent secrets‑exposure incident: inventory affected hosts, purge or redact exposed logs, rotate any potentially compromised proxy credentials, and deploy the vendor remediation without delay. rview
The flaw stems from how the PI to CONNECT Agent records proxy configuration and connection attempts in its Windows event logs. Under certain configurations the agent writes full proxy URLs — in some cases containing cleartext credentials — into the PI to CONNECT event log. Because Windows event logs are readable by members of the built‑in Event Log Reader group (SID S-1-5-32-573) and by any account with equivalent privileges, an attacker who either holds those privileges or can obtain access to an account in that group can extract proxy endpoints and, where present, username
assword pairs. This simple exposure can enable unauthorized access to corporate proxy services and any systems reachable via those credentials.
This is not an abstring workstations and OT integration hosts that run AVEVA components are high‑value targets: they commonly store project files, network mappings, and credentials used to reach historians, cloud connectors, and vendor portals. A secrets leak from an engineering host can be leveraged for lateral movement, supply‑chain abuse, or direct access to cloud/third‑party services. The short remediation checklist — inventory, patch, purge, rotate — is simple in principle but operationally challenging in OT/ICS environments, which often restrict downtime and retain long‑lived backups.
What exactly is exposed and why xposed data
- Proxy URL — The event log entries can contain the proxy endpoint (scheme, host, port).
- Embedded credentials — If the proxy is configured using a URL that includes usernameassword (for example, https://user:pass@proxy.example.local:3128/), those credentials can appear in plaintext in the log messages.
- Authentication metadata — Timestamps, error messages, and correlation IDs that aid an attacker’s reconnaissance.
Even if passwords are not embedded in URLs, the URL and port alone can reveal internal proxy infrastructure that attackers can target for credential harvesting or service abuse. When credentials are present, the exposure becomes immediate and actionable: any party with access to the logs can authenticate to the proxy and potentially access internal or cloud resources.
Why Windows event logs are sensitive
Event logs are desiostics and operational detail. They are also a sensitive forensic repository: many administrative and system processes write secrets or tokens in error messages when software is misconfigured. On Windows hosts, read access to the standard event channels is commonly granted to users via group membership (Event Log Readers) or via helpdesk/service accounts. Thus, logging secrets in event text creates a low‑friction path for exposure — no privilege escalation is required if the attacker already controls or can trick an Event Log Reader account. Practically, any defect that writes credentials into logs multiplies risk across backups, SIEM archives, and log collectors unless those stores are themselves access‑restricted and encrypted.
Vendor guidance, fixes, and verifiability
AVEVA’s remediation path for th proxy details from logs in newly generated event records and to supply a fixed agent build. The vendor lists a fixed build baseline (PI to CONNECT Agent v2.5.2790 or later) and advises customers to upgrade to that version. Operators who have already used the affected agent versions are instructed to scan existing live logs and backups for exposed proxy connection details and to purge or redact them; rotating the proxy credentials that may have been logged is also recommended. Where direct verification is required, organizations should consult the vendor bulletin AVEVA‑2026‑003 and any national advisory (for example the CISA ICS advisory referenced in coordination notices).
Caveat: in operational practice, coordinated advisories and bulletin text can be posted in different places and may lag in third‑party aggregators. Before relying on a single feed for patch automation, confirm the fixed version and SHA‑256 checksums via the vendor’s official support portal or the CONNECT Data Services portal as part of an audited change control. The recommended fixed version in initial notices should be validated against vendor release notes prior to deployment.
Immediate operational actions (0–72 hours)
These are the high‑urgency, high‑impact steps to take immediately on any estate thaAgent.
- Inventory and prioritize
- Identify every host running PI to CONNECT Agent, including jump hosts, engineering workstations, and servers used for archival or backup of AVEVA logs. Treat engineering workstations and jump hosts as high priority.
- Restrict access to Event Log Reader privileges
- Audit membership of the Event Log Readers group (S‑1‑5‑32‑573) on each impacted host. Remove any non‑iately and tighten group membership to a minimal, trusted set (security/monitoring accounts only).
- Search for exposed proxy strings in logs and SIEM
- Hunt across:
- Local Windows event logs (Application, System, and any PI‑specific channels)
- SIEM/Log Archivups and exported .evtx files
- Look for string patterns such as "http://", "https://", "://", "proxy", and common credential separators like ":" and "@" inside URL contexts. If your logging platform supports regex, run queries to detect URLs with embedded credentials (for example, patterns matching ://[^:]+:[^@]+@).
- Purge or redact sensitive log entries
- Where logs clearly contain credentials, consider secure purge or selective redaction. Preserve forensic integrity by first exporting an encrypted forenste and access‑controlled) before removing the sensitive entries from production logs.
- If purging is operationally or legally constrained, isolate the logs and harden access controls immediately.
- Rotate the credentials
- For any proxy accounts that may have appeared in logs, rotate credentials immediately and remove the old credentials from any connection strings, configuration files, and credential stores. Update the agent configuration to use the new credential mechanism.
- Apply the vendor fix
- Schedule and test the vendor release (v2.5.2790 or later) in a controlled environment and roll out according to change control. If the environment cannot tolerate downtime, prioritize hosts exposed to the internet or used by contractors/third parties.
- Compensating network controls
- If patching will be delayed, enforce stricter network controls: restrict the agent host’s outbound access to trusted proxies, firewall the management plane, and place engineering woardened jump host with MFA.
Detection and hunting: concrete recipes for Windows teams
- Audit Event Log Reader membership via PowerShell:
- Get the S‑1‑5‑32‑573 group name and enumerate members on each host.
- Centralized approach: use a configuration mquery to list all machines where non‑standard accounts are members.
- Search local and archived .evtx logs for proxy URL patterns:
- Use Windows Event Log cmdlets or your SIEM to search for strings: "://", "proxy", "username=", "user=", "pass=", and "@".
- Example conceptual query (adapt to your SIEM): find events where the message contains '://:@' or 'proxy' and 'http'/'https'. (Avoid posting exact regexes for safety in public channels; adapt to your environment.)
- SIEM correlation rules:
- Alert on any access to proxy services from unexpected hosts or newly created service accounts shortly after log access events.
- Track the creation or export of .evtx files or archive operations touching PI/CONNECT event channels.
- Forensic steps if compromise suspected:
- Preserve full disk images of impacted hosts; capture memory and relevant process dumps where feasible.
- Export affected .evtx logs to an encrypted repository for offline analysis.
- Correlate with network logs to confirm any use of the leaked proxy credentials (proxy access logs, NAT logs, firewall logs).
These detection steps should be integrated into existing incident response playbooks and tuned to minimize false positives in complex OT/IT converged environments.
Longer‑term technical recommendations
- Remove plaintext credentials from configuration artifacts
- Never store passwords inline in URLs. Use tokenized credential stores, OS service accounts, or managed secrets (vaults) where possible.
- If a proxy requires explicit credentials, provision a least‑privilege service account scoped to only the necessary outbound destinations.
- Centralize secrets management
- Adopt an enterprise secret store that allows controlled access, rotation, and audited retrieval (HashiCorp Vault, Azure Key Vault, or equivalent). Configure agents to retrieve ephemeral or short‑lived credentials rather than persisting them in text files or URLs.
- Harden logging practices
- Apply a logging hygiene policy: redact or mask secrets at the source before emitting logs. Implement log sanitization middleware for services that format event messages.
- Ensure archival and SIEM pipelines encrypt at rest and employ strict ACLs, and that backups containing logs are included in incident response planning.
- Platform design changes
- Vendors should avoid writing full connection strings or embedded credentials into logs. Error messages can include non‑sensitive codes, timestamps, and correlation IDs while omitting secrets. Demand this as part of procurement and patch management conversations.
Operational risks, attack scenarios, and real‑world impact
An attacker with read access to the PI to CONNECT event log can:
- Use leaked proxy credentials to route requests through the organization’s proxy, potentially accessing internal resources, cloud APIs, or other services thatthat proxy.
- Exfiltrate data through the proxy or bypass network restrictions.
- Perform reconnaissance using the proxy to mask source IPs, complicating detection and IR.
- Reuse credentials on other services if passwords are reused across systems.
Because engineering systems integrate with controllers, historians, and often have privileged network access, a secrets leak can be the first step in a chain that leads from an innocuous log read to controller tampering. The ladder from log‑read → credentials → authenticated access → lateral movement is short if defenses are weak. These risk dynamics are discussed in AVEVA/CISA coordinated advisories which recommend defensive hardening and rapid remediation in OT contexts.
Critical analysis: strengths and gaps in vendor and community response
Strengths
- Coordinated disclosure gives operators a clear remediation path: inventory, patch, and rotate. This practical playbook aligns with established ICS incident response practices.
- The vendor acknowledged the issue and produced a fixed agent build, which reduces the window of exposure for operators who can apply updates quickly.
Gaps and risks
- Operational patch windows in OT environments are often very constrained. Many engineering stations and controllers cannot be rebooted on short notice without coordinated maintelengthens the time-sensitive period during which secrets must be protected by compensating controls.
- Public registries (NVD/CVE aggregators) and thirdag vendor bulletins or coordinated advisories. Relying only on automated NVD pulls can delay detection of whether a given installed version is vulnerable; cross‑verification with vendor release notes is essential.
- Forensic preservation vs. purge tension: operators must balance the need to retain logs for incidentoving sensitive entries to prevent further leakage. The recommended compromise is to export encrypted forensic copies before redaction or purge. This is operationally nuanced and often overlooked in rushed remediations.
Unverifiable or uncertain claims
- Some public summaries may listixed‑version mappings that are not immediately visible in every authoritative registry. Operators should treat such claims as provisional until confirmed by the vendor bulletin or coordinated authority. In our review, the recommended vendor remedial version was cited in advisories and coordination materials, but always verify the exact build vendor portal before rollout.
Practical checklist for Windows/OT administrators (actionable)
- Short term (within 24 hours)
- Run a domain‑wide inventory to list hosts with PI to CONNECT Agent installed.
- Audit Event Log Reader (S‑1‑5‑32‑573) group membership and remove non‑essential accounts.
- Hunt for proxy patterns in local / aggregated logs and export any hits to encrypted forensic stores.
- Next 72 hours
- Purge or redact logs that contain credentialsting encrypted copies for forensics.
- Rotate any proxy credentials that may have been exposed.
- Apply the vendor‑published fix (test then push to production per change control).
- Medium term (1–6 weeks)
- Migrate proxy credentials out of inline URLs into a managed secrets platform.
- Harden log generation: configure agents to redact sensitive parameters.
- Integrate engineering host logs into central SIEM with strict retention and access policies.
- Ongoing
- Maintain an inventory and a vulnerability management workflow that cross‑verifies vendor bulletins with national advisories.
- Exercise IR runbooks that include log redaction, and forensic preservation.
Conclusion
The PI to CONNECT Agent issue is a classic illustration of why logging hygiene and secrets management matter as much as code hardening. The vulnerability is both straightforward to exploit (if an attacker can read event logs) and deceptively dangerous because logs are replicated, archived, and widely accessible in many environments. Rapid, pragmatic action — inventory, restrict Event Log Reader privileges, hunt and purge exposed logs, rotate credentials, and apply the vendor fix — will materially reduce risk. Longer term, replace inline credentials with secrets management, enforce log sanitization, and demand that vendors avoid emitting secrets into diagnostic channels.
AVEVA’s coordinated remedy and the recommended operational playbook provide a clear path forward; however, the success of mitigation depends on disciplined patching, careful forensic handling of logs, and tighter control over who can read diagnostic data on engineering hosts. Treat pre‑patch artifacts as compromised until proven otherwise and prioritize the remediation of any host that is externally exposed or shared with third parties.
Source: CISA
AVEVA PI to CONNECT Agent | CISA