Tetranitrocubane

So these BIOS files were archived on an HDD within my system - I've changed my GPU twice since ever needing them. The GPU I'm currently running is three generations newer than the one these BIOS files modify. These files have never touched my current GPU, ever. As such, I'm more than happy to delete them. However, the fact that these files have been on my HDD for so long and ESET has never had an issue with them before tells me that something nefarious is going on. ESET has scanned these files literally hundreds of times over the years, and never had a problem with them. Why would ESET flag them now? I doubt that any vulnerability in the files was discovered recently. That makes me think these files have been recently modified by malware. Furthermore, these files were flagged by ESET outside of a system scan, while my system was idle. That makes me even more suspicious - As if something were trying to modify the files when no one was watching. I've performed two full system scans since these detections, but ESET has found nothing else.

Awesome, thank you. An impressive upgrade in efficiency and capability. Excellent work all around!

I've found that full system scans are much faster now. With around ~9,800,000 files, a full system scan used to take approximately 3.5-4.0 hours. After upgrading to 17.1.9.0, I've found that a scan takes just slightly more than an hour. Is this a function of the new multi-threaded scanning capability? Or did settings perhaps get set to something not as exhaustive on upgrade?

This afternoon while not particularly using my computer, I was stunned when suddenly ESET popped up and gave me two extremely worrying warnings about viruses being detected on my system. I was not trying to access the files at the time, and these files have been on my computer for nearly a year (since 2015). They correspond to a BIOS update package that I required for my Nvidia GTX 980 Ti graphics card long, long ago. The virus notifications are as follows: I don't particularly care about these files, so I asked for them to be cleaned. I've sent the quarantine samples to ESET as well. VirusTotal scans for both of the files come back clean: https://www.virustotal.com/gui/file/b01716285d5b4849263a55215e1eb63f45a8206ba30fceb1a2d494c2c00dcd5e?nocache=1 https://www.virustotal.com/gui/file/f2db560a52ef1259dd053b3a0c391669f55dbd29c7f2ed24f21324d41f37f78b?nocache=1 I'm very concerned that this may indicate a deeper system infection spilling over into or corrupting/infecting older files. But the fact that both the hashes discovered and cleaned by ESET return 0 detections on VT seem to indicate that these may not actually be risks? I'm confused, and afraid. With that in mind, I'd ask the following questions: 1) Are these detections legitimate malware? If so, why were they not seen as threats by ESET until *today*, considering they've been scanned every time I've assessed my system for almost a decade? 2) How on earth were these files "accessed" by the windows search process when I wasn't even running a search? 3) These files were part of a backup of BIOS files I needed for my old GPU. Why would they be seen as malicious? Could they be infected, and if so, why would the infected files have the same hash as files seen previously by VT? Notably, first seen by VT in 2011? 4) Are the VT results trustworthy? Why doesn't ESET flag this as malware via VT, when it clearly doesn't like these files during real time scanning? And most importantly: 5) Does this indicate a system compromise or infection? Or is this just some manner of false positive? Thanks in advance for any help.

Thank you Marcos for confirming that it was a false positive! I very much appreciate it!

It is, but that makes it currently inaccessible. Do you mean that I ought to restore the file? In the event that the file is truly malicious, won't that infect my system?

Unfortunately (or fortunately?) the file was deleted by ESET and I cannot upload it to VT. I did submit the file for analysis via the quarantine tab, though. I've searched VirusTotal by the file hash listed in the log file, but this doesn't return any results. The file was updated at a date of about two days ago. It seems no one has submitted it to VT since.

A bit of further investigation: Digging into the Steam DB entry for the latest Portal With RTX update reveals that Depot 2012842 (you need to advance to tab 2) DOES contain the file parsifal.dll, at an expected file size of 116.50 kb, which matches what my machine downloaded (According to the file being held in Quarantine). If nothing else, this seems to indicate that the file was delivered intentionally as a part of this update, and not the result of a trojan or infected component of Steam. I'm still uncertain as to the legitimacy of this file, but malware or no, Steam pushed this file as designed.

I awoke this morning and launched the Steam client on my PC, and began auto-downloading a number of patches, as the software is designed to do. In the midst of the download, ESET popped up to alert me of a malware detection originating from Steam.exe. The details are as follows: Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here 3/16/2024 6:31:54 AM;Real-time file system protection;file;D:\Steam\steamapps\downloading\2012840\bin\parsifal.dll;ML/Augur potentially unwanted application;cleaned by deleting;[COMPUTER NAME REDACTED];Event occurred on a new file created by the application: D:\Steam\steam.exe (558403043F0288ABA3D9A43E9DFA7E109BC0B31A).;F68ECA3E557C9D55DC254054822225016429A4A3;3/16/2024 6:31:19 AM I responded by cleaning via deletion, and copied the file to Quarantine. I also submitted the file to ESET via the quarantine tab. A cursory search of the Steam ID associated with this file (2012840) reveals that this was downloaded as an update to "Portal With RTX". Further investigation of the Steam Download panel lists that the "Portal With RTX" game is showing "Missing Downloaded Files" as an error during the download, indicating that this file (parsifal.dll) was expected, and is now regarded as missing. As Steam.exe is scanning clean, and is fully clear via VirusTotal, I don't believe Steam.exe has been infected, and it looks as if this file was an expected one. Is this a legitimate detection, and if so, does this indicate a compromise of my system? Or is this a false positive? Thanks in advance for any help.

Thanks much, Marcos. I appreciate your help and reassurance. I've updated the program and deleted the old one, so hopefully the vulnerability is eliminated. Out of curiosity, a cursory search of the forums after my post reveals that this has been an issue that others have encountered months ago - For some reason I only had this happen to me today, despite keeping ESET up to date for the last few years. I also launch Process Explorer with Admin privileges first thing on every boot. Is there a reason why this detection would occur so late for me? I haven't changed any options in ESET recently. I'm concerned that something else might be compromising ESETs effectiveness.

So, updating Process Explorer alleviated this issue - The latest version doesn't cause this issue with ESET. I gather this is because the older version of PROCEXP152.SYS was vulnerable. Does the fact that the vulnerable driver was running previously, before ESET alerted me, mean that my system is compromised?

I've run Process Explorer every single day for the last several years. It's the first program I launch on startup - ESET has never had an issue with it. Today it detected Process Explorer as malware for some startling reason. It's flagging a file "PROCEXP152.SYS", which I do not seen at location it specifies. I had to select "Clean" or "Ignore" so I selected "Clean" with the option to copy to quarantine selected - No file showed up in quarantine. It also specifies that this file was being accessed by Procexp64.exe - A file I purposefully launched. VT scan of Procexp64.exe turns it up clean. Can anyone help determine if this is a legitimate threat, or a false positive?

Also observing this myself. I had it happen last night, and once again tonight.

New unpackers do sound like they could be responsible here. One particular file, or kind of file, that I notice taking a LONG time are the self-extracting NVIDIA driver executables. Right now an old copy of the drivers I had downloaded, 471.68 For Win10, are taking an exceptionally long time to scan.

Previously, I would perform a Full System scan and it would be completed in 4 or so hours. I have four different drives that get scanned in the process, three of which are SSDs, one of which is a traditional spinning HDD. The number of items scanned is roughly 9,100,000. Currently I have engaged a full system scan and even after 5 h, it is still scanning only the boot drive. Only 2,600,000 items have been scanned in this time. This represents a drastic reduction in performance and an incredible increase in scan time. I have not altered my settings in the least. The only thing I can think that has changed between these scans is upgrading to 16.2.13.0. What's going on here? Is this an indication of something nefarious having gotten into my system and chewing up the resources? Or did the update make ESET incredibly slow?

Thank you for the prompt reply. I do indeed have the pre-release update channel selected, though I was unaware before you pointed it out, and I'm not sure why. This does explain things, though! Thank you very much.

The knowledge base also indicates that 16.1.14.0 is the latest version. Has the ESET update delivery protocol been hijacked? Is this update legitimate, or suspicious?

ESET Antivirus on Win10 recently pinged me to install version 16.2.11.0 - I do not see an announcement for that version release on this forum, nor do I see version 16.2.11.0 in the changelog on the manual download page. Is this in fact a legitimate download? It seems strange to me that an update of this nature would be pushed on a US Federal Holiday.

For anyone else in the future who might have this issue and comes across this post: After doing some poking around myself, I actually got to the bottom of this this morning. This issue was cause by having the "Removable Media Access" option checked under "Scan on" in the "Files system protection" settings. After turning this off and rebooting, the system returned to normal operations. From what I could gather, having this option selected meant that at boot, the entirety of my external Time Machine drive was being scanned silently. When Time machine then attempted to launch a backup at the same time, the combination of these simultaneous scans and backups ground the system to a halt. Checking my backup logs, none of my iterative backups had completed since I upgraded to 7.3.3700.0, which is when I selected this option "on", foolishly assuming it'd target USB thumbdrives and the like - That's on me. I ought to have recalled that external USB backup drives count as removable media. Since turning this option off, the system is under less strain, scand is not out of control, and my backups are completing.

Thank you. I will do this now.

I will do this, but I do not have a local ESET distributor. I purchased directly from the ESET webpage. Who should I be contacting?

Slight further update, in the approximately 1 hr that the machine has been powered on this morning, scand has written nearly One Terabyte of information to disk(!!!), which is well beyond what any other process has done at all. Any insight into what is happening here would be appreciated.

I'm currently running ESET 7.3.3700.0 on MacOS Ventura 13.4 on an M2 Macbook Pro. This morning after logging in, before launching any programs whatsoever, ESET started positively destroying my CPU at 1000% usage or higher. It has been doing this for over a half hour. I did not launch a scan, and from everything I can see in the ESET GUI and Logs, no active scan is currently going. This is positively overwhelming the system right now, and I'm not sure why it's happening.

Excellent! Thank you much for the quick reply, and the information about the changelog on the download page.

Much appreciated! I still don't understand how Sysinspector could crash when I wasn't running it, but this seems like an issue that will be resolved with the next version update. Thank you much.