Forum Discussion
Defender detection caused by monitoring script
Dear Community
We use PRGT, which monitors various things for our customers. One of our customers uses Microsoft Defender, which issued an alert for “SmokeLoader.” After some research, we found that this is caused by two of our scripts, which establish a connection to our servers and query various things.
This raised the question of how we can best whitelist this, since the detection comes from “WinRM” and not directly from the script itself. However, the script itself establishes a connection to the servers and requests some information.
Are there any sensible measures that can be taken here, because only whitelisting the script (folder or hash) makes limited sense here, since the detection in this case was for the WinRM process. So the behavior analysis would kick in again.
Thank you for your time!
Best regards,
SleeperHead
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.
1 Reply
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.