Forum Discussion
SentinelOne detected \Config.Msi\4e6142cc.rbf as Ransomware in Windows Server
Hi,
Recently, one of our Dell Windows servers triggered a critical ransomware detection in SentinelOne. Here are the specific alert details:
File Path: \Device\HarddiskVolume3\Config.Msi\4e6142cc.rbf
Originating Process: msiexec.exe (SupportAssist_x64.msi)
SentinelOne Alert Summary:
The alert indicates a critical detection on the Windows server involving an unsigned file (4e6142cc.rbf) located in the system's MSI configuration directory. Executed under the NT AUTHORITY\SYSTEM context by msiexec.exe (associated with SupportAssist_x64.msi), the file was flagged as ransomware under a "User-Defined Blocklist" policy with a malicious confidence rating. The system highlighted potential ransomware activity utilizing MSI installer processes, prompting immediate enforcement and investigation.
We attempted to remove the file, but it reappears periodically, likely triggered by background installer/update tasks.
Has anyone encountered similar alerts with Dell SupportAssist or SentinelOne? Is this a known false positive associated with MSI rollback (.rbf) files, or is further remediation required?
Any insights or recommendations would be greatly appreciated.
Many thanks,
Sebastian
1 Reply
An .rbf file in Config.Msi can be consistent with Windows Installer rollback activity: Microsoft documents that installation creates rollback information and copies of files needed to reverse changes. However, that context does not establish that this particular file or SupportAssist installation is safe. An msiexec parent process and SYSTEM execution are not sufficient to dismiss a ransomware alert. Preserve the detection, file hash, installer source, process tree and installation timestamps rather than repeatedly deleting the file and losing evidence. Ask your security team to inspect the User-Defined Blocklist rule that actually triggered, and submit the relevant sample or hash privately through your security vendor's review process. Verify the installer against the official vendor package before rerunning it. Keep containment and protection in place until the investigation is complete. If there are signs of broader compromise, follow your incident-response process rather than adding an exclusion.
