Infostealers Without Borders: Why Local Admin Still Matters On Windows Endpoints

This week, the security team at published new research on modern infostealers: campaigns that quietly steal credentials, tokens and other sensitive data across macOS, Python-based tools and trusted platforms like messaging apps and PDF utilities.

On the surface it looks like “mostly a macOS story”, but the pattern will feel very familiar to anyone running Windows endpoints:

• Use phishing, malvertising or fake installers to get code running in the user’s context.
• Steal browser passwords, cookies, access tokens, crypto wallets and more.
• Use those stolen secrets to pivot into cloud apps, admin portals and Windows environments.

The part that should make Windows admins sit up is the mitigation guidance. Alongside cloud-delivered protection, EDR block mode and other controls, the research calls out the combination of Tamper Protection with Disable Local Admin Merge so attackers can’t use local admin rights to add their own antivirus exclusions.

In other words: even when the malware is cross-platform, local admin on Windows is still a force multiplier for attackers.

Why infostealers love over-privileged users

Infostealers are designed for scale. They don’t need a full remote shell on every machine; they “grab and go”:

• Harvest credentials and tokens from browsers and apps.
• Upload password vaults and configuration files to a command-and-control server.
• Sell or reuse those secrets for later attacks against email, VPN, RDP, admin portals and more.

If the compromised user is a standard user on a well-managed Windows device, the attacker still has to work to turn that initial foothold into admin or domain control. If the same user is already a local admin, a lot of the hard work disappears:

• They can tamper with security tools, logs and local protections.
• They can add Defender exclusions to hide future payloads, unless you explicitly block local overrides.
• They can install additional tools, persistence mechanisms and lateral movement utilities without hitting privilege roadblocks.

That’s why so many of your recent blogs – from January 2026 Patch Tuesday: 58 Windows Privilege Escalation Flaws & What They Mean for Local Admin to What the Samsung Magician Vulnerability Teaches Us About Local Admin & Least Privilege – keep coming back to the same theme: initial access is inevitable, but local admin determines how bad it gets.

What the new guidance means for Windows admins

The infostealer research includes a familiar set of hardening steps: turn on cloud-delivered protection, enable attack surface reduction rules, use network and web protection, and keep OS and browsers patched.

Two points are particularly relevant if you’re wrestling with local admin today:

1. Enable Tamper Protection and Disable Local Admin Merge for Defender.
   When you disable local admin merge for Microsoft Defender, you prevent local admins from adding their own exclusions via the UI or PowerShell. That keeps AV exclusions and related settings under central control (Intune, ConfigMgr, GPO) rather than whichever user happens to have admin rights on the box.
2. Remove unnecessary local admins so attackers can’t “live off the land”.
   If an infostealer lands on a device where the user is already a local admin, disabling local admin merge helps, but it doesn’t fix the broader problem. Over-privileged accounts still make it easier to disable EDR, tamper with services and set up persistence.

In short: the research is a reminder that endpoint least privilege is still one of your highest-leverage controls, even when the malware headlines are about macOS or Python.

Three practical steps to take this month

1. Review your Defender and local admin merge settings.
   Check whether Tamper Protection is enabled, and confirm that Disable Local Admin Merge is configured so local admins can’t quietly add exclusions. Treat this as part of your standard Windows baseline, not an optional extra.
2. Get honest about who is still a local admin – and why.
   Use your existing tooling (Intune, scripts, EDR) to inventory local Administrators group membership across your estate. You’ve covered the “why this matters” and the roadmap in posts like Best Practices for Implementing Least Privilege on Windows and How To Tell Your Users You’re Removing Local Admin Rights (Without Starting a Revolt); this is a good moment to revisit those plans.
3. Isolate the “only works as admin” apps and give them a safer path.
   Every estate has a handful of legacy or specialist Windows apps that still insist on admin rights. Those are exactly the places infostealers and other malware can hide extra capabilities if the user is over-privileged. Instead of leaving those users as full-time admins, broker elevation just for those binaries.

Where Elevator fits into the infostealer story

At UNYK, we built Elevator for Windows to make that last step achievable in real environments, not just in policy documents:

• Keep most users as standard users all day.
• Define a short, explicit list of applications that should run with admin rights.
• Let those apps run elevated under policy, without putting the user in the local Administrators group.
• Log every elevation event so you can see what’s running with admin rights and tune your policies over time.

That way, when the next infostealer or Office zero-day hits, your answer to “how far can this attacker go from a single compromised user?” is much more reassuring:

• Security settings and exclusions are centrally controlled, not tweakable by every local admin.
• Most users are standard, so malware has to work much harder to become SYSTEM or move laterally.
• The few apps that genuinely need elevation are handled in a narrow, auditable way via Elevator instead of blanket local admin rights.

Infostealers may be “without borders”, but your Windows admin rights don’t have to be. Tightening that boundary – with better baselines, fewer local admins and per-app elevation – is still one of the fastest ways to shrink the blast radius of the next inevitable incident.