Settra Blinder
IOCs & detection

Settra Blinder signals a new generation of security evasion

• Accenture Cyber Intelligence recently identified a new toolkit for blinding endpoint detection and response (EDR), which is designed to disable, evade, and bypass endpoint security products and Windows-native security controls. We are tracking this tool as Settra Blinder.
• Settra Blinder is engineered to undermine the visibility defenders rely on to detect and respond to attacks. Its design philosophy emphasizes persistence through invisibility rather than speed or volume.
• Accenture Cyber Intelligence has developed detection content and analytical techniques to help organizations identify this emerging threat and strengthen resilience against similar security-evasion tools.

Accenture Cyber Intelligence obtained and reverse engineered both the ransomware payload and the defensive evasion tooling deployed by the threat group Settra. Though a relatively recent entrant to the ransomware ecosystem, Settra has already demonstrated sophistication comparable to more established adversaries. In this incident, it was not the ransomware, but the group’s sophisticated, dedicated EDR bypass framework that grabbed our attention.

Put simply, Settra Blinder is not just attempting to avoid detection. It is designed to systematically erode the visibility defenders depend upon, creating what amounts to a digital blind spot inside a compromised environment.

Settra Blinder represents a significant evolution in security-evasion tooling. The framework leverages vulnerable but legitimate kernel drivers to gain deep access to Windows systems, allowing it to manipulate critical operating system structures and interfere with both native security features and endpoint detection technologies.

From this privileged position, the toolkit can disable security monitoring mechanisms, terminate security-related processes and services, bypass protected processes, and suppress security telemetry. It also employs parent process spoofing to disguise malicious activity as legitimate system behavior.

Perhaps most concerning is Settra Blinder's focus on two of Windows' most important visibility mechanisms: Event Tracing for Windows (ETW), the primary channel through which Windows reports system activity to security tools, and the Antimalware Scan Interface (AMSI), which is a built-in inspection layer that lets security software scan content before it’s executed. By disrupting these technologies, the malware can interfere with the telemetry and inspection capabilities many security tools rely upon to identify malicious activity.

The toolkit also incorporates extensive anti-analysis, anti-debugging, and anti-sandbox techniques designed to detect when researchers or automated security systems are attempting to inspect it.

The result is a compromised endpoint where visibility is degraded, security controls are weakened, and malicious activity becomes substantially more difficult to detect, investigate, and contain.

Settra Blinder is a 64-bit Windows PE command-line tool designed to disable Endpoint Detection and Response protections via kernel-level attack techniques.

Settra Blinder demonstrates sophisticated kernel-level attack capabilities across several technique categories:

Settra Blinder highlights how adversaries are increasingly targeting the technologies that provide security visibility before conducting ransomware, extortion, and lateral movement operations. As such, it is becoming more important for defenders to assume adversaries will attempt to disable visibility before launching their primary objectives. As cybercriminal operations continue to professionalize, security teams need to be prepared to detect attacks, but also to detect attacks on the tools designed to detect them.

Accenture Cyber Intelligence suggests:

• Keep your systems fully patched. Settra Blinder exploits known weaknesses in legitimate software drivers, so timely patching can reduce exposure to known vulnerable drivers.
• Enable Windows security features that control which software can run at the deepest levels of your system. Features like Secure Boot and appropriately configured driver controls may help restrict unauthorized or vulnerable drivers.
• Limit who can change core system functions. The more tightly you control access to sensitive system operations, the harder it could become for tools like Settra Blinder to take hold.
• Make sure your logging covers system-level activity, not just application events. Settra Blinder specifically targets the mechanisms that generate security alerts, so deeper logging could aid in spotting something interfering with your defenses.
• Use our detection logic to find Settra Blinder in your environment. Accenture Cyber Intelligence has published a Yara rule on our GitHub that security teams can deploy to help identify this threat: https://accenture.github.io/cyber-intelligence/settra-blinder/

APEX Labs recommends the following measures to mitigate the risk posed by Settra Blinder:

• Implement and maintain updated kernel patches to prevent exploitation of known vulnerable drivers.
• Deploy Driver Signature Enforcement (DSE) and Secure Boot to prevent unsigned or vulnerable driver loading.
• Implement strict access controls to prevent unauthorized access to kernel interfaces and system management functions.
• Keep operating system and kernel patches updated to mitigate vulnerabilities that could be exploited via BYOVD techniques.
• Enable system logging including kernel-level events, driver activities, and security configuration changes to support detection and forensic investigation.

The following YARA rule detects Settra Blinder based on CLI argument strings, vulnerable driver device paths, kernel callback routine names, and runtime log strings. Security teams are encouraged to deploy this rule across endpoint and file-scanning solutions.

rule settra_blinder
{
  meta:
    description = "Detects EDR Blinder"
    author      = "Accenture Cyber Intelligence"
    date        = "2026-07-10"
    hash        = "32d6657506d861c206a5c47c62bba4c82231d4a12f12d258908a46f7e5f637bc"

  strings:
    // CLI argument strings
    $args1 = "--asrdrv" ascii wide
    $args2 = "--ppid" ascii wide
    $args3 = "--kill-loop" ascii wide
    $args4 = "--stpm" ascii wide

    // Vulnerable driver device paths (BYOVD targets)
    $drvdev1 = "\\\\.\\RTCore64" ascii wide
    $drvdev2 = "\\\\.\\AsrDrv101" ascii wide
    $drvdev3 = "\\\\.\\gdrv" ascii wide
    $drvdev4 = "\\\\.\\HpPortIox64" ascii wide
    $drvdev5 = "\\\\.\\PhysMem" ascii wide
    $drvdev6 = "\\\\.\\WinRing0_1_2_0" ascii wide
    $drvdev7 = "\\\\.\\STProcessMonitorDriver" ascii wide

    // Kernel callback routine names
    $krlstruct1 = "PsSetCreateProcessNotifyRoutine" ascii wide
    $krlstruct2 = "PsSetCreateThreadNotifyRoutine" ascii wide
    $krlstruct3 = "PsSetLoadImageNotifyRoutineEx" ascii wide
    $krlstruct4 = "PsSetLoadImageNotifyRoutine" ascii wide
    $krlstruct5 = "PsCreateProcess" ascii wide
    $krlstruct6 = "PsCreateThread" ascii wide
    $krlstruct7 = "PsLoadImage" ascii wide
    $krlstruct8 = "ObProcess" ascii wide
    $krlstruct9 = "ObThread" ascii wide

    // Runtime log strings
    $log1 = "[*] === ETW Threat Intelligence Provider Bypass ===" ascii wide
    $log2 = "[*] === PPL Bypass ===" ascii wide
    $log3 = "[*] === ETW + AMSI self-patch ===" ascii wide
    $log4 = "[*] === Minifilter Scan ===" ascii wide

  condition:
    3 of ($args*) and 4 of ($drvdev*) and 5 of ($krlstruct*) and 2 of ($log*)
}

The condition requires a minimum threshold across all four string groups — reducing false positives while tolerating minor sample variation. Any binary matching 3+ CLI args, 4+ driver paths, 5+ kernel callback names, and 2+ log strings is a high-confidence match.