Your Users Are Copy-Pasting PowerShell From the Internet: How Self-Healing IT Kills the ClickFix Threat

Security researchers at Manifold Security just discovered active ClickFix malware being served from third-party[.]com — a domain that appears in thousands of tutorials, vendor docs, and forum posts as a literal stand-in for "any third-party domain." Unlike example.com, it is not reserved. It is registered, it is live, and it is pushing Windows users toward fake "fix it" prompts that end in PowerShell commands no admin ever approved.

Here is the part that should keep IT managers up at night: ClickFix only works because users are already in the habit of fixing things themselves. They Google "printer offline fix," they land on a page with a copy-paste command, and they run it — because the alternative is a ticket queue where they have already waited three hours. Every ClickFix victim is a user who lost faith in official IT channels. That is not just a security problem. It is an operations problem, and it is one that self-healing automation solves at the root.

What Happened: The Placeholder Domain Trap

ClickFix is a social engineering pattern: a fake CAPTCHA, error dialog, or "your PC is infected" page instructs the user to press Win+R — or open PowerShell as administrator — and paste in a command that supposedly resolves the issue. The command downloads and executes malware instead. There is no exploit for your defenses to catch, because there is nothing to catch: the user executes the payload willingly, often with admin rights, from an interactive session.

The twist in this campaign is the domain itself. Web developers and technical writers use third-party.com constantly in code samples and documentation. Someone following the documentation a little too literally types it into a browser and lands on a live, malicious site. Enterprises that use the placeholder in internal runbooks, onboarding guides, or knowledge-base articles are effectively publishing a link to attacker infrastructure. example.com, example.org, and a handful of others are reserved and safe; third-party.com is not.

If your internal documentation, scripts, or KB articles reference third-party.com as an example domain, check them today. But do not stop there — the domain is a symptom.

The Real Problem Is Not the Domain. It Is the Gap.

Step back and ask why a user is running PowerShell commands from a random webpage in the first place. In most organizations, the honest answer is the same: the gap between when something breaks and when IT responds.

Walk through Monday morning at a typical 500-seat company:

• 8:47 AM — the print spooler on PRNT-01 crashes after the weekend patch reboot. Two hundred users see "Printer offline."
• 9:15 AM — forty tickets sit in the queue, each with a standard "we are investigating" autoresponse.
• 9:30 AM — users who cannot wait start googling. Most land on legitimate advice. One lands on a page that says "Fix: restart the print service with this command" and pastes it into an elevated PowerShell.
• 10:40 AM — a tier-1 tech finally restarts the spooler. Forty tickets get closed. Nobody logs what actually broke, and nobody knows one user just ran an unknown command as admin.

Total damage: nearly two hours of disruption, roughly ten technician-hours (forty tickets at fifteen minutes each), one potentially compromised endpoint, and forty users who learned that IT is slow and self-service is faster. That last lesson is exactly what turns the next ClickFix lure into a breach.

Why the existing toolchain misses it:

• The RMM (NinjaOne, ConnectWise Automate, Datto RMM) saw the service stop — and generated a low-priority "service stopped" alert that sat in an unmonitored queue.
• The standalone monitoring stack (PRTG, Zabbix, SolarWinds) has eyes but no hands. It can tell you the spooler died. It cannot restart it. A human must read the alert, find the endpoint, remote in, and fix it.
• The helpdesk (Freshservice, Zendesk, Jira Service Management) has no endpoint context. The forty user tickets and the RMM alert live in separate systems, so nothing correlates them. There is no automatic "yes, we know — it is being fixed, here is your status."
• Nobody in the chain watches what the user does next. The endpoint agent collects telemetry, but no workflow flags the sequence "service failure at 8:47, user-launched PowerShell at 9:32."

These gaps exist because the tools were built separately, sold separately, and glued together with webhooks and CSV exports. The result is alert noise without action, tickets without context, and remediation that always waits for a human.

How AlertMonitor Closes the Gap

The philosophy is simple: the fastest way to keep users off Google is to fix their problems before they notice them. AlertMonitor does this in four concrete ways.

1. Runbooks attached to alert conditions. When an alert fires — spooler down, disk above 90%, a service crash-looping — an attached runbook executes automatically: restart the service, clear disk space, rotate logs, or trigger a webhook. No human gets paged. If the automated fix succeeds, the user never sees an issue and never opens a ticket. If it fails, then a human is paged, with full execution logs attached.

2. Monitoring, RMM, helpdesk, and patching in one platform. When a user does submit a ticket, the tech opens it and sees live endpoint telemetry — CPU, disk, service state, recent alerts, patch status — in the same window. No twelve tabs across five tools. When forty tickets about "printer offline" arrive, they auto-correlate with the spooler alert and its runbook execution: one root cause, forty tickets linked and closed with a single status update.

3. Canary deployment monitoring. Self-healing means automation running at scale, and untested automation is its own outage generator. AlertMonitor validates script and agent rollouts against a test group before they touch the full fleet. Your spooler runbook proves itself on ten machines for 48 hours before it runs on five hundred.

4. Proactive instead of reactive. Thresholds tuned to warn before failure — disk at 80%, not 99% — plus scheduled maintenance automation and patch compliance visibility mean Monday morning's crash never happens, because the underlying cause was handled the previous week.

The math for the print spooler scenario: outage duration drops from roughly two hours to about thirty seconds, forty tickets become zero, ten technician-hours become a one-time five-minute runbook setup — and the user who would have googled a fix never has a reason to exist.

Practical Steps: Kill Your Top Self-Fix Scenarios This Week

Step 1 — Find out what your users are self-fixing. Pull last quarter's ticket data and count by category. In nearly every environment it is the same shortlist: print spooler, disk full, Outlook profile, VPN drops, stuck services. Every repeat offender is a runbook candidate.

Step 2 — Build the service-restart runbook. This is the pattern for any "service stopped" alert. Attach it to the alert condition in AlertMonitor so it runs on the affected endpoint automatically. Exit code 1 escalates to a human with the execution log attached:

# runbook-service-restart.ps1 — auto-remediation for critical service alerts
# Triggered by AlertMonitor when the watched service enters a non-Running state

$serviceName = 'Spooler'   # swap in the service name from your alert
$svc = Get-Service -Name $serviceName -ErrorAction SilentlyContinue

if ($null -eq $svc) {
    Write-Output "SKIP: Service '$serviceName' not present on this host."
    exit 0
}

if ($svc.Status -ne 'Running') {
    Write-Output "DETECTED: '$serviceName' is $($svc.Status). Restarting..."
    Start-Service -Name $serviceName
    Start-Sleep -Seconds 10

    if ((Get-Service -Name $serviceName).Status -eq 'Running') {
        Write-Output 'RESOLVED: Service restarted automatically. No ticket needed.'
        exit 0
    }
    else {
        Write-Output 'ESCALATE: Restart failed. Route to tier-2 with execution log.'
        exit 1
    }
}

Write-Output 'OK: Service already running. Flap was likely transient.'
exit 0

Step 3 — Get ahead of disk-full incidents. A full disk is the classic "paged at 2am because monitoring warned too late" scenario. This runbook clears the usual offenders when free space drops below 10%:

# runbook-disk-cleanup.ps1 — proactive space recovery on Windows endpoints and servers
$thresholdPct = 10
$drive = Get-PSDrive -Name C
$freePct = [math]::Round(($drive.Free / ($drive.Used + $drive.Free)) * 100, 1)

if ($freePct -lt $thresholdPct) {
    Write-Output "WARNING: C: at $freePct% free. Clearing temp locations..."
    Remove-Item -Path "$env:TEMP\*" -Recurse -Force -ErrorAction SilentlyContinue
    Remove-Item -Path 'C:\Windows\Temp\*' -Recurse -Force -ErrorAction SilentlyContinue
    Remove-Item -Path 'C:\Windows\SoftwareDistribution\Download\*' -Recurse -Force -ErrorAction SilentlyContinue

    $newFreeGB = [math]::Round((Get-PSDrive -Name C).Free / 1GB, 1)
    Write-Output "RESULT: C: now has $newFreeGB GB free after automated cleanup."
}
else {
    Write-Output "OK: C: at $freePct% free. No action needed."
}

And for fleet-wide visibility across your servers, this is the sweep that tells you where you stand right now:

# disk-sweep.ps1 — report any server volume with less than 15 GB free
$servers = @('SRV-APP01', 'SRV-DB01', 'SRV-FILE01', 'SRV-RDS01')

Invoke-Command -ComputerName $servers -ScriptBlock {
    Get-PSDrive -PSProvider FileSystem |
        Where-Object { $_.Free / 1GB -lt 15 } |
        Select-Object PSComputerName, Name,
            @{N = 'FreeGB'; E = { [math]::Round($_.Free / 1GB, 1) }}
}

Point a monitor at that output — or use AlertMonitor's built-in disk monitors — and the cleanup runbook triggers long before anything fills up.

Step 4 — Verify patch compliance. Unpatched machines turn every small incident into a bigger one, and environments where basic hygiene slips are exactly the ones attackers target. Quick snapshot for a Windows server:

# check-pending-updates.ps1 — patch compliance snapshot
$session = New-Object -ComObject 'Microsoft.Update.Session'
$searcher = $session.CreateUpdateSearcher()
$pending = $searcher.Search("IsInstalled=0 and Type='Software'")

if ($pending.Updates.Count -eq 0) {
    Write-Output 'COMPLIANT: No pending software updates.'
}
else {
    Write-Output "NON-COMPLIANT: $($pending.Updates.Count) updates pending:"
    $pending.Updates | ForEach-Object { Write-Output " - $($_.Title)" }
}

Linux fleet equivalent:

#!/bin/bash
# check-updates.sh — report pending updates on a Linux server
if command -v apt-get &> /dev/null; then
    apt-get update -qq
    echo "PENDING UPDATES: $(apt list --upgradable 2>/dev/null | grep -c upgradable)"
elif command -v dnf &> /dev/null; then
    updates=$(dnf -q check-update 2>/dev/null | grep -c '^[a-zA-Z0-9]')
    echo "PENDING UPDATES: $updates"
fi

Step 5 — Canary before fleet. Scope each new runbook to a canary group — ten machines spread across departments — and watch the execution logs in AlertMonitor for 48 hours. Confirm the success rate, then promote it to the full fleet. Untested automation at scale turns one bad script into a company-wide outage; the canary group is how proactive IT avoids becoming a new source of incidents.

Step 6 — Handle the human layer. Scrub your internal docs, runbooks, and KB articles for the third-party.com placeholder and replace it with example.com or your real domain. Add known ClickFix lure domains to your web filter. Then tell users the new deal explicitly: "You should not need to google fixes anymore — if something breaks, we usually know before you do. Just report it and keep working."

The Bottom Line

The third-party[.]com ClickFix campaign will eventually land on blocklists. The user behavior it exploits will not — not while the official fix for "printer offline" is a two-hour ticket queue. Self-healing IT is the sustainable answer: automate remediation for the problems that repeat, correlate alerts with tickets so nobody troubleshoots blind, and canary-test every script before it runs at scale. When the platform fixes issues in seconds, users stop searching for their own fixes — and the ClickFix lure dies of starvation.

Related Resources

AlertMonitor Self-Healing & Proactive IT AlertMonitor Platform Overview Book a Demo Self-Healing & Proactive IT Resources