Two Lookalike Characters Are All It Takes: Why Homoglyph Typosquatting Makes Fleet-Wide Browser Patching an RMM Problem

Researchers recently highlighted a deceptively simple weakness in Chromium-based browsers: a specific pair of rare characters — one Cyrillic, one Latin — render so similarly that attackers can register domains visually indistinguishable from the sites your users log into every day. Two characters. That is the whole attack. No exploit chain, no malware dropper — just a URL that looks exactly right to a user skimming their inbox at 4:45 on a Friday afternoon.

For browser vendors this is an IDN rendering problem. For you — the sysadmin, the helpdesk lead, the MSP tech with twelve tabs open across five consoles — it is an endpoint management problem. Your real defense against homoglyph typosquatting is not a firewall rule. It is three operational capabilities: knowing exactly which browser build sits on every endpoint, pushing a patched build to all of them in minutes, and remoting into one specific user's machine the second they call and say the login page looked odd. If those three things take hours, the exposure window belongs to you, not the attacker.

And in most IT shops, they do take hours — because the monitoring tool does not watch workstations, the RMM lives in a different console from the helpdesk, and nobody can answer "how many machines are below the current Chromium build?" without an afternoon and a spreadsheet.

The Problem Is Not the Character. It Is the Gap Between Your Tools.

Chromium Stable ships roughly every four weeks, with out-of-band security releases in between. In a typical 500-endpoint environment, 5–15% of machines lag behind at any given moment: laptops offline for weeks, broken updater services, restarts deferred by users, machines that only touch the VPN once a month. That straggler population is your actual attack surface — and most monitoring stacks cannot even see it.

Look at what the average tool stack does here:

• Standalone monitoring platforms (Nagios, Zabbix, PRTG) watch servers, services, and SNMP counters. They have no opinion about which Chrome build is on the sales team's laptops, because workstations are simply out of scope.
• Standalone or bolt-on RMM consoles can run scripts on endpoints, but the results land in the RMM's own console and then evaporate. They are not attached to a ticket, not correlated with an alert, and not visible in any timeline your IT manager reviews. If the tech who ran the script goes on vacation, the findings go with them.
• A separate helpdesk sees only the downstream symptom — the ticket that says "the sign-in page looked strange" — and has no way to turn that single ticket into fleet-wide action. So the technician cleans up one user's machine while forty-nine identical machines stay exactly as they are.

These gaps are not an accident. They are the result of siloed architecture and legacy purchasing: monitoring was bought for the server room, RMM for managed endpoints, helpdesk for the service desk. Three vendors, three databases, zero shared context. Many legacy RMM products treat patching as an afterthought, so browser updates route through yet another mechanism — WSUS, Intune, a hand-built GPO — or quietly fall between the cracks.

The operational cost is painfully recognizable:

• Time-to-answer: "Are we patched?" becomes a manual sweep — hours per site for an MSP, a full day across a 500-seat internal environment.
• MTTR and ticket volume: one suspicious-domain scare triggers a burst of near-identical tickets. Handled as islands across disconnected tools, what should take minutes stretches into days.
• SLA misses and burnout: the tech toggling between the monitoring console, the RMM, the helpdesk, and Excel makes mistakes, works late, and absorbs the blame when the audit answer arrives after the client already asked for it.

The bitter part: the fix — an updated Chromium build — is usually already available from the vendor. The failure is operational, not technical. It is the lag between knowing and acting.

How AlertMonitor Turns This Into a Five-Minute Workflow

AlertMonitor is one platform: infrastructure monitoring, RMM, helpdesk, patching, and alerting share the same data model and the same timeline. In this scenario, three things change immediately.

1. Fleet-wide browser audits become a script run, not a project. Select a device group — All Workstations, or Workstations – Client A — paste the audit script, execute. Version results stream back from every machine into the same console; non-compliant endpoints stand out instantly. No RDP sessions into 200 machines, no CSVs emailed around, no second tool.

2. Script results live on the same timeline as alerts and tickets. When the ticket "user saw a lookalike login page" is open, the technician sees that device's full history — alerts, script outputs, patch state — in one view, and launches a remote session from that same screen. No tab-switching, no copying computer names between a monitoring console and a separate RMM, no "which tool did we run that in?" archaeology a week later.

3. Remediation is one click, not a change request. Push the current Chrome or Edge build through software deployment, re-run the audit script to verify, and the entire sequence is captured automatically — which means your SLA report writes itself from the same timeline.

The before-and-after is blunt. Old way: five tools, a half-day sweep, a spreadsheet, and hope. AlertMonitor way: a two-minute script execution across the device group answers "which machines are exposed," a targeted push closes the gap, and a verification run proves it — all logged in one place the whole team can see.

Practical Steps You Can Take Today

Step 1 — Baseline every Chromium browser on your endpoints. Run this across your workstation device groups. It reports every detected Chrome, Edge, or Brave install with its exact build:

# Chromium browser inventory — run via RMM across a workstation device group
$candidates = @(
    "$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
    "${env:ProgramFiles(x86)}\Google\Chrome\Application\chrome.exe",
    "$env:ProgramFiles\Microsoft\Edge\Application\msedge.exe",
    "${env:ProgramFiles(x86)}\Microsoft\Edge\Application\msedge.exe",
    "$env:ProgramFiles\BraveSoftware\Brave-Browser\Application\brave.exe"
)

foreach ($exe in $candidates) {
    if (Test-Path $exe) {
        $file = Get-Item $exe
        [PSCustomObject]@{
            Computer = $env:COMPUTERNAME
            Browser  = $file.VersionInfo.ProductName
            Version  = $file.VersionInfo.ProductVersion
            Path     = $exe
        }
    }
}

Step 2 — Enforce a minimum build and make non-compliance visible. This check exits with code 1 when any detected browser is behind your minimum. Schedule it in AlertMonitor as a recurring script on your workstation groups, and non-compliant machines raise an alert exactly like any other failed check:

# Chromium minimum-build compliance check
# Set to your approved minimum. Browsers ship security updates roughly
# every 4 weeks — review this value monthly.
$minimum = [version]'153.0.0.0'

$candidates = @(
    "$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
    "${env:ProgramFiles(x86)}\Google\Chrome\Application\chrome.exe",
    "$env:ProgramFiles\Microsoft\Edge\Application\msedge.exe",
    "${env:ProgramFiles(x86)}\Microsoft\Edge\Application\msedge.exe"
)

$results = foreach ($exe in $candidates) {
    if (Test-Path $exe) {
        $file = Get-Item $exe
        [PSCustomObject]@{
            Computer = $env:COMPUTERNAME
            Browser  = $file.VersionInfo.ProductName
            Version  = $file.VersionInfo.ProductVersion
            Current  = ([version]$file.VersionInfo.ProductVersion -ge $minimum)
        }
    }
}

$results | Format-Table -AutoSize

if ($results | Where-Object { -not $_.Current }) {
    Write-Output 'NON-COMPLIANT: at least one Chromium browser is below the minimum build.'
    exit 1
}

Write-Output 'COMPLIANT: all detected Chromium browsers meet the minimum build.'
exit 0

Step 3 — Close the gap with a targeted update push. For the machines that failed, push the update from the same console, then re-run Step 2 to verify:

# Silently update Chrome and Edge via winget (run as SYSTEM for machine-wide installs)
winget upgrade --id Google.Chrome --silent --accept-package-agreements --accept-source-agreements
winget upgrade --id Microsoft.Edge --silent --accept-package-agreements --accept-source-agreements

On machines where winget is unavailable, trigger the vendors' own updaters instead:

# Force the built-in updaters to check for a new build immediately
Start-ScheduledTask -TaskPath '\' -TaskName 'GoogleUpdateTaskMachineUA'
Start-ScheduledTask -TaskPath '\' -TaskName 'MicrosoftEdgeUpdateTaskMachineUA'

Managing Linux endpoints in the same fleet? Same audit, one line:

google-chrome --version 2>/dev/null || chromium --version 2>/dev/null || microsoft-edge --version 2>/dev/null || echo 'no chromium browser found'

Step 4 — Wire it into the workflow, not just the tooling. In AlertMonitor: schedule the compliance script as a recurring check on workstation device groups, save a response that pairs the update push with a verification re-run, and add a suspicious-website action to your helpdesk ticket templates that offers a one-click remote session to the affected endpoint. When the next lookalike-domain scare lands — and there will be a next one — your entire response is: run audit, push update, verify. Minutes, not days, inside one timeline that doubles as your SLA evidence.

Two characters are enough for an attacker to build a convincing fake. Your answer has to be operational speed: every endpoint visible, every build current, every response captured in one place. That is exactly what a unified RMM is for.

Related Resources

AlertMonitor RMM & Remote Management AlertMonitor Platform Overview Book a Demo RMM & Remote Management Resources