Instead of playing whack-a-mole with individual apps in the portal, I developed a workflow that starts with a deep hunt in Defender and ends with an automated “kill” via Intune.

The Problem: Shadow IT and Defender Alarms

I’ve seen it time and again: Defender’s vulnerability management flags 50 devices with an outdated version of GIMP or a random browser like Yandex. These aren’t apps we deployed; they are “zombie” software—apps that shouldn’t be there, aren’t getting patches, and create massive operational noise in our security reports.

Step 1: Hunting at Scale with KQL

I don’t waste time browsing the Defender portal app-by-app. Instead, I use KQL (Kusto Query Language) in Advanced Hunting to get immediate clarity across the entire fleet.

I developed this script to categorize apps by risk (High/Medium/Low), join them with known CVEs, and calculate an Exposure Score. This is how I decide exactly what needs to be removed immediately and what can wait.

You can find my full KQL hunting scripts here: unwanted-apps.kql and eos-and-unwanted-summary.kql.

// MY UNWANTED APP HUNTER - Fleet-wide Discovery (Sample List)
let HighRiskApps = dynamic(["utorrent", "anydesk", "app_placeholder_1"]);
let MediumRiskApps = dynamic(["steam", "bluestacks", "app_placeholder_2"]);
let LowRiskApps = dynamic(["ccleaner", "app_placeholder_3"]);
let UnwantedRegex = strcat(@"(?i)(", strcat_array(HighRiskApps, "|"), "|", strcat_array(MediumRiskApps, "|"), "|", strcat_array(LowRiskApps, "|"), ")");

// Inventory & CVE Correlation
DeviceTvmSoftwareInventory
| where isnotempty(SoftwareName)
| extend MatchTarget = tolower(strcat(coalesce(SoftwareVendor, ""), " ", SoftwareName))
| where MatchTarget matches regex UnwantedRegex
| join kind=leftouter (
    DeviceTvmSoftwareVulnerabilities
    | summarize CveCount = dcount(CveId), MaxCvss = max(todouble(CvssScore)) by DeviceId, SoftwareName
) on DeviceId, SoftwareName
| extend ExposureScore = case(MatchTarget matches regex @"(?i)(utorrent|bittorrent|anydesk)", 80.0, 40.0) // My scoring logic
| project DeviceName, SoftwareName, SoftwareVersion, CveCount, MaxCvss, ExposureScore
| order by ExposureScore desc

This KQL gives me my “hit list.” Once I have the targets identified by the query, I move to automation.

Step 2: Automating the Kill with Intune

Once my KQL hunt identifies the targets, I use a “Master Script” approach for Intune Proactive Remediations. I don’t create separate packages for every single app; I use a centralized target list based on my KQL findings.

The Strategy

The system uses two scripts: a Detection script that identifies the presence of the software found in my KQL hunt, and a Remediation script that kills it.

I target these “zombies” using three methods:

1. Registry GUIDs: Finding the specific MSI or installer GUID.
2. Wildcard Registry: Finding keys like HKLM:\... \Uninstall\Opera*.
3. File Paths: Checking for specific executables.

Crucially, my scripts handle per-user installs by scanning the HKEY_USERS (HKU) hive, ensuring that apps hiding in a user’s local profile don’t escape.

Implementation: The Master Scripts

I keep the full scripts in my GitHub repository.

1. The Detection Script

The script iterates through a $zombieTargets array. If any target identified in my KQL hunt is found on a device, it exits with Exit 1, triggering the remediation.

2. The Remediation Script

When triggered, the script attempts a silent uninstall via the registry. If that fails (which it often does with user-installed “zombies”), it forcefully stops any running processes and nukes the application folder.

Verification: Closing the Loop

After deploying the remediation, I close the loop by:

1. Intune Console: Monitoring the “Issue fixed” status in the Remediations blade.
2. Local Logs: Checking C:\ProgramData\Eriteach\Logs\ if I need to see why a specific uninstall failed.
3. Defender for Endpoint: Re-running my KQL query a few days later to watch the exposure score drop as the zombie apps disappear.

Summary

I don’t let unauthorized and outdated software bloat my vulnerability reports. By starting with a KQL hunt to identify the risk and following up with Intune automation, I’ve managed to keep my environment clean without manual intervention.

Before we standardized our browsers, users were free to install whatever they liked, which left Firefox scattered across hundreds of endpoints. I don’t waste time with manual cleanup; I’ve automated the entire process.

Scoping at Scale with KQL

I start by getting a clear picture of the “infestation.” I use KQL (Kusto Query Language) in Defender Advanced Hunting to see exactly which versions are out there and how many devices are affected:

// My Firefox Discovery Query
DeviceTvmSoftwareInventory
| where SoftwareName contains "Firefox"
| summarize DeviceCount = dcount(DeviceName), Versions = make_set(SoftwareVersion) by SoftwareName
| order by DeviceCount desc

This query gives me an immediate count and version list, which I use to target my Intune remediations effectively.

The Strategy: Automating the Cleanup

I use Intune Proactive Remediation with a two-script system:

• Detection: Finds Firefox in the registry, Program Files, and user profiles.
• Remediation: Wipes everything—processes, files, shortcuts, services, and scheduled tasks.

Detection Logic

My script scans three main areas where Firefox likes to hide:

1. Registry - 64-bit/32-bit uninstall keys and per-user installs.
2. Program Files - Standard install locations.
3. User Profiles - AppData folders.

$findings = @()
$uninstallPaths = @(
    "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall",
    "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall",
    "HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall"
)

foreach ($path in $uninstallPaths) {
    if (Test-Path $path) {
        $apps = Get-ItemProperty "$path\*" -ErrorAction SilentlyContinue |
            Where-Object { $_.DisplayName -like "*Firefox*" }
        foreach ($app in $apps) {
            $findings += "Registry: $($app.DisplayName)"
        }
    }
}

if ($findings.Count -gt 0) { exit 1 } else { exit 0 }

Full script: firefox-removal-detection.ps1

The Kill: Remediation

My remediation script is designed to be thorough. It stops all active processes before attempting the uninstall to ensure nothing is locked.

1. Stop Processes - Firefox, plugin-container, and updaters.
2. Uninstall - Uses the registry uninstall string (handles helper.exe and msiexec).
3. Cleanup - Deletes directories in Program Files, ProgramData, and AppData.
4. Final Polish - Removes shortcuts, the MozillaMaintenance service, and update tasks.

# My Process Kill List
$firefoxProcesses = @("firefox", "firefox-esr", "plugin-container", "crashreporter", "updater")
foreach ($proc in $firefoxProcesses) {
    Get-Process -Name $proc -ErrorAction SilentlyContinue | Stop-Process -Force
}

Full script: firefox-removal-remediation.ps1

Outcome and Verification

I monitor the progress directly in the Intune portal under Devices > Scripts and remediations.

Success looks like a “fixed” status on my devices. I also check my custom logs at C:\ProgramData\Eriteach\Logs\ if I see any stubborn installs that require a manual look.

Lessons Learned

• User Profiles - The script cleans all profiles on the machine. I always warn users that bookmarks and saved passwords will be gone.
• Force Close - Since I force-close the process, I run this remediation during off-hours or maintenance windows to minimize disruption.

Related Links

• Auto-Update Firefox with Intune - My workflow for when I need to keep Firefox but stay updated.
• Intune Remediations overview
• Microsoft Defender software inventory

I don’t manually check every device. Instead, I’ve built a workflow that finds these apps across the fleet and removes them automatically.

The Discovery: Fleet-wide Hunting with KQL

Before I can remove anything, I need to know exactly where the problems are. I use Microsoft Defender for Endpoint (MDE) to find these apps in seconds. Instead of browsing the portal, I run a KQL query in Advanced Hunting to identify high-risk software:

// My Discovery Query (Sample)
DeviceTvmSoftwareInventory
| where SoftwareName has_any ("utorrent", "anydesk", "ccleaner")
| project DeviceName, SoftwareName, SoftwareVersion

This gives me my target list. For a more aggressive approach that handles EOL and EOS software, I use my Zombie Software Hunting workflow.

The Automation: Intune Proactive Remediation

Once I have my targets, I use Intune Proactive Remediation. My setup uses two scripts:

1. Detection - Checks if the app exists (exit 1 = found, triggering the kill)
2. Remediation - Silent removal

My Configuration

I target apps by registry, WMI, or the programs list. I typically configure my detection by setting these variables:

$AppDisplayName = "Zoom"
$AppPublisher = ""
$AppProductCode = "{86B70A45-00A6-4CBD-97A8-464A1254D179}"
$UsePartialMatch = $true

Full script: Detect-UnwantedApp.ps1

The Kill (Remediation)

Once detected, my remediation script pulls the uninstall string from the registry or uses the MSI product code to wipe the app silently.

Full script: Remove-UnwantedApp.ps1

Deployment Details

This is how I set it up in my tenant:

1. Intune → Devices → Remediations
2. Create script package: “Remove [AppName]”
3. Settings:
   • Run script in 64-bit PowerShell: Yes
   • Run with logged-on credentials: No (runs as SYSTEM)
4. Schedule: Daily (I want these gone fast)

Trade-offs and Lessons Learned

• Pilot first - I always run detection on a pilot group before enabling the remediation.
• Product codes change - I’ve learned that different versions often have different codes; KQL helps me find all the variants first.
• Partial match risk - I use $UsePartialMatch = $true carefully to avoid catching plugins I might actually want to keep.

Related Links

• Microsoft: Proactive Remediations
• Intune script requirements