Where to get more information on "Behavioral threat detected (rule: create_renamed_script_engine_by_hash)"

[SGarringer]

Hello Cortex users, wondering if anyone has seen this before?  We are getting a single host flagged with a large amount of "Behavioral threat detected (rule: create_renamed_script_engine_by_hash)" but when we investigate in Cortex XDR there is almost no information to go on.  The process shows ::1 for the value, no path, command, PID, TID, MD5.  Signature is unavailable. It's not giving us much to go on.

We looked at the host and didn't see anything in particular in the System/Application/Security event logs, nothing repeating at the times the events fires.  We were seeing it up to every about 5 minutes last night.

Any guidance on what we can zero in on, I can't find any other references to this specific alert.

Thanks!

[KanwarSingh01 · Accepted solution]

@SGarringer What cortex licenses version are you using? Seems Prevent.

Can you take a look at the prevention folder in c:\ProgramData\Cyvera\Prevention Folders and look into the prevention alert which is generated around that time, this will give a little bit of more information for your investigation around the alert.

According to me this alert triggers when you have a hash of a process which is similar to wscript.exe, cscript.exe, cmd.exe or powershell.exe (scripting engine process) but the "process name" is not a scripting engine process but has a same hash value. When triggered by a suspicious parent process as setup in PA Cortex defined rule set.

hash of cmd.exe == hash of blahh.exe (Trigger Rule.) if the parent is x, y or z.exe (Something like this.)

List of scripting engine:

https://attack.mitre.org/techniques/T1059

You will come to know more about the story when you take a look at the prevention alert data in the folder which i have mentioned.

[SGarringer]

This was exactly the information we needed.  In this case it was an SCCM folder that we needed to exclude as per best practices from Microsoft.  We've done that now and hopefully that will resolve the issue.  It's unfortunate that the file information doesn't flow back into Cortex XDR for easy viewing and instead we have to pull these files.  I'm new to supporting Cortex XDR Protect so that's great to know about the additional info in those files.