Process Explorer - ProcExp152.sys Driver Flagged As Vulnerable

Marc Denman 76

Hello-

We are leveraging a new security solution in our environment that adds protection to our endpoints. The XDR solution has a rule that is detecting the driver ProcExp152.sys as being "vulnerable". I have asked our security vendor to better explain and was provided this explanation.

The driver load/write that is blocked by this rule is a driver that has a known vulnerability in it. an attacker can use this vulnerability to gain privilege escalation and (among other things) disable the XDR agent.

So my question is: Does this driver in fact contain a known vulnerability and if so, if there a newer version which was fixed?

Christian 16 Reputation points

2023-10-31T07:43:42.0666667+00:00

Our XDR reports this:

CortexXDR - Generic Usecase with 2 'Impair Defenses - 3645069560' alerts prevented by XDR Agent on host <hostname> involving user n/a system at 2023-09-04 12:35:23. Threat Analysis: Tampering capable driver with the original name 'procexp.sys' was loaded to the system at 2023-09-04 12:34:57 and 2023-09-04 14:38:17 from following Path: Type : Load Load Path : C:\WINDOWS\system32\Drivers PROCEXP152.SYS This driver was loaded from Process Explorer Application (Sysinternals) <some folder> procexp64.exe Measures done by InfoGuard AG SOC: Some of the procexp.sys drivers are vulnerable to the attack technique called 'Bring Your Own Vulnerable Driver' (BYOVD). Attackers may install a legitimate kernel driver and exploit its vulnerability to gain kernel access. We checked the logs around the time of the incident and could not find anything suspicious.

cross-linking this thread here: https://learn.microsoft.com/en-us/answers/questions/1346514/procexp152-sys-driver-cannot-load-due-to-security

and linking more detailed report: https://news.sophos.com/en-us/2023/04/19/aukill-edr-killer-malware-abuses-process-explorer-driver/

I did not noticed any limitations (without the driver being loaded) while using this tool, is there anything that should be noticeable?
joseph brewer 0 Reputation points

2024-02-05T05:11:59.2666667+00:00

This popped up after updating the RECentral App from AverMedia

11 answers

Marc Denman 76 Reputation points

2023-01-13T13:56:58.9933333+00:00

Thanks all for the additional comments/information. I certainly hope someone from the Microsoft team can look into this and offer some explanation or ideas to resolve.

Some additional information that I learned since posting this question originally.

In our cases, the alert was being triggered and execution blocked due to the customers executing ProcessExplorer with elevated privilege (aka "as admin/system"). In this case the driver is loaded with same so is flagged because the driver "could be used by a threat actor to cause harm". Seems when the application is run normally, the issue is not the same as access to manipulate the system via the driver privileges is not available.
Please sign in to rate this answer.

5 people found this answer helpful.

0 comments No comments
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Swiecicki, Tomasz 16 Reputation points

2022-09-28T13:56:20.5+00:00

Code signing certificate expired December 2, 2021 on Procexp64.exe 16.43 (latest). Would it be possible to republish the utils with valid signature?

I have just received the alert and a tip, that the signing certificate may be responsible.
Please sign in to rate this answer.

3 people found this answer helpful.
Marc Denman 76 Reputation points

2022-09-28T22:59:42.643+00:00

Great find. I had not thought about that as a possibility. In my specific case, I have pushed back on my XDR vendor to further validate/explain the "how/why" this was flagged. I raised the questions of:

If this is a known vulnerable driver, why I do not find any CVE's referencing this?
If this is known vulnerable driver, why have you not reached out/worked with Microsoft on the details as I am sure they would be interested in fixing it

I am still awaiting feedback from XDR vendor.

In the meantiime, I am still awaiting feedback from anyone inside MSFT in regards to this post as well.

Thanks.

Aaron Margosis 26 Reputation points

2023-03-02T00:09:08.83+00:00

Sysinternals signatures are timestamped, which means that the signatures remain valid even after a code-signing certificate has expired.

Aditya Mesta 0 Reputation points

2023-10-27T05:39:07.9133333+00:00

Hi @Marc Denman : Did you hear back from XDR vendor to validate/explain the "how/why" this was flagged.

Wayne Dawson 5 Reputation points

2023-10-27T14:56:44.9066667+00:00

@Aditya M We know why it was flagged. It's hash was listed in Cuba Ransomware hashes, which was reported on originally by Blackberry (I believe), and picked up by several Threat Intel services. Those propagated it. The reason why they included it was that as part of the attack chain, it could be exploited to elevate privileges on the host. (It wasn't the only vulnerable software they included hashes for other things that could also be and used). The question on whether it should have been included as an IOC hash is another question. I don't think it should've been handled that way. They should have clearly indicated it and then a patch process could have been used instead of having it added to something would block it without context.

Aditya Mesta 0 Reputation points

2023-10-31T05:31:43.3733333+00:00

How to resolve this Wayne. We are getting many incidents related to this.

Christian 16 Reputation points

2023-10-31T07:38:00.54+00:00

There is no way to "fix" this as consumer, the driver is blacklisted. And renewing any signature will not fix the side-loading-capabilities of this driver in order to avoid further blacklisting.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Stefan Soller 6 Reputation points

2022-09-29T11:26:34.327+00:00

I also have a similar question because the file ProcExp152.sys is also blocked by the security solution of a customer.

The tool handle in version 4.22 from Sysinternals is used there, which installs the ProcExp152.sys driver in version 16.27.0.0, which does not correspond to the latest version. Is this driver version a security problem or not? Is there an updated version of handle.exe that includes the latest driver?

Does anyone know of a Command Line / PowerShell command to unload the system driver without rebooting?

Many Thanks.
Please sign in to rate this answer.

1 person found this answer helpful.
Dominic Erni 0 Reputation points

2023-01-24T14:25:22.9566667+00:00

@Stefan Soller What about this: To unload a system driver without rebooting, you can use the devcon.exe tool provided in the Windows Driver Kit (WDK). To use devcon.exe, open a command prompt as an administrator and then run the following command:

devcon.exe -r unload <driver name>

Replace <driver name> with the name of the driver you want to unload.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Henk Poley 6 Reputation points

2023-01-13T13:34:48.41+00:00

Just a heads up that apart from Elastic Endpoint Security Solution, now also Sentinel One blocks PROCEXP152.SYS by default. Even for the legitimate Process Explorer loading this driver.

Maybe discuss with them what the issue is, and how to resolve it?
Please sign in to rate this answer.

1 person found this answer helpful.
Scot Harkins 5 Reputation points

2023-03-01T19:36:30.0333333+00:00

Cortex XDR here, too, triggering for PE 17.0.2 when running elevated privs. Does not trigger for limited user startup.

Lowell Picklyk 10 Reputation points

2023-03-01T21:06:06.6666667+00:00

Yeah, S1 has been blocking this since late last year at least. Kind of wish MS would get on with fixing this.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Lowell Picklyk 10 Reputation points

2023-01-19T17:36:39.4966667+00:00

We're seeing this issue as well. Looks like it may only happen when PE is run as an administrator.
Please sign in to rate this answer.

1 person found this answer helpful.
Scot Harkins 5 Reputation points

2023-03-01T18:03:54.74+00:00

I have confirmed this behavior for PE 17.0.2. The trigger only trips if either the binary is launched with "Run this program as an administrator" property set or from within PE when selecting File > Show Details for All Processes, which relaunches PE with elevated privs.

The vuln I see for "ProcExp152.sys" indicates it would be created in Sys32, but I see no indication of such an object being created there or in any subs. I check from an admin cmd with various iterations of dir, mostly 'dir /a:S /s', and no procexp* anywhere in the tree.

The short vuln report from our Cortex XDR tool calls out "procexp.sys", also not found anywhere on the computer.

I've asked our InfoSec resource to check with Palo Alto Networks about the status of the trigger. I am under the impression the core vuln was resolved by MS...but that may be only to do with the driver block list updates being stalled for some of the Windows OS trees.

At this time the status is that procexp.exe 17.0.2 (and older from another server) is flagged by XDR tools for the procexp.sys or procexp152.sys driver when PE is launched with elevated privs.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Process Explorer - ProcExp152.sys Driver Flagged As Vulnerable

11 answers

Your answer