Forum Discussion
Defender detection caused by monitoring script
This is a classic case where Defender’s behavior-based engine is flagging something that looks like SmokeLoader (C2-style comms via WinRM), even though it’s your monitoring script. The fact that it’s tied to WinRM (wsmprovhost.exe / svchost.exe) instead of the script binary is why hash/path exclusions won’t help.
Long-Term Fix:
Where possible, move away from WinRM-based scripts → use native PRTG sensors, APIs, or WMI/DCOM sensors instead of custom WinRM queries.
The more you mimic malware behavior (remote WinRM sessions, credential delegation, repetitive queries), the more often behavior-based ML will fire.
Recommended approach for your case:
Submit FP to Microsoft.
Don’t exclude WinRM globally.
Use a custom detection suppression rule scoped to your known PRTG monitoring activity.
If feasible, re-architect the script to query via PRTG’s supported APIs to avoid looking like C2.
Jovan.
This is a classic case where Defender’s behavior-based engine is flagging something that looks like SmokeLoader (C2-style comms via WinRM), even though it’s your monitoring script. The fact that it’s tied to WinRM (wsmprovhost.exe / svchost.exe) instead of the script binary is why hash/path exclusions won’t help.
Long-Term Fix:
Where possible, move away from WinRM-based scripts → use native PRTG sensors, APIs, or WMI/DCOM sensors instead of custom WinRM queries.
The more you mimic malware behavior (remote WinRM sessions, credential delegation, repetitive queries), the more often behavior-based ML will fire.
Recommended approach for your case:
Submit FP to Microsoft.
Don’t exclude WinRM globally.
Use a custom detection suppression rule scoped to your known PRTG monitoring activity.
If feasible, re-architect the script to query via PRTG’s supported APIs to avoid looking like C2.
Jovan.