Investigation of McAfee Endpoint Agent and Powershell interaction

Recently I came across the logs issued by my McAfee Endpoint Agent that looked suspicious to me. It looked like this.

So, svchost.exe started powershell.exe. Based on our corporate policy, this action wasn't blocked. Still, I was not aware there is a powershell running on my laptop in the background. Also the fact it was run by a system process raised an alarm. I decided at this point to investigate what is actually going on here.
The first step was to run a process monitor and observe what is powershell.exe doing. Maybe I can get some idea from the detailed dump from process monitor what exactly it is doing, which script it executes etc. I stared process monitor with filter set to process name "powershell.exe".

And indeed, powershell was loading some system DLLs,creating, reading some registry keys etc. The detail that attracted my attention here was the process conhost.exe - very similar to cmd.exe, so another command shell. The whole dump from Process Monitor was exported into Excell to allow easier search. After trying various strings, mostly "*.ps1", "powershell.exe" and many others, I detected the following content.

Powershell.exe executes the script loaded on the shared drive of our corporate server. At that time I was pretty sure there was nothing malicious here, but still , I wanted to understand what is this script doing.

After loading the script from this folder into my text editor, it was indeed just a benign check if the specific windows update service was running or not. Further, my intention was to discover what exactly happens on the network level, mainly, to understand what processes are required to control this script execution - we knew powershell.exe and conhost.exe were involved- was there anything else.

It seems there is - first I ran netstat to check established SMB connections (tcp port 445) because I saw the script is executed from a shared folder on Windows. I also ran Wireshark in parallel to see what this SMB communication does. All pretty standard stuff, but I still don't know what process handles the SMB communication. Several experiments were done in Process Monitor to isolate the process responsible for SMB communication, but it was not powershell.exe nor conhost.exe. After a lot of attempts with filters on process IDs, process names , all correlated with time when powershell.exe was started I found out it was the System (PID=4) that does SMB session.

Given that McAfee logs were showing entries at precisely the same time every day, I assumed this execution was defined in the Windows scheduled tasks.

One more thing that was left to find out was how did the McAfee capture those events in its log. Once again I needed to call Process Monitor in help and trace the processes accompanied with powershell.exe and System (PID=4).

Note the entry with powershell.exe looking into registry key. The key is labelled as McAfee, so I good chance we may find the missing link responsible for logging. Let us investigate the registry and try to figure out what these keys are.

Note the "Data" field - all contain the key word "IPSAppHookRule". Intuitive enough, some kind of API hooking is in place so that McAfee endpoint client can intercept the process calls (not API calls!) and, my assumption here, to inspect the process name to be executed. A quick look into the key value for powershell.exe is this.

Let us check some hypotheses here - is the hooking tied to the process name? If so, then it detects every invocation of powershell.exe. What would happen if I simply rename the file? Let us do that.
I found the process that calls the powershell script , copied powershell.exe into "powershell2.exe", edited scheduled tasks and let the scheduler run at its programmed time.

It is important to note here that renaming or copying powershell.exe to powershell2.exe required local Admin privileges. A quick check above proves that powershell.exe shall not execute, but powershell2.exe will. I went on to use powershell2.exe in the scheduled tasks.

After this intervention, the scheduler ran as usual, this time running the same task with powershell2.exe instead of powershell.exe and the logs in McAfee were at this stage were no longer appearing. Also, any manual run of powershell2.exe did not produce any alarm logs.
At this stage I decided to check with McAfee if they view this as a vulnerability or is this protection mechanism purposely designed to inspect only the static name of the process. I opened the case with them, and they replied as follows indicating this is not considered a vulnerability.

In fairness, I can agree to a certain degree with their view - this is only one stage of protection that they designed to recognise the name of the process. Nothing else in this first step inspection process. In addition, one would require local administrative privilege to rename/copy the file from C:\windows\system32.  From my humble knowledge and research of the McAfee Endpoint agent, I am sure it does the second level protection in terms of heuristic analysis and behaviour anomalies. This means that even though one bypassed the process name restriction, and one ran some suspicious actions with this renamed process, the Agent would still analyse what the process is doing - if anything malicious, it would most likely prevent the action. This last step (heuristic inspection) was not in the scope of this investigation and I cannot confirm that it either did or did not kick in.