Possible FP with Intel driver?

[Gregecslo 8]

Ummm I highly doubt that something is trying to exploit something on my devices...

We also have separate xdr which is silent and it should report something suspicious...

Also eset sysinspector showed nothing abnormal...

Driver was accessed by compatelrunner and wmipvrs...

[NetworkBear 0]

I have to agree with Gregecslo. As far as I can tell, ESET simply seems to be flagging and deleting (in my case) the vulnerable driver file whenever ANYTHING tries to interact with it. I have confirmed this while installing IME updates, checking the IME version, etc.  Of course, the file comes right back, and around we go.

[Gregecslo 8]

Yes, that seems to be correct, it doesn`t matter what proccess touches the driver at all...

So previous statements made by Marcos and Itman are NOT correct.

Scanner: Real‑time file system protection
Action performed: Cleaned by deleting
Object type: File
Object uri: file:///C:/Windows/System32/drivers/pmxdrv.sys
Proccess: C:\Windows\explorer.exe

Edited May 9 by Gregecslo

[Gregecslo 8]

Also I have Lenovo notebook and their software updater shows my notebook as fully updated.

[itman 1,721]

2 hours ago, frapetti said:

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

This confirms my suspicion that deleting the vulnerable driver download is not enough since the source will keep trying to download the driver.

What Eset needs to do is detect what is starting the WmiPrvSE.exe, or whatever LOLbin being deployed, download and kill and remove that process..

[itman 1,721]

4 minutes ago, Gregecslo said:

Yes, that seems to be correct, it doesn`t matter what proccess touches the driver at all

The source process can be any Windows process; i.e. LOLbin, capable of performing remote downloading.

[Gregecslo 8]

Emmm in my case when driver was deleted on my own machine, no more detections were made.

I OPENED EXPLORER AND RIGHT CLICKED ON C:/Windows/System32/drivers/pmxdrv.sys AND THAT IS WHEN DETECTION HAPPENED.

Below I tried with VLC, so no lolbin...
Then I tried with notepad++, same detection...

Whatever, eset is just deleting driver no matter what procees is touching it.

It doesnt need to be windows lolbin.

[Gregecslo 8]

And with notepad

[itman 1,721]

10 minutes ago, Gregecslo said:

I OPENED EXPLORER AND RIGHT CLICKED ON C:/Windows/System32/drivers/pmxdrv.sys AND THAT IS WHEN DETECTION HAPPENED.

Submit pmxdrv.sys to VirusTotal. If there are no detections there, this Eset detection is indeed a false positive.

Edited May 9 by itman

[Gregecslo 8]

Hash of the file:

SHA-1

9e5fcaea33c9a181c56f7d0e4d9c42f8edead252

SHA-256

b1a8ee1222eea5f199028d90b9b77c2acf46d6d84a9e125403b2888c6f681c72

 

 

Again, we have also 3rd party XDR solution which would alert on something like this

[Gregecslo 8]

It is the same file as in my first post.

And that very same file was detected on 10-20 computers in my org...

And will be detected like on all computers if I don`t exclude it.

Edited May 9 by Gregecslo

[Gregecslo 8]

I  never argued that it is not vulnerable.

This same driver is on 1 week newly formatted lenovo notebook as well. Up to date with lenovo system update software.

I just said that if detected it doesn't mean it is being exploited.

In my case it is not exploited.

[itman 1,721]

2 minutes ago, Gregecslo said:

I just said that if detected it doesn't mean it is being exploited.

In my case it is not exploited.

Correct. Because Eset is blocking any access to the driver.

I erred in that I said Eset is deleting the driver. It is not. This is why the alerts keep appearing.

[Gregecslo 8]

I have configured that this type of detection gets deleted... So when deleted no more warnings appear.

[itman 1,721]

52 minutes ago, Gregecslo said:

I have configured that this type of detection gets deleted... So when deleted no more warnings appear.

As long as this is not a detection exclusion, I guess it's OK.

Edited May 9 by itman

[itman 1,721]

I believe this needs to be said. Do you really need to rely on Eset vulnerable driver protection?

In Win 10 with HVCI - Memory integrity enabled, it will block any attempted loaded driver code modification. Likewise in Win 11, the same is enabled in addition to the Vulnerable Driver Blocklist setting enabled in the same section.

Quote

Starting with Windows 10 (KB5018482) and Windows 11 (KB5018483 and KB5018496), the Microsoft Vulnerable Driver Blocklist is enabled by default.

The vulnerable driver blocklist is also enforced when either memory integrity (also known as hypervisor-protected code integrity or HVCI), Smart App Control, or S mode is active. Users can opt in to HVCI using the Windows Security app, and HVCI is on by-default for most new Windows 11 devices.

The vulnerable driver blocklist is designed to help harden systems against third party-developed drivers across the Windows ecosystem with any of the following attributes:

• Known security vulnerabilities that can be exploited by attackers to elevate privileges in the Windows kernel
• Malicious behaviors (malware) or certificates used to sign malware
• Behaviors that aren't malicious but circumvent the Windows Security Model and can be exploited by attackers to elevate privileges in the Windows kernel

 

https://www.elevenforum.com/t/enable-or-disable-microsoft-vulnerable-driver-blocklist-in-windows-11.10031/

Refs.: https://techcommunity.microsoft.com/t5/microsoft-security-experts-blog/strategies-to-monitor-and-prevent-vulnerable-driver-attacks/ba-p/4103985

https://learn.microsoft.com/en-us/windows/security/hardware-security/enable-virtualization-based-protection-of-code-integrity

Edited May 11 by itman

[itman 1,721]

I realized there is a "gotcha" in regards to Microsoft Vulnerable Driver Blocklist use not being disclosed. That is your worst driver vulnerability; one in a device driver.

As I see it, Windows is applying the Vulnerable Driver Blocklist via its AMSI driver. The problem is the AMSI driver loads at system startup time after all device drivers have loaded. As such, it is incapable of blocking vulnerable device drivers. Ditto for Eset's AMSI driver.

Assumed this vulnerable Intel driver is a device driver and can't be blocked loading at boot time. If blocked at boot time, it would also most likely blue screen the device.

Edited May 11 by itman

[itman 1,721]

I'm going to give Eset a "pass mark" on its vulnerable driver detection upon any process access attempt. Here's why.

I went back and reviewed the KUD article. Of note, the screen shots showing the actual exploit in action. I noticed that the provider driver being used was RTCore64.sys and it was being loaded "on the fly." This driver is the vulnerable MSI Afterburner utility driver exploited in a number of BlackByte ransomware attacks.

Now let's simulate use of the vulnerable MSI driver being dropped on a target device and being loaded "on the fly" w/o KDU use. I found the vulnerable driver here: https://www.loldrivers.io/drivers/e32bc3da-4db1-4858-a62c-6fbe4db6afbd/ which includes instructions on how to load the driver "on the fly." The first thing to note is what is downloaded is a .bin file. It is not detected by Eset upon download. Nor is it detected by anyone at VT except Dr. Web and Elastic. Assume that those detection's are by hash.

Upon access of the .bin file via Win Explorer to check its Properties, the file was loaded in memory and Eset detected it:

Quote

Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here
5/12/2024 9:35:17 AM;Real-time file system protection;file;C:\Users\xxxxxx\Downloads\2d8e4f38b36c334d0a32a7324832501d.bin;Win64/MicroStar.A potentially unsafe application;cleaned by deleting;xxxxxxxx;Event occurred during an attempt to access the file by the application: C:\Windows\explorer.exe (8B6A425A69E0F805291505B3F98B107652C2FA01).;F6F11AD2CD2B0CF95ED42324876BEE1D83E01775;5/12/2024 9:24:32 AM

Again, the known vulnerable driver exploits presently do not work with HVCI - Memory integrity enabled. But detecting the vulnerable driver on the disk will prevent any future unknown driver exploits from succeeding.

Edited May 12 by itman

[Sec-C 6]

We were looking for the cause and found there where some critical "Intel Management Engine Firmware" Updates in 2023. Lenovo seems to use a vulnerable driver to patch their vulnerable Intel-ME Firmware: https://download.lenovo.com/pccbbs/mobiles/n20rg24w.exe
The "Lenovo vantage" updater still presents this package to unpatched devices.

[itman 1,721]

1 hour ago, Sec-C said:

Lenovo seems to use a vulnerable driver to patch their vulnerable Intel-ME Firmware: https://download.lenovo.com/pccbbs/mobiles/n20rg24w.exe

Refers to Intel Management Engine 11.8 Firmware - Package 1.5.11.5 .

Again, has anyone contacted Lenovo about this? It's obvious to me Lenovo believes the vulnerability was with the Intel Management Engine and not the driver it uses,

Edited May 15 by itman

[frapetti 1]

3 hours ago, itman said:

Refers to Intel Management Engine 11.8 Firmware - Package 1.5.11.5 .

Again, has anyone contacted Lenovo about this? It's obvious to me Lenovo believes the vulnerability was with the Intel Management Engine and not the driver it uses,

I wrote Lenovo about the problem with this particular machine, but the answer from Lenovo is not very helpful. The computer is 5 years old, however: https://forums.lenovo.com/t5/ThinkPad-X-Series-Laptops/Vulnerable-driver-found-in-X1-Carbon-6th-Gen-notebook/m-p/5308580?page=1#6340257

[NetworkBear 0]

33 minutes ago, frapetti said:

I wrote Lenovo about the problem with this particular machine, but the answer from Lenovo is not very helpful. The computer is 5 years old, however: https://forums.lenovo.com/t5/ThinkPad-X-Series-Laptops/Vulnerable-driver-found-in-X1-Carbon-6th-Gen-notebook/m-p/5308580?page=1#6340257

This issue seems to affect only 6th to 8th gen intel CPU's, if I read that first intel advisory correctly (assuming it is still the valid advisory for the current issue), so the problematic endpoints will all be several years old now. I could reach out myself, but I'm very much dreading having to deal with lvl1 Lenovo support for something like this, as I assume I will get the same run around you received. If I can find some time to open the support case, I will update this thread with our results.

Otherwise I did notice there is a new bios update for my T480s a few days ago that mentions several fixes for CVE's, but i have not had the time to browse through that list yet. I assume the fix for this vulnerable driver would be in an IME update from Lenovo though, and not a BIOS update.

[itman 1,721]

On 5/15/2024 at 2:16 PM, frapetti said:

I wrote Lenovo about the problem with this particular machine, but the answer from Lenovo is not very helpful.

I love Lenovo's suggested mitigation;

Quote

Try downgrading the OS build version since it is listed as compatible to upgrade up to Windows 10/11 21H2 only: 

Reading "between the lines" what Lenovo is stating is the device is no longer actively supported. As such, they are not going to go through the expense for creating firmware compatible with later Win OS versions that contain a non-vulnerable driver. I also state it's a bunch of B.S.. As noted above;

Quote

We were looking for the cause and found there where some critical "Intel Management Engine Firmware" Updates in 2023.

contains a vulnerable pmxdrv.sys driver.

Now, let's "cut to the chase' to what Lenovo is implying. These OS versions, Windows 10/11 21H2, were the last versions vulnerable to kernel driver memory patching. All Win 10/11 versions thereafter will prevent it via HVCI - Memory integrity option. As such, Lenovo feels there is no reason to create a non-vulnerable driver. The problem with relying on HVCI - MI is it can be auto disabled for a number of reasons; running BIOS memory timings at higher than stated specifications, a boot loaded driver that is incompatible with it; etc.. -EDIT- Only on Win 11 22H2+ will you receive indication that HVCI - MI has been disabled;

Quote

Beginning with Windows 11 22H2, Windows Security shows a warning if memory integrity is turned off. The warning indicator also appears on the Windows Security icon in the Windows Taskbar and in the Windows Notification Center. The user can dismiss the warning from within Windows Security.

https://learn.microsoft.com/en-us/windows/security/hardware-security/enable-virtualization-based-protection-of-code-integrity

Also in regards to Intel processors,  the Windows HVCI vulnerable driver blacklist feature only works on systems with a 7th gen + Intel CPU.

Edited May 16 by itman

[itman 1,721]

Here's today's find and I beleive it's a big one for Lenovo users.

There appear to be two driver versions for this Intel Management software; pmxdrv.sys - 32bit and pmxdrv64.sys - 64 bit. It appears that Lenovo never updated the pmxdrv.sys driver.

You need to verify which driver version is actually being loaded on your system; also there should be a pmxdrv64.sys in the Win driver directory. If it's pmxdrv64.sys, pmxdrv.sys can be deleted from the Win driver directory; I would save it to off-line storage first just to be safe.

Edited May 16 by itman

[Matevzg 2]

On 5/16/2024 at 11:05 PM, itman said:

Here's today's find and I beleive it's a big one for Lenovo users.

There appear to be two driver versions for this Intel Management software; pmxdrv.sys - 32bit and pmxdrv64.sys - 64 bit. It appears that Lenovo never updated the pmxdrv.sys driver.

You need to verify which driver version is actually being loaded on your system; also there should be a pmxdrv64.sys in the Win driver directory. If it's pmxdrv64.sys, pmxdrv.sys can be deleted from the Win driver directory; I would save it to off-line storage first just to be safe.

Has anyone tried this?