Did anyone else get hit by this?
Last night we started seeing a huge number of alerts in InsightIDR triggered by the “Suspicious Process – PowerShell IO.MemoryStream” detection, which seems to have been recently pushed by Rapid7.
It looks like a non-productive rule that’s generating tons of false positives. We’re already in touch with Rapid7 for clarification, but honestly… this isn’t the first time in the past year and a half, and it’d be great if they gave us a heads-up or some explanation before rolling out detections like this.
Yep, we’re having the same issue here. I’ll raise a ticket with support
EDIT: The last modify date on the rule appears to be Tuesday 15 April 2025 at 9:28:17 UTC so I’m not sure whats changed here to cause these detections.
OK, agreed on the date. I’ve just gone back to check this and the Rule Last Modified in the individual alerts says April, but if you check the rule in Detection Rules it shows 16th October. Not entirely helpful - I’ll make a mental note to check both next time!
I’ve got a reply from Support - multiple customers are reporting this. They’ve suppressed the alerts while investigating what they suspect is benign behaviour. I’ll update here once they confirm.
Support has roller out an update to the alert containing:
NOT (
process.cmd_line
ICONTAINS-ANY [
“Diagnostics.Eventing.Reader”,
“Get-UEFIDatabaseSigner”,
“UEFISecDatabaseParser.ps1”,
Yes sir. I started seeing a bunch of alerts last night for this rule:
Suspicious Process - PowerShell IO.MemoryStream
Turns out they where all FP.
Here is my analysis on it if interested:
The parent process was: C:\windows\system32\compattelrunner.exe -m:appraiser.dll -f:DoScheduledTelemetryRun -cv:U99n7VhDQUmHtxpz.0.1.3
Which launched Powershell.
PowerShell launched under SYSTEM by CompatTelRunner.exe (Windows telemetry binary) – uncommon parent-child combination that merits scrutiny.
Script is in clear text (no obfuscation) but reaches deep into firmware (Get-SecureBootUEFI) to enumerate Secure-Boot certificate store – activity rarely needed outside diagnostics or security checks.
Runs with full SYSTEM privileges, giving potential to tamper with UEFI variables if script were modified; indicates high-impact capability.
No destructive actions observed, only enumeration, and command line sets ExecutionPolicy to ‘Restricted’ (default) rather than ‘Bypass’, reducing malicious indicators.
Lack of additional context (signed script, Microsoft provenance, scheduled task details) prevents confidently labeling as benign telemetry; therefore flagged for further investigation.
these alerts were false positives and posed no security risk to your environment.
The alert spike was caused by the latest Windows Patch Tuesday cumulative update. Specifically, the update executed compattelrunner.exe, which, in turn, ran PowerShell scripts to update Secure Boot certificates. These legitimate Windows maintenance processes involved memory stream operations that, unfortunately, closely resembled the pattern of malicious activity our rule is designed to catch. We also observed this same false trigger during forced Windows 11 update attempts.
Our team quickly identified the root cause and pushed an update for our detection logic at 02:14 UTC, halting the unnecessary alerts.
We apologize for the inconvenience and the noise in your security console. We’re refining our rule logic to ensure benign OS maintenance activities like this are automatically filtered out in the future.
Thanks David
“The alert spike was caused by the latest Windows Patch Tuesday cumulative update. Specifically, the update executed compattelrunner.exe, which, in turn, ran PowerShell scripts to update Secure Boot certificates. These legitimate Windows maintenance processes involved memory stream operations that, unfortunately, closely resembled the pattern of malicious activity our rule is designed to catch. We also observed this same false trigger during forced Windows 11 update attempts.”