Jump to content

Possible FP with Intel driver?


Go to solution Solved by Marcos,

Recommended Posts

Posted (edited)
Hash
9E5FCAEA33C9A181C56F7D0E4D9C42F8EDEAD252
 
Name
Win64/Intel.N
Detection Type
Potentially unsafe application
Object type
File
Uniform Resource Identifier (URI)
file:///C:/Windows/system32/drivers/pmxdrv.sys
Process name
C:\Windows\System32\wbem\WmiPrvSE.exe
Edited by Gregecslo
Link to comment
Share on other sites

  • Gregecslo changed the title to Possible FP with Intel driver?
  • Administrators
  • Solution

The detection is correct. It's a vulnerable driver from 2019. Please check if a newer version is available which might have the vulnerability already fixed.

Link to comment
Share on other sites

Posted (edited)
2 hours ago, Matevzg said:

have you found to which drivers this refers to?

First, what is the driver vulnerability: https://www.zdnet.com/article/flaw-in-intel-pmx-driver-gives-near-omnipotent-control-over-a-victim-device/ .

Next, what uses the PMx driver;

Quote

pmxdrv.sys is a component of the INTEL-SA-00086 Detection Tool included in SA00086_Windows.zip in case anyone else is wondering where it came from. That is the Hyperthreading Bug detection Tool. Possibly included in other Intel tools.

Finally, Intel's advisory publication on the vulnerability: https://www.intel.com/content/www/us/en/support/articles/000025619/software.html . As noted in the article, a software and/or firmware update is required to mitigate this issue. The update must be provided by your PC manufacturer.

Edited by itman
Link to comment
Share on other sites

I'm constantly getting the "potentially unsafe application" message in one Lenovo X1 Carbon 6th Gen laptop, and their support website says that there are no new versions of any drivers. When checking the file from ESET PROTECT in virustotal, it sends me here: https://www.virustotal.com/gui/file/b1a8ee1222eea5f199028d90b9b77c2acf46d6d84a9e125403b2888c6f681c72/details

Is this really a vulnerable version, or why is this message showing every 1 second? How do i get rid of it? Can i delete the pmxdrv.sys file, or something like that?

Regards

Link to comment
Share on other sites

6 minutes ago, frapetti said:

I'm constantly getting the "potentially unsafe application" message in one Lenovo X1 Carbon 6th Gen laptop, and their support website says that there are no new versions of any drivers.

Did you check here: https://support.lenovo.com/us/en/product_security/len-17297 per provided link in the Intel advisory?

Link to comment
Share on other sites

Posted (edited)
2 hours ago, frapetti said:

Yes, but the ThinkPad X1 Carbon 6th Gen is not listed there.

Contact Lenovo directly on the issue.

-EDIT-

Based on this;

Quote

X1 Carbon (6th Gen)     20KH, 20KG     January 2018

https://support.lenovo.com/us/en/solutions/hf004081

Your PC wasn't publically released until Jan. 2018. As such, it wouldn't be listed on the Levono advisory issued in 2017.

Edited by itman
Link to comment
Share on other sites

Some of these events have to be false positives.

It triggered on my PC with the latest driver from March 2024 and on an affected PC I updated the driver with a driver from February 2024 and it still triggered the event.

Link to comment
Share on other sites

1 hour ago, Marcos said:

Then it's very likely that the vulnerability has not been fixed yet. Please upload the latest driver to https://www.virustotal.com and provide a link to scan results.

 

Here's the scan: https://www.virustotal.com/gui/file/b1a8ee1222eea5f199028d90b9b77c2acf46d6d84a9e125403b2888c6f681c72

Intel Management Engine Driver version: 2336.5.2.0

Link to comment
Share on other sites

Posted (edited)
4 hours ago, thae said:

Here's the scan: https://www.virustotal.com/gui/file/b1a8ee1222eea5f199028d90b9b77c2acf46d6d84a9e125403b2888c6f681c72

Intel Management Engine Driver version: 2336.5.2.0

This is the same driver that the VT link posted at the beginning of this thread showed zero detection's. It dates to 2018. Appears Lenovo hasn't updated the driver since then.

It is also odd that Eset doesn't detect the driver at VT.

Again referring to the first posting in this thread, what is suspect is that it appears WmiPrvSE.exe is attempting to load this driver or access it in some way. I wonder if this is what is triggering the Eset alert?

Edited by itman
Link to comment
Share on other sites

To further clarify my suspicions.

At the the time vulnerable driver was in existence, it was detected that exploitation of it was being done via WMI. Eset in turn created a Sigma/YARA-like behavior signature to detect access of the driver via WmiPrvSE.exe.

Currently, this behavior signature is being triggered. It is entirely possible a new vulnerability has been discovered in the patched driver and is being exploited. This is something Eset needs to check out ASAP.

Link to comment
Share on other sites

Yeah, something is up with these detections.

We have just started seeing this pop up on several Lenovo endpoints that have never been flagged for this detection before yesterday. All these endpoints are up to date using Vantage or system update (using IME FW version 11.9.82.4222 on the device I have investigated).

I was going to assume these were false positives, but the Intel verification tool from the Intel advisory page also seems to suggest there is a vulnerability on the device (if I am reading that result correctly). I have been unable to get the intel check to come up clean on the affected endpoint I have been working on, so far. ESEt also continues to flag the file every time it is accessed (using MEinfo for example)

example affected PC > Thinkpad E470

On my current work PC (Thinkpad T480s) , the Intel check does some up clean, with IME 11.9.04.4494 (also no ESET detections)

I guess we stand by for another update. Hopefully it comes around quickly.

 

2024-05-08_10-21-59.jpg

Link to comment
Share on other sites

Ahh also have this one:

 

Process name
C:\Windows\System32\CompatTelRunner.exe

 

 

File
Hash
9E5FCAEA33C9A181C56F7D0E4D9C42F8EDEAD252
Name
Win64/Intel.N
Detection Type
Potentially unsafe application
Object type
File
Uniform Resource Identifier (URI)
file:///C:/windows/system32/drivers/pmxdrv.sys
Process name
C:\Windows\System32\CompatTelRunner.exe
User
NT AUTHORITY\SYSTEM
Detection Flags
Link to comment
Share on other sites

Posted (edited)
2 hours ago, Marcos said:

We've added a detection on May 6th.

https://github.com/hfiref0x/KDU

A few tidbits from this "trash."

What it can do;

Quote

It features:

  • Protected Processes Hijacking via Process object modification;
  • Driver Signature Enforcement Overrider (similar to DSEFIx);
  • Driver loader for bypassing Driver Signature Enforcement (similar to TDL/Stryker);
  • Support of various vulnerable drivers use as functionality "providers".

 

How it does it;

Quote

How it work

It uses known to be vulnerable (or wormhole by design) driver from legitimate software to access arbitrary kernel memory with read/write primitives.

Depending on command KDU will either work as TDL/DSEFix or modify kernel mode process objects (EPROCESS).

When in -map mode KDU for most available providers will by default use 3rd party signed driver from SysInternals Process Explorer and hijack it by placing a small loader shellcode inside it IRP_MJ_DEVICE_CONTROL/IRP_MJ_CREATE/IRP_MJ_CLOSE handler. This is done by overwriting physical memory where Process Explorer dispatch handler located and triggering it by calling driver IRP_MJ_CREATE handler (CreateFile call). Next shellcode will map input driver as code buffer to kernel mode and run it with current IRQL be PASSIVE_LEVEL. After that hijacked Process Explorer driver will be unloaded together with vulnerable provider driver. This entire idea comes from malicious software of the middle of 200x known as rootkits.

Shellcode versions

KDU uses shellcode to map input drivers and execute their DriverEntry. There are few shellcode variants embedded into KDU. Shellcode V1, V2 and V3 used together with 3rd party victim driver (Process Explorer, by default). They are implemented as fake driver dispatch entry and their differences are: V1 uses newly created system thread to execute code, V2 uses system work items, V3 manually builds driver object and runs DriverEntry as if this driver was loaded normally. Shellcode V4 is simplified version of previous variants intended to be run not like an driver dispatch entry. While theoretically all "providers" can support all variants this implementation is limited per provider. You can view it by typing -list command and looking for shellcode support mask. Currently all providers except N21 support V1, V2 and V3 variants.

Edited by itman
Link to comment
Share on other sites

We are receiving the same alert for Win64/Intel.N potentially unsafe application - 9E5FCAEA33C9A181C56F7D0E4D9C42F8EDEAD252.

Link to comment
Share on other sites

Posted (edited)
22 hours ago, Marcos said:

We've added a detection on May 6th.

https://github.com/hfiref0x/KDU

The question is what is Eset detecting?

Attacker can build their own KDU version from available source code;

Quote

KDU comes with full source code. In order to build from source you need Microsoft Visual Studio 2019 and later versions. For driver builds you need Microsoft Windows Driver Kit 10 and/or above.

Complete working binaries include: kdu.exe (main executable) and drv64.dll (drivers database). They must reside in the same directory that must have R/W access enabled for kdu.exe. All binaries MUST BE compiled in "Release" configuration. In order to use providers that require Microsoft Symbols usage you need to put dbghelp.dll and symsrv.dll from the Debugging Tools For Windows into KDU directory.

 

Edited by itman
Link to comment
Share on other sites

  • Administrators
27 minutes ago, itman said:

The question is what is Eset detecting?

Attacker can build their own KDU version from available source code;

We detect vulnerable drivers exploited by KDU and not KDU itself.

Link to comment
Share on other sites

23 minutes ago, Marcos said:

We detect vulnerable drivers exploited by KDU and not KDU itself.

The problem with this is it's not going to stop the downloading of the vulnerable driver via LOLbin method as shown in this thread. Hence, constant Eset alerts on driver detection and deletion.

Link to comment
Share on other sites

Is there a new vuln. advisory for what this "utility" is exploiting? Surely, it can't be the same exact vuln. as the one mentioned in this thread, as that was (supposedly) patched in any number of IME updates since then. That page was last updated back in November 2023 though.

I am quite perplexed by the fact the intel check tool is flagging systems with the most up do date IME fw as vulnerable, also. I have, however also started getting ESET alerts for endpoints that come up green on that tool...so I am confused now. I assume this tool may not be checking for the new vuln.

I will have to reach out to Lenovo support to inquire (not looking forward to that). If anyone has already done this, please share what information you may have.

Link to comment
Share on other sites

11 minutes ago, NetworkBear said:

I have, however also started getting ESET alerts for endpoints that come up green on that tool.

The problem is something has been installed on these devices; most likely a KDU variant, and it is attempting to create the vulnerable Intel driver and exploit it to gain kernel mode access. Eset detects the vulnerable driver and deletes it preventing the attack.

If the Eset detection alert only occurs once, then the issue has been resolved as far as that device is concerned.

Link to comment
Share on other sites

Posted (edited)

In any case, why is a message shown and logged every time any process has access to the file? Shouldn't the file be reported once instead? I had only one computer in the office showing those messages, and in a few hours there were like 500 detections on the PROTECT console saying that the process C:\Windows\System32\wbem\WmiPrvSE.exe was accessing the file C:/Windows/System32/drivers/pmxdrv.sys

The detection is about a Potentially Unsafe Application, nothing more, so ESET is taking no action other than inform about it.

It seems like i found the original article about the vulnerability: https://eclypsium.com/research/mother-of-all-drivers-new-vulnerabilities-found-in-windows-drivers/ . I wished that manufacturers stopped installing "backdoors" on out of band firmware just because it looks good in marketing. Huge risk vs doubtful benefit for most users.

Edited by frapetti
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...