The 11-Hour Backdoor: What the Cursor Extension Attack Should Teach Every IT Team About Endpoint Control

On October 29, a maliciously modified version of Anthropic's Claude Code extension sat in Cursor's VS Code Extension Marketplace for roughly 11 hours — from about 2:27am PT to 1:35pm PT. Versions 2.1.312 and 2.1.313 attempted to add an attacker-controlled SSH key and enable local SSH access. Translation: a persistent remote-access backdoor on developer machines — the exact machines holding source code, deployment credentials, and production access.

Cursor pulled the compromised builds once discovered, and that response deserves credit. But the incident leaves every IT team and MSP with an uncomfortable question: if that extension had landed on 40 developer workstations in your environment, how long would it take you to find every copy, remove it, verify no unauthorized SSH keys were added, and produce evidence that you actually did all of that?

If your honest answer involves remote-desktoping into machines one at a time, or emailing your devs and asking them to run a command and paste back the output — keep reading. Your RMM setup has a gap, and this incident just exposed it.

What Made This Incident Different From a Normal Malware Alert

No phishing email, no malicious attachment, no user clicking something they shouldn't. Developers updated a tool through a channel they trust, the same way they do every week. That is what a supply chain attack is: the trusted update mechanism itself is the delivery vehicle.

And the target matters as much as the method. Developer endpoints are the crown jewels of most networks: Git credentials, API keys sitting in environment variables and dotfiles, direct access to staging and production, VPN routes into client environments. For an MSP, one compromised dev workstation can mean a foothold in a client's infrastructure within minutes. Eleven hours of exposure is more than enough time for an automated script to do its work.

The Real Problem: Developer Workstations Are the Endpoints You Manage Worst

Most IT teams have decent RMM coverage on servers and standard corporate workstations — and near-zero visibility into developer machines. The devs have local admin rights (they needed it once in 2019 and nobody revoked it), they self-install tools, and their IDE extensions update themselves silently. Forty developers means forty slightly different tool sets, and nobody on the IT side maintains an inventory of any of it.

Here is the technical detail that makes it worse: traditional RMM platforms inventory installed applications from WMI and the Add/Remove Programs registry. VS Code and Cursor extensions do not live there. They are plain folders under each user profile — C:\Users\<name>\.cursor\extensions and similar. That means a whole class of software — one that just demonstrated it can carry a backdoor — sits invisible to the software inventory in most RMM products, including the big names like ConnectWise, NinjaOne, Datto RMM, and Syncro. The exact tool category meant to give you endpoint control has a blind spot exactly where this attack landed.

Then something like this breaks, and the response is ad hoc: a Slack message to the dev team, a shared spreadsheet, techs bouncing between machines through a remote-access tool. Or worse — you find out when a user mentions it.

Why Fragmented Tooling Turns a Bad Day Into a Bad Week

Look at the typical stack: infrastructure monitoring in one console (PRTG, Zabbix), RMM in another, helpdesk in a third (ConnectWise Manage, Freshservice, HaloPSA), remote access in a fourth (AnyDesk, TeamViewer, ScreenConnect). Every one of those seams costs you time during an incident:

• The tech gets the ticket but cannot deploy a script from it. They switch tools, search for the device, hope it is online, hope the credentials work.
• Script output vanishes into a tool log that nobody connects back to the ticket or the monitoring timeline.
• When the client's security contact asks 'which machines had it, when were they cleaned, who verified it?' — nobody can answer without manually reconstructing events across four systems.
• Once word spreads, the helpdesk fills with 'am I affected?' tickets, triaged blind because the service desk cannot see device data or script results.

Run the numbers for a mid-size MSP: 12 clients, roughly 250 developer workstations. Checking one machine manually over remote access takes 8–10 minutes once you include login, enumeration, and note-taking. That is 33+ technician hours for detection alone, spread across shifts and interrupted by everything else on your plate. Remediation and verification roughly double it. Realistic total: two to three days of chaos, missed SLAs on unrelated tickets because everyone is firefighting, and a QBR where you have to explain all of this to the client.

How AlertMonitor Turns This Into a 45-Minute Exercise

AlertMonitor's RMM was built on the assumption that monitoring, scripting, and helpdesk are one system, not three. Here is the same incident inside AlertMonitor:

1. Group once, target forever. Developer workstations are a device group. When the advisory drops, you do not hunt for machines — the population is already defined.
2. One script, every endpoint. Deploy the sweep script to the device group in a single action. Results stream back per device as each machine checks in — into the same console where your alerts and tickets live.
3. Remediate straight from the results. Devices that flagged get the removal script — again, one action, scoped to the machines that matched.
4. Verify and prove. Re-run the sweep as a verification pass. The output — clean on every device, timestamped — is your incident report. Filter the timeline by script and date range and hand it to the client.
5. Close the loop in the helpdesk. Remediation tickets are created in the same platform, script output attaches automatically, and the SLA clock runs against the actual fix — not against email back-and-forth.
6. Remote session when you need eyes. Anything ambiguous gets a remote session opened from the same screen. No second tool, no second credential set.

The time math: advisory published to every endpoint swept in under an hour for an online fleet. Remediation plus a verified clean report: same day. Not two days of remote-desktop roulette.

What You Can Do Today

Even before you fix your tooling, these are the sweeps to run. Deploy each one through your RMM as a script against your developer device groups.

Step 1 — Sweep for the extension (per machine, all user profiles):

# Find known-bad Claude Code extension builds under every user profile
$badPattern = 'anthropic\.claude-code\-(2\.1\.312|2\.1\.313)'
$paths = 'C:\Users\*\.cursor\extensions', 'C:\Users\*\.vscode\extensions'

Get-ChildItem $paths -Directory -ErrorAction SilentlyContinue |
    Where-Object { $_.Name -match $badPattern } |
    Select-Object @{n='Computer';e={ $env:COMPUTERNAME }},
                  @{n='User';e={ ($_.FullName -split '\\')[2] }},
                  FullName, LastWriteTime

In AlertMonitor, this output lands on each device's timeline automatically — no copy-pasting out of remote sessions.

Step 2 — Remove known-bad builds and log the action:

# Remove known-bad extension builds; output is collected per device
$bad = Get-ChildItem 'C:\Users\*\.cursor\extensions', 'C:\Users\*\.vscode\extensions' `
    -Directory -ErrorAction SilentlyContinue |
    Where-Object { $_.Name -match 'anthropic\.claude-code\-(2\.1\.312|2\.1\.313)' }

foreach ($ext in $bad) {
    Remove-Item -LiteralPath $ext.FullName -Recurse -Force -ErrorAction SilentlyContinue
    [PSCustomObject]@{
        Computer = $env:COMPUTERNAME
        Path     = $ext.FullName
        Result   = 'Removed'
        Time     = (Get-Date).ToString('o')
    }
}
if (-not $bad) { 'Clean - no known-bad Claude Code builds found.' }

Step 3 — Audit SSH trust on every endpoint. The advisory says the malware tried to add an SSH key, so this is the check that proves your machines are actually clean — not just that the extension folder is gone:

# List every non-comment key in user and admin authorized_keys files (Windows OpenSSH)
$files = @(Get-ChildItem 'C:\Users\*\.ssh\authorized_keys' -ErrorAction SilentlyContinue)
$admin = 'C:\ProgramData\ssh\administrators_authorized_keys'
if (Test-Path $admin) { $files += Get-Item $admin }

foreach ($f in $files) {
    Write-Output ('=== ' + $f.FullName + ' (modified ' + $f.LastWriteTime.ToString('s') + ') ===')
    Get-Content $f.FullName |
        Where-Object { $_.Trim() -and $_ -notmatch '^\s*#' } |
        ForEach-Object { ($_ -split ' ')[-1] }
}

And for the Linux and macOS endpoints in the same fleet:

# Sweep authorized_keys across all home directories
for f in /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys; do
  if [ -f "$f" ]; then
    echo "=== $f ==="
    grep -vE '^\s*(#|$)' "$f" | awk '{print $NF}'
  fi
done

# Flag any key file modified in the last 72 hours
find /root /home -name authorized_keys -mtime -3 2>/dev/null

Step 4 — Check for SSH listeners and the OpenSSH service where it should not be:

# Anything unexpected listening on SSH ports?
Get-NetTCPConnection -State Listen -ErrorAction SilentlyContinue |
    Where-Object { $_.LocalPort -in 22, 2200, 2222 } |
    Select-Object LocalAddress, LocalPort, OwningProcess,
        @{n='Process';e={ (Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName }} |
    Sort-Object LocalPort -Unique

# Is the OpenSSH server installed and running?
Get-Service -Name sshd -ErrorAction SilentlyContinue |
    Select-Object Name, Status, StartType

Step 5 — Make it continuous, not a one-off. In AlertMonitor, schedule the sweep script weekly against the developer device group, and put alerts on the conditions that would have caught this class of attack early: a new authorized_keys file appearing in a profile that never had one, the sshd service showing up on a machine where OpenSSH was never installed, and new extensions matching your watchlist in the per-user extension folders. The next supply chain incident should generate one alert in your console — not a week of manual discovery.

The Takeaway

This was never just about Cursor, and it will not be the last compromised update channel — extension marketplaces, package registries, and vendor update servers are all in the blast radius. Your exposure comes down to three questions: how fast can you see what is on every endpoint you are responsible for; how fast can you act on all of them at once; and can you prove what you did afterward.

Those are RMM questions. Answered through four disconnected tools, they go unanswered while you fight fires. Answered inside one platform — where the inventory, the scripts, the remote sessions, and the tickets share a single timeline — they are a 45-minute exercise and a report you can hand to a client with confidence.

Related Resources

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