Domain-Join Accounts: A Quiet, Consistent Path to AD Compromise
Active directory domain-join accounts are routinely exposed during device buildouts and imaging, where their passwords are often stored in clear text across deployment steps and configuration stores. Discovered by Shelltrail, once an attacker gets credentials from anywhere on the internal network, they can create or rejoin computers to Active Directory and quietly inherit control over those new assets. By default, the account that joins a machine becomes its “creator,” granting read and change rights that can be elevated to full control and, ultimately, domain dominance. Even when teams remove broad read access at a higher level, Windows automatically restores key reads on each newly created computer object, keeping the door open. Microsoft only published clear, official guidance in August 2025 after years of conflicting practices, so many environments still carry risky defaults. In real incidents and assessments, this combination of exposure, default ownership, and inherited privileges makes domain-join accounts one of the most reliable paths from a single credential to widespread impact. The business result is an elevated likelihood of ransomware blast radius, long recovery windows, and regulatory/reporting fallout. Reducing this risk requires layered controls, not a one-time setting. First, stop ordinary users from creating machine accounts and limit join rights to a tightly scoped service account and specific organizational units; ensure a senior admin group is automatically recorded as the owner of every computer object. Remove domain-join credentials from deployment pipelines and vault them; if offline join is practical, prefer it to avoid passing passwords during imaging. Add targeted “deny” permissions that block the service account from reading legacy local-admin passwords on computers and from setting delegation entries that enable stealthy impersonation. Monitor continuously for high-value changes, who owns new computer objects, attempts to read stored local-admin passwords, and edits to delegation attributes, and alert on anomalies. Be aware that, even with these defenses, password reset rights can still be abused during directory replication delays, especially in multi-site estates when combined with certificate services. Treat domain-join governance as an ongoing program with periodic audits and scripted corrections, not a checkbox; the goal is straightforward: shrink exposure, prevent privilege inheritance, and cut off the fast lanes to domain control.
EDR-Redir: Filesystem Redirection That Defeats Endpoint Defenses
New EDR-Redir leverages built-in Windows filesystem features to redirect an endpoint protection product away from its legitimate executable and data folders, enabling an attacker to control or disable the protection without touching the kernel. The technique uses the Bind Filter driver (bindflt[.]sys) to create virtual path mappings that make one folder appear as another, and it falls back to the Cloud Filter API (cldflt[.]sys) to register a sync root when defenders resist the basic bind approach. An actor with administrative capabilities on the host can create these mappings and either point an EDR’s working directory to attacker-controlled content or render its folder unreachable, and the Cloud Filter approach can persist after reboot. The practical outcomes include DLL hijacking, injection of attacker-supplied binaries into the EDR for execution, service startup failures, and broad loss of endpoint telemetry. Tests reported disruption across multiple commercial products; some required the cloud-filter method to be neutralized, while others were affected directly by bind link redirection. Because the method operates entirely in user mode, traditional kernel-level protections and many file-system guards do not prevent it. Defending against this vector requires coordinated vendor and operational changes across the enterprise security stack. EDR vendors must treat their installation and runtime folders as hardened assets, validate the origin and integrity of any filesystem namespace registrations, and add detection for abnormal use of the bind_link and sync_root APIs. Operators should restrict who can perform administrative filesystem namespace actions through strict role separation, platform hardening, and just-in-time elevation for maintenance tasks. Monitoring must include events tied to bindflt.sys and cldflt.sys activity, unexpected changes to an EDR’s on-disk footprint, and loss of EDR process health; network- and cloud-level telemetry should be used to detect protection gaps when host signals disappear. Recovery playbooks should be documented and rehearsed for restoring protection on impacted hosts, and organizations should prioritize layered defenses that do not rely solely on a single endpoint agent for detection and response.
Shadow Escape: A Zero-Click AI Data Exfiltration Attack
Operant AI’s security research team uncovered Shadow Escape, a zero-click attack that abuses the Model Context Protocol (MCP), the framework used by AI assistants such as ChatGPT, Claude, and Gemini to connect with enterprise systems. Unlike phishing or malware-based breaches, Shadow Escape operates fully within trusted system boundaries. It begins when an employee uploads an ordinary document, such as a PDF manual, into their AI assistant. Hidden instructions embedded in the file activate once ingested by the AI, silently instructing the assistant to query internal systems via its MCP connections. Because the AI has legitimate access to CRMs, cloud drives, and databases, it autonomously discovers and aggregates sensitive data (Social Security numbers, banking details, medical identifiers, and payroll records) without any malicious code execution or user interaction. The assistant then exfiltrates the compiled data to a remote endpoint disguised as a routine performance log upload. From the employee’s and the organization’s perspective, everything appears normal; the traffic is encrypted, authenticated, and originates from a trusted identity within their own network. The implications are severe. Shadow Escape reveals how AI agents can become insider threats when operating with broad MCP privileges and without internal behavioral oversight. Because the attack exploits default configurations and standard tool permissions, it affects industries and platforms across the board, potentially exposing trillions of records from healthcare, finance, legal, and critical infrastructure systems. Defending against this requires rethinking how enterprises govern and monitor AI systems. Organizations must treat AI assistants as privileged software agents subject to identity governance, least-privilege access, and runtime monitoring. All documents entering AI environments should be scanned for embedded prompt instructions or steganographic payloads, and MCP traffic should be continuously audited for abnormal tool invocation or external calls. Perimeter defenses cannot protect against breaches that occur inside trusted AI workflows. Enterprises must implement AI-native security controls that can inspect context, validate tool use, and enforce real-time policy before sensitive data escapes the organization.
