You know that feeling when you lock your front door, but then realize the back door is wide open? That's what happened to Stryker. A massive cyberattack wiped their systems clean, and it all started because the very tools meant to protect them were turned into weapons. Now, CISA is demanding that every organization tighten the screws on Microsoft Intune and Teams. This isn't just another security advisory—it's a wake-up call.
Let's break down exactly what you need to do to make sure your endpoint management doesn't become a backdoor for attackers. We'll skip the fancy jargon and get straight to the point.
Lock down device enrollment to corporate hardware only
Most IT departments leave device enrollment wide open. Any user with a valid password can enroll their phone or laptop. That's like giving a stranger the keys to your house because they know your name. In the Stryker attack, the bad guys used stolen passwords to enroll a virtual machine into the company's Intune tenant. Once enrolled, that machine looked legit. It could access internal resources, download sensitive data, and bypass basic security rules.
Here's how you fix it: Go to the Microsoft Intune admin center, then Devices > Enrollment device platform restrictions. Create a new restriction for each platform—Windows, macOS, iOS, Android—and set it to block personal devices. Only allow corporate-owned devices. This forces attackers to have a physical device that's already registered in your hardware hash list or serial number database. It's not foolproof, but it raises the bar significantly.
Why does this matter? Think of it like a hotel key card. If you let anyone with a credit card get a key, that's a problem. But if you only give keys to people who checked in at the front desk and provided an ID, you're much safer. Same concept here.
Rein in PowerShell and proactive remediation scripts
The real damage in the Stryker attack came from PowerShell scripts. Intune lets admins run scripts as SYSTEM—the highest privilege on a machine. So if an attacker compromises an admin account, they can push ransomware or wiper code to every computer in minutes. It's like giving someone the master key to every room in your building.
To prevent this, you need to lock down who can create or modify scripts. Don't use the global Intune Administrator role for day-to-day work. Instead, set up Privileged Identity Management (PIM) in Microsoft Entra. With PIM, any admin who wants to change a script has to request temporary access, get approval, and provide a business reason. This creates an audit trail and adds a time delay that can stop an attack in progress.
But that's not enough. You also need to control which scripts actually run on endpoint machines. Use Windows Defender Application Control (WDAC) or AppLocker to enforce a constrained language mode for PowerShell. Better yet, require all scripts to be digitally signed. Intune doesn't block unsigned scripts by default, but a properly configured WDAC policy will refuse to run any script that doesn't carry a signature from your corporate certificate authority. So even if an attacker modifies a script in the Intune console, it will fail on every endpoint because the signature is invalid.
I remember a story from a friend who worked at a hospital. They had a script that pushed software updates to all nurses' stations. Someone accidentally edited the script to delete files instead of installing updates. Luckily, they had code signing enabled, so the script didn't run. That's the kind of safety net you want.
Close the Teams external access loophole
Teams is often where the trouble starts. Attackers use external access to send messages that look like they're from a colleague. Because people trust Teams more than email, they're more likely to click a link or download a file. It's like a wolf in sheep's clothing.
Go to the Teams admin center and check your External access settings. The default is to allow all external domains—that means anyone with a Microsoft 365 account can message your staff. Change that to "Allow only specific external domains" and add only the domains of trusted partners. If you absolutely need open federation, turn on Safe Links for Teams through Microsoft Defender for Office 365. This scans every URL in a chat and blocks malicious ones at the moment someone clicks.
Also, disable the ability for external users to send files. That forces attackers to use external links, which your security stack can intercept more easily than a direct file transfer within a trusted app.
Think of it this way: You wouldn't let strangers walk into your office and start handing out USB drives to your employees. Treat Teams the same way.
Implement phishing-resistant conditional access
The A0Backdoor malware relies on session token theft. Even if you have MFA, attackers can use a proxy tool to steal a user's session cookie and bypass the login entirely. It's like someone copying your hotel key card from a distance and then using it to enter your room.
To stop this, require phishing-resistant authentication methods in your Conditional Access policies. Move to Authentication Strength policies in Microsoft Entra that demand FIDO2 security keys or Windows Hello for Business. These methods tie the authentication to the specific hardware and the website's origin, so a stolen token is useless.
Another critical policy: require devices to be marked as compliant. Even if someone steals a session token, they can't use it unless they're on a device that Intune has verified as healthy and compliant. That means the attacker needs both the user's physical security key and their managed laptop to get in. It's a two-factor defense for the session itself.
Monitor for unauthorized management actions
Detection is your last line of defense. Even with all these locks, a clever attacker might slip through. You need to watch for suspicious activity in real time.
Stream your Intune audit logs and Microsoft Entra sign-in logs to a Log Analytics workspace or a SIEM like Microsoft Sentinel. Then create alerts for specific high-risk operations. For example, attackers often look for the DeviceConfiguration and DeviceManagementConfiguration providers. Write a Kusto query to alert you whenever a script or policy is updated that hasn't been touched in months, especially if the admin who updated it just activated their PIM role from an unfamiliar IP address.
Also monitor for "Retire" or "Wipe" commands that target many devices at once. Intune doesn't have a built-in approval workflow for bulk actions, so you have to build your own. If someone issues more than five wipe commands in an hour, your security team should get an automated page. That's your smoke detector.
Wrapping up
The days of trusting a perimeter firewall are over. Your Intune configuration is now the most critical defense you have. A single mistake in an enrollment policy or an overly permissive Teams setting can open the door for a tenant-wide wipe. But by locking down device enrollment, hardening script execution, limiting Teams external access, requiring strong authentication, and monitoring for abuse, you can make it much harder for attackers to turn your own tools against you.
Take it one step at a time. Start with device enrollment restrictions—that's the quickest win. Then move on to script signing and Teams settings. Remember, security isn't about being perfect; it's about being less vulnerable than the next guy. Every layer you add makes the attacker's job harder. And in a world where one click can bring down your entire company, that's worth the effort.