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.