🛡️ InfoSec Blue Team Briefing

📰 Articles Covered

• Implications of Recent CISA Disclosures on Iranian OT Targeting - Dataminr 🔍 Show Kagi Synopsis
  Based on recent CISA disclosures, the Iran-linked threat actor group "CyberAv3ngers"—associated with the IRGC Cyber-Electronic Command—has significantly escalated its campaign targeting industrial control systems.
  
  ### What Happened
  The group has expanded its operational technology (OT) targeting scope. While initially focused on Rockwell Automation programmable logic controllers (PLCs), updated reporting confirms they have extended their reach to include Schneider Electric and Siemens devices. Most critically, the campaign has evolved from simple process disruption to the active retrieval of project files and the uploading of malicious project files to compromised PLCs.
  
  ### Who Is Affected
  The campaign targets critical infrastructure entities, with identified victims in:
  * Water and wastewater sectors
  * Energy facilities
  * Government facilities
  
  ### Security Implications
  This shift toward process and safety manipulation represents a severe escalation in risk. By overriding instruction sets responsible for maintaining safe operating parameters, the attackers threaten:
  * **Loss of process integrity:** Undermining the reliability of control systems.
  * **Physical destruction:** Potential for damage to equipment or entire processes.
  * **Physical harm:** Risks to personnel safety within impacted facilities.
  * **Geopolitical tension:** The activity is viewed as a clear escalation in the targeting of civilian infrastructure within the context of the US-Iran conflict.
  
  ### Technical Details
  * **Malicious Logic:** Analysis of the uploaded project files reveals they retain necessary downstream ladder logic while inserting instructions that override critical safety parameters.
  * **Access Methods:** While specific entry vectors are unconfirmed, the targeted devices are known to have historical authentication bypass vulnerabilities that could be exploited to reach internet-exposed assets, including:
  * **Schneider Electric:** Vulnerable to CVE-2021-22779 (ModiPwn).
  * **Siemens SIMATIC:** Vulnerable to CVE-2022-38465 (involving hard-coded cryptographic keys).
  * **General:** Older vulnerabilities such as CVE-2021-22681.
  
  ### What Defenders Should Know
  Defenders are urged to adopt rigorous security measures to protect critical assets:
  * **Eliminate Internet Exposure:** OT devices, particularly PLCs, must never be directly accessible from the open internet. If remote access is required, organizations must use secure, robust architectural designs like VPNs or jump hosts.
  * **Vulnerability Management:** Prioritize patching known vulnerabilities, even if they are not explicitly linked to the current activity. If patching is delayed, compensating controls and enhanced monitoring are mandatory.
  * **Credential Hygiene:** Remove all default or factory-set authentication credentials immediately.
  * **Logic Integrity:** Regularly capture and audit critical ladder logic to identify unauthorized changes.
  * **Physical Security:** Where possible, utilize physical switches to keep devices in "run" mode, which restricts the ability to perform unauthorized logic updates.
  
  ***
  
  *Source:*
  *【1】*
• A new ETSI standard could rewrite the memory-safety debate - CHERI Alliance 🔍 Show Kagi Synopsis
  The European Telecommunications Standards Institute (ETSI) has introduced a new draft standard, **TS 104 198**, which establishes a comprehensive framework for defining and evaluating memory-safety requirements. This standard is significant because it aims to provide a standardized language for the industry to move beyond vague claims of "memory safety" toward measurable, incremental security improvements 【1】.
  
  ### What Happened
  ETSI has released a draft technical specification that categorizes memory safety into distinct properties and maturity levels. By defining what it means for a system to be "memory safe" in a rigorous, standardized way, the organization seeks to harmonize the fragmented landscape of memory-safety tools and techniques, creating a common benchmark for both software and hardware implementations 【1】.
  
  ### Who Is Affected
  * **Software Developers:** Those working in memory-unsafe languages (e.g., C/C++) or memory-safe languages (e.g., Rust, Java, Go, Erlang) can use this framework to benchmark their security posture.
  * **Hardware Manufacturers:** Vendors developing security-focused hardware, such as CHERI, Arm MTE, and PAC, will be directly influenced by how their technologies are categorized under this standard.
  * **Security Practitioners and Organizations:** Enterprises and government bodies can leverage the standard to define security requirements, evaluate vendor compliance, and plan long-term security roadmaps 【1】.
  
  ### Security Implications
  The standard acknowledges that absolute memory safety is rarely achieved overnight. By establishing five incremental assurance levels, it allows organizations to transition from weak security guarantees to robust protections. It specifically recognizes that combining mature hardware protection mechanisms—such as CHERI—with appropriate software stacks can achieve the highest (Level 4) assurance, providing a clear path for reducing vulnerabilities like buffer overflows and temporal memory errors 【1】.
  
  ### Technical Details
  The standard evaluates systems based on seven core memory-safety properties and a multi-level enforcement framework:
  * **Memory Safety Properties:** Reference safety, spatial safety, temporal safety, initialization safety, finalization safety, concurrency-safe memory safety, and type-safe memory safety.
  * **Enforcement:** The framework categorizes how these properties are enforced, with CHERI frequently cited as a reference model for managing capability permissions, provenance, and reference integrity 【1】.
  
  ### What Defenders Should Know
  * **Vendor Neutrality:** The framework is designed to be hardware- and language-agnostic, ensuring it remains relevant across diverse tech stacks.
  * **Quantifiable Roadmaps:** Defenders can use this standard to map their current security posture, identify gaps, and create realistic, actionable roadmaps for improving memory safety.
  * **Strategic Utility:** Rather than just a compliance checkbox, the document acts as a guide to making informed decisions about technology integration and prioritizing security investments based on verified assurance levels 【1】.
• ADR: ADR secures enterprise AI agents through observability, security benchmarking, and threat detection. Deployed at Uber. - Uber 🔍 Show Kagi Synopsis
  The information provided accurately captures the core components of the Uber ADR (Agentic AI Detection and Response) project as described in their open-source repository.
  
  To provide further clarity on the framework for defenders, here is a structured summary of the system's capabilities:
  
  ### ADR Framework Overview
  
  | Component | Function | Key Features |
  | :--- | :--- | :--- |
  | **ADR Sensor** | Observability | Captures agent intent, tool usage, and execution traces across multiple OS platforms and AI coding tools. |
  | **ADR-Bench** | Security Testing | Contains 300+ tasks, 133 MCP (Model Context Protocol) servers, and coverage for all 17 documented agent attack techniques. |
  | **ADR Detector** | Threat Detection | Employs a two-tier architecture: high-recall triage followed by deeper agentic reasoning for suspicious sessions. |
  
  ### Summary for Security Teams
  
  * **Deployment Context:** ADR is not just a theoretical framework; it is currently actively used in production at Uber to secure both internal employee-facing AI (e.g., coding assistants) and external customer-facing support agents.
  * **Defensive Scope:** The system aims to mitigate risks associated with AI agents performing unintended or malicious actions, such as those initiated via prompt injection or compromised agent workflows.
  * **Operational Note:** The current open-source release provides the tooling for observability, benchmarking, and detection. As noted, the **ADR Prevention** component (which would actively stop unsafe actions) and the **ADR Explorer** engine (used for pre-deployment red teaming) are not included in this release.
  * **Research Safety:** The synthetic data fixtures (e.g., fake credentials and emulated environments) found in the `Detection/` directory are designed specifically for defensive security research and testing purposes.
  
  For further investigation, teams can explore the **ADR-Bench** components to test their own agentic security postures against the 17 identified attack techniques or utilize the **ADR Sensor** to begin gathering telemetry on agent activity within their specific enterprise environments.
• Apple Screen Sharing Pre-Auth RCE (macOS ≤ 26.5) - bl4sty 🔍 Show Kagi Synopsis
  This article details a critical pre-authentication remote code execution (RCE) vulnerability in Apple’s `screensharingd` daemon, allowing unauthenticated attackers to gain root-level file access.
  
  ### Executive Summary
  A flaw in the Secure Remote Password (SRP) authentication implementation allows an attacker to bypass authentication entirely. By sending a specially crafted SRP frame, an attacker can trick the daemon into entering an authenticated state without credentials, granting them root privileges to read and write files on the target system.
  
  ### Affected Systems
  * **Software:** macOS version 26.5 (Tahoe) and earlier, specifically systems where Screen Sharing is enabled.
  * **Protocol:** Apple Screen Sharing (RFB 003.889), specifically security type 36.
  * **Resolution:** Patched in macOS 26.6, released on July 27, 2026.
  
  ### Technical Breakdown
  The vulnerability originates from inadequate frame-length validation within the `screensharingd` daemon:
  * **The Flaw:** When the daemon processes an SRP frame with a length of 32,768 bytes or greater (triggering a bit at position 15 or higher), the error-handling logic fails.
  * **The Bypass:** Instead of dropping the malformed connection, the code returns a status code of zero, which the system misinterprets as "authentication successful."
  * **The Impact:** This skips the entire security stack—including cipher negotiation and session encryption—leaving the connection in an unencrypted state. The attacker then gains access to the RFB (Remote Framebuffer) message loop, which includes an Apple-specific file-transfer protocol (`0x22`) executing with root privileges.
  
  ### Security Implications
  * **Authentication Bypass:** Access is granted without any username or password verification.
  * **Privilege Level:** The attacker operates with root privileges.
  * **Effect of SIP:**
  * **With SIP Enabled:** System Integrity Protection provides a layer of defense by blocking modifications to sensitive paths (e.g., `/System`). However, attackers can still compromise systems by targeting unprotected directories such as `/etc/sudoers.d/` or `/etc/zshenv`.
  * **With SIP Disabled:** The system is highly vulnerable to immediate full code execution, such as through crontab injection, which can be achieved in under a minute.
  
  ### Guidance for Defenders
  * **Prioritize Patching:** Immediately update all affected systems to macOS 26.6.
  * **Reduce Attack Surface:** If updating is not immediately feasible, disable the Screen Sharing feature via System Settings.
  * **Enforce Hardening:** Ensure System Integrity Protection (`csrutil`) remains enabled across the enterprise.
  * **Incident Response:** Any macOS system that had Screen Sharing enabled while SIP was disabled during the period this vulnerability was unpatched should be treated as potentially compromised; forensic review is strongly recommended.