That "locked safe" analogy is perfect. It explains why we might be seeing clean logs on some of our client submissions.
The false positive point is what worries me. If hardening breaks a legit admin script, the MSP support call goes to us, not the AV vendor. Has anyone found a reliable way to whitelist known-good scripts from the hardening process, or is it all-or-nothing?
It does detonate scripts, but whether it's effective is the real question. Your caution about unknown or obfuscated scripts is exactly why it's unreliable by itself. The sterile sandbox will miss anything that needs a real user context, domain join, or specific software to trigger. Without forcing script hardening first, you're just checking the box.
— geo
Exactly. It's checking the box unless you pair it with the hardening. I've had scripts flagged post-hardening that looked totally harmless in a normal context, like a simple deployment script that tries to write to a protected directory if it detects a certain service isn't running. Without that real endpoint context, the sandbox just saw it query a service and stop. With hardening, it tried the write and triggered. That's the value, but also the risk if you don't tune your exclusions.
Your caution is justified, and yes, the sandbox does detonate PowerShell scripts, not just executables. That's the checkbox part. The "real layer of protection" part is what's missing without tuning.
The discussion here nails it: the default sterile environment will miss anything with environmental triggers. Where I'd add a new, concrete data point is on the cost of enabling that script hardening. It's not just about false positives for admin scripts; it adds a measurable 300-800ms of latency to every single script execution on your endpoints while the deobfuscation runs. For an MSP, you need to factor that cumulative performance tax across all clients. It can make systems feel sluggish during deployments.
So, it's a real layer *if* you deploy and accept the overhead of hardening, and *if* you manage the resulting exclusions list. Otherwise, for unknown scripts, it's largely theater.
Show me the benchmarks
Your caution is well-founded. To answer your direct question, the sandbox does detonate PowerShell scripts, not just executables. However, its analysis of unknown or obfuscated scripts without the hardening module is fundamentally limited.
The core issue is that static script analysis occurs before detonation. If a script is heavily obfuscated, the system only sees the benign outer wrapper designed to run in the generic sandbox VM. You'll get a report showing harmless activity because the real malicious logic was never unpacked for execution. The hardening feature acts as a forced deobfuscation step on the endpoint prior to submission, making the actual payload visible to the sandbox engine.
So, it's not merely a checkbox, but it is a checkbox that requires you to check several other boxes in your policy configuration to become effective.
null
Your caution is spot on. It does detonate scripts, not just exes, but that's the easy part. The real cost isn't in the feature itself, it's in the mandatory performance tax from the hardening module to make it work.
You're an MSP, so you're billed on time. You enable hardening to catch the unknown scripts, and now every single script execution on every client endpoint adds that 300-800ms delay. That's a tangible, cumulative drag that will generate support calls about "slow systems" during legitimate admin work. Have you quantified that hidden cost against the value of catching a few more scripts?
Show me the bill
You're right to be cautious, and everyone's hit the nail on the head about hardening being the key. I'd add a practical step from our experience.
You can't just flip on hardening for everyone. We set it to only trigger on scripts from untrusted locations or those downloaded from the internet. That cuts down a lot on the performance hit for routine admin tasks while still catching the sketchy stuff that usually needs analysis. It's not perfect, but it makes the whole system more usable day-to-day.
The sandbox alone? Yeah, it's basically a checkbox for anything clever.
> slips through as "non-executable."
Yep. The sensor logic is boneheaded like that. They treat it as a text file, unless you've got the agent set to force everything through AMSI. Even then, a one-liner that downloads and invokes is basically invisible.
The checkbox isn't just about missing behavior - it's about missing the script entirely.