Strange file in operating memory of the computer

[AlSky 4]

1 hour ago, itman said:

Another possibility here is we are dealing with an unknown rootkit.

I came across the old Eset posting yesterday: https://forum.eset.com/topic/28800-cleaning-rootkit-problem/ . In this instance, the attacker dropped the .dll into the C:\Windows\System32 directory. Whereas Eset did detect the .dll as malicious, it could not stop the .dll from being repeatedly loaded into memory at boot time.

The original poster and others used Kaspersky's Virus Removal Tool (KVRT) to remove the rootkit. It can be downloaded here: https://www.kaspersky.com/downloads/free-virus-removal-tool . I have never used the tool since it's a Kaspersky provided product. If one has no reservation on using Kaspersky's products, you can try running it and see if it detects anything. Again, I can't help you with any issues with KVRT.

Hello and thank you for the answer. I have sent the logs to Marcos, indicating the thread of the forum I opened to see everything written here. I wait to see what he answers.

The other user with a similar problem uses a different operating system and the user of the thread 28800-cleaning-rootkit-problem/ had a similar and different problem at the same time, because his ESET product is able to detect the infection. In my case it only detects a strange file that it cannot open and there are some issues in the operation of the computer since then.

We'll see what's the result.

[AlSky 4]

1 hour ago, Mr_Frog said:

I have done this and KVRT.exe found nothing. Right now I feel insecure and just think maybe someone is spying on my Computer.

Hello. Looks like we have a similar problem. Does that file of yours have the same format as what it looks like to me? Like mem_2EBDBEB0000_7668.dll. Does it change every time you start the computer? Small changes, some digits. It's easy not notice it because seems to be the same, but in my case it changes every time.

The truth is that one feels unsafe not knowing if there is something dangerous on the computer. Good luck.

[itman 1,717]

There is another possibility based on lack of comment by an Eset moderator.

If either of you have an Intel CPU installed on your device, open Eset GUI -> Setup -> Computer Protection. Then open HIPS settings. Under Ransomware Shield protection settings, does the following highlighted setting exist?

If this Intel TDT setting exists and is enabled, it is possible this mystery .dll running in memory is related to that protection.

[AlSky 4]

1 hour ago, itman said:

There is another possibility based on lack of comment by an Eset moderator.

If either of you have an Intel CPU installed on your device, open Eset GUI -> Setup -> Computer Protection. Then open HIPS settings. Under Ransomware Shield protection settings, does the following highlighted setting exist?

If this Intel TDT setting exists and is enabled, it is possible this mystery .dll running in memory is related to that protection.

Hello. On your question, I have Intel Core i7 -12650H, but the option you show isn't available in my ESET product. Why? Isn't supposed ESET product is the same for al countries?

 

[itman 1,717]

6 minutes ago, AlSky said:

Why? Isn't supposed ESET product is the same for al countries?

Eset Intel TDT protection was originally implemented for only select Intel processor versions. The statement made by Eset at the time this protection was announced is additional Intel processors will be added at a later date,

Edited July 11, 2023 by itman

[itman 1,717]

One final comment in this thread and I am done with responding to replies.

KVRT scan didn't detect anything malicious with this .dll in question.

Eset real-time protection employs an advanced memory scanner which would have scanned the .dll when it loaded into memory.

I therefore conclude baring further proof that this .dll is malicious, one should not worry further about it.

Edited July 11, 2023 by itman

[AlSky 4]

1 hour ago, itman said:

One final comment in this thread and I am done with responding to replies.

KVRT scan didn't detect anything malicious with this .dll in question.

Eset real-time protection employs an advanced memory scanner which would have scanned the .dll when it loaded into memory.

I therefore conclude baring further proof that this .dll is malicious, one should not worry further about it.

Thank you for your time. Anyway, although the file may not be malware, how do you explain that more or less since that file started appearing the task manager spontaneously opens every day at 22.13? Or that the restore points disappeared? You said yesterday that it could be, as a conjecture, a case of hijacking dll. Also, in your first answer you said have never encountered an instance where ESET on-demand scan could not scan something in memory. I yes found it sometimes, but it happened occasionally and if I repeated the analysis in one or two days, there was no longer any file that could not be read. However, this file, whatever it is, persists. There is some process that makes it stay there or that creates it every time the computer starts.

About the working of the ESET real-time protection last month I had some problems that I reported to technical service. Doing the test to download cloudcar from the link that ESET indicates to check the functionality of ESET LiveGrid, I came across the ugly surprise that in half the attempts the cloudcare file was downloaded to my computer, when ESET should have blocked it. Cloudcar is harmless, but there is other software that is not. By the way, look at the date of the screenshot, June 15. Soon after, the problem with the mysterious file began. Coincidence? Maybe yes, maybe not. Could the protection of my ESET product have been malfunctioning during those days running a risk for my computer?

Please don't get me wrong. I'm not claiming that file is malware. I'm just saying we don't know what it is and what causes it.

 

[itman 1,717]

43 minutes ago, AlSky said:

Doing the test to download cloudcar from the link that ESET indicates to check the functionality of ESET LiveGrid, I came across the ugly surprise that in half the attempts the cloudcare file was downloaded to my computer, when ESET should have blocked it.

Repeat the test again. If you see clouldcar.exe file in your Downloads folder, check its file size. It should have a size of 0 bytes.

You car also check the cloudcar.exe files that currently exist in your Downloads folder. They also should be 0 bytes in length.

In other words, no actual executable file was created.

 

[AlSky 4]

13 hours ago, itman said:

Repeat the test again. If you see clouldcar.exe file in your Downloads folder, check its file size. It should have a size of 0 bytes.

You car also check the cloudcar.exe files that currently exist in your Downloads folder. They also should be 0 bytes in length.

In other words, no actual executable file was created.

 

Hello. I reported the error to technical support then, I was told that there was a problem with the ESET web link and that they would fix it. So it looks like it was, two days later it was fixed. I did the cloudcar test several times after I was told it was fixed and no files were downloaded to the computer.

The files that were downloaded to the computer weighed 7 kb. But none should have been downloaded. I made six or seven attempts, three of them downloaded, you can see in the screenshot. The other three or four were blocked by the ESET product with a warning screen.

These LiveGrid tests, repeating the on-demand scan over and over again, are due to the fact that since early June I noticed that if I did not enable all on-demand scanning options, the ESET product does not scan pagefile.sys, hiberfile.sys and swapfile.sys, or home/UEFI sectors. You have to mark them all. Why do you have the option to choose which sectors you want to analyze if ESET don't do it?

File that can never be read by ESET (it is normal) and that's why usually appears a message with error number 4 (can't be read), so I realized that the ESET product should not scan them. In the attached screenshot you can see that by selecting only those sectors for analysis the result is zero detections, zero scanned files.

After sending several logs to the support service, repeated numerous times the on-demand scan, complete and partial, the support service told me that the developers had encountered a problem in the product that will be resolved in the next version of ESET.

It was doing so many on-demand scans (almost daily) that I realized the appearance of the mysterious file that motivated the current thread.

[itman 1,717]

7 hours ago, AlSky said:

the ESET product does not scan pagefile.sys, hiberfile.sys and swapfile.sys, or home/UEFI sectors. You have to mark them all.

Eset does not and cannot scan pagefile.sys, hiberfile.sys and swapfile.sys files. As your screen shot and my below screen shot shows, zero files were scanned;

If you are worried about malware in the pagefile, it can be cleared at system shutdown by setting appropriate registry key to do so. Or, via like Group Policy setting if you are running a Win Pro+ version.

Likewise, the hiberfil.sys and swapfile.sys files can be deleted by running appropriate command line option to disable Hibernation, rebooting, and then re-enabling Hibernation. The same also can be done via Group Policy option.

Edited July 12, 2023 by itman

[AlSky 4]

5 hours ago, itman said:

Eset does not and cannot scan pagefile.sys, hiberfile.sys and swapfile.sys files. As your screen shot and my below screen shot shows, zero files were scanned;

If you are worried about malware in the pagefile, it can be cleared at system shutdown by setting appropriate registry key to do so. Or, via like Group Policy setting if you are running a Win Pro+ version.

Likewise, the hiberfil.sys and swapfile.sys files can be deleted by running appropriate command line option to disable Hibernation, rebooting, and then re-enabling Hibernation. The same also can be done via Group Policy option.

Hello and thank you for answering. That same screenshot I sent to ESET technical service. Along with others showing that in order for the on-demand scan to appear pagefile.sys, hiberfile.sys and swapfile.sys sectors with the "unable to open [4]" in the scan log, it is necessary to make an analysis enabling all the options, all the disks, all the folders. For example, I show in the screenshot: I do not want to scan the folder "Mis imágenes" or other "Mi musica" because they are folders that never change or do so rarely, take up a lot of space and analyze them takes about 1/3 of the total scan time. A hypothetical malware won't just stay there, where I keep my photos and my songs and music videos, it will infect other more important sectors of the computer.

If I disable those options, "Mis imágenes" and "Mi musica" it doesn't show at the end pagefile.sys, hiberfile.sys and swapfile.sys with the "unable to open [4]." It doesn't seem to analyze the memory either. If I enable all options, yes.

The technical service told me in June that it is an ESET product error that will be fixed in the next version. Have I not been told the truth?

First screenshot showing what I mean when I say about disabling some option. Second without enabling all options in scan. Third screenshot enabling all options. The divergence scaning or not pagefile.sys, hiberfile.sys and swapfile.sys sectors is a bug of the ESET product according the tech support and will be solved in future new version.

 

Edited July 12, 2023 by AlSky

[itman 1,717]

2 hours ago, AlSky said:

The technical service told me in June that it is an ESET product error that will be fixed in the next version. Have I not been told the truth?

We'll have to wait and see. I am skeptical this will happen since the OS has those files locked from access;

Sophos can detect malware in pagefile.sys, hiberfile.sys, etc. but cannot remove it. Removal methods are identical to those I previously posted: https://support.sophos.com/support/s/article/KB-000037996?language=en_US .

Edited July 12, 2023 by itman

[AlSky 4]

14 hours ago, itman said:

We'll have to wait and see. I am skeptical this will happen since the OS has those files locked from access;

Sophos can detect malware in pagefile.sys, hiberfile.sys, etc. but cannot remove it. Removal methods are identical to those I previously posted: https://support.sophos.com/support/s/article/KB-000037996?language=en_US .

Hello and thank you for answering.

I do not know if it is true or not what I was told from the technical service of ESET Spain, I only comment here in case anyone knew anything else about it.

Nor do I think currently I have any malware on pagefile.sys, hiberfile.sys and swapfile.sys, I simply indicate that the only way for ESET to attempt to scan those sectors and memory (even if it cannot and indicates error 4 unable to open) is to select all the disks and folders in the on-demand scan, if I don't, nor even try to scan it. And I was told on tech support that that's a product bug.

Otherwise, I'm waiting for Marcos' answer about the bootlog and logfile I sent, see if we can get anything clear about the strange file that keeps appearing.

Have a nice day.

[AlSky 4]

Hello there. ¿Any answer or help? Bootlog and logfile were uploaded and sent days ago, but no answer yet.

Thanks in advance.

[Marcos 5,157]

It is not a dll which could not be scanned but an internal virtual stream. Unfortunately we don't have an idea why it could not be scanned so we'd need step-by-step instructions how to reproduce it before we can investigate it on our end. Do you get the error when scanning memory every time you run a scan and also after you've rebooted the machine? Please provide logs collected with ESET Log Collector, at least we will get a list of installed and running applications so we could install them here and see if we get the same error. Definitely it's nothing to worry about and the error can be ignored.

[AlSky 4]

44 minutes ago, Marcos said:

It is not a dll which could not be scanned but an internal virtual stream. Unfortunately we don't have an idea why it could not be scanned so we'd need step-by-step instructions how to reproduce it before we can investigate it on our end. Do you get the error when scanning memory every time you run a scan and also after you've rebooted the machine? Please provide logs collected with ESET Log Collector, at least we will get a list of installed and running applications so we could install them here and see if we get the same error. Definitely it's nothing to worry about and the error can be ignored.

Good afternoon, Marcos, thank you for answering. I sent you by private message an ESET log collector log, selected all options and collected original binary from disk.

 

Indeed, every time I run an on-demand scan, that file appears. If I reboot the pc just the file changes name. Each time it has a different name, but the variation is minimal, the basic structure is preserved. The names till now are:

mem_19678010000_12860.dll

mem_25E7AE80000_8104.dll

mem_2BE77E60000_10020.dll

mem_2ABFC6D0000_19092.dll

mem_24A649D0000_13936.dll

mem_1883B4E0000_13256.dll

mem_2EBDBEB0000_7668.dll

mem_23A9E280000_13640.dll

mem_1325F220000_5904.dll

mem_178487D0000_5368.dll

mem_20577AC0000_8312.dll

mem_2DA3C590000_2580.dll

mem_198EF470000_6360.dll

mem_27B382B0000_7024.dll

 

Perhaps that mysterious file is nothing serious, no malware, and I wouldn't worry if along with the appearance of that file all restore points disappeared, the task manager opens every night at 22.13 spontaneously and on external hard drives (this is something I discovered recently) there is error reading in the boot sectors. ESET cannot read boot sectors. Attached screenshots.

 

Can it be a symptom of malware?

 

Itman wrote, about Process Monitor: "If the .dll doesn't load into memory after a system re-boot, this would be a strong indicator of malware activity. Certain malware are "Process Monitor aware" and will not perform malicious activities if it detects Process Monitor running”. Is it possible that we are facing this kind of problem?

 

Waiting your news. Thanks in advance.

[Marcos 5,157]

We'll stop reporting errors on internal streams soon, no further logs are needed. It is not a sign of infection.

[AlSky 4]

6 hours ago, Marcos said:

We'll stop reporting errors on internal streams soon, no further logs are needed. It is not a sign of infection.

Hello, Marcos. Thanks for the answer.

Are you sure in this case that I am reporting there is no hidden malware as indicated like the hypothesis that indicated @itman? I beg a categorical answer.

It's not just that mysterious file that we don't know what it is or what its origin is. Let's look at the background:

That file appears on on-demand scan in mid-June. On approximately the same days, Files Explorer begins to open spontaneously every night at 22.13. The existing restore points have disappeared. ESET cannot read the boot sector from external hard drives.

On the inability of the ESET product to read the boot sector of external hard disks, ESET Spain technical support has again done the same as with the mysterious file in RAM: they cannot ensure that there is no malware, better formatting external hard disks. (?) At least here you have requested logs of different programs, in the technical support of ESET Spain, no.

That's why I want to be sure that the problem is not related to malware.

Thank you in advance.

[Marcos 5,157]

By the way, what mysterious file do you mean? I'm asking since that mem*.dll is not a file as explained above.

[John Dow 5]

@Marcos: Just out of curiosity what is an "internal stream"?

[itman 1,717]

Non-withstanding the internal streams statement, I do know it is possible for an attacker to download a malicious .dll directly into memory as shown here: https://guidedhacking.com/threads/how-to-stream-a-dll-without-touching-disk-encrypted.16940/ . Since the downloads are encrypted, they are not accessible to AV scanning.

Edited July 22, 2023 by itman

[AlSky 4]

7 hours ago, Marcos said:

By the way, what mysterious file do you mean? I'm asking since that mem*.dll is not a file as explained above.

Hello. The file I mean is the RAM .dll I'm talking about.

@itman made an interesting contribution today that perhaps it would be interesting to study.

Otherwise, I asked a categorical question and requested an answer of the same kind.

Thank you in advance.

[AlSky 4]

5 hours ago, itman said:

Non-withstanding the internal streams statement, I do know it is possible for an attacker to download a malicious .dll directly into memory as shown here: https://guidedhacking.com/threads/how-to-stream-a-dll-without-touching-disk-encrypted.16940/ . Since the downloads are encrypted, they are not accessible to AV scanning.

Hello, @itman and thanks for answering.

Then I really don't know what to think and nobody from ESET seems to know or want to say anything concrete. You pointed to an option where that .dll file or whatever we want to call it, could be malware. ESET says don't worry, it isn't important, there is no malware but they can't explain what that .dll or its origin is, so believing it's not important and not a malware becomes an act of faith. What should I do?

Thanks in advance.

Edited July 22, 2023 by AlSky

[itman 1,717]

9 minutes ago, AlSky said:

What should I do?

That decision is up to you my friend.

[Marcos 5,157]

Since the SysInspector log didn't yield any suspicious files, I don't find any reason to be concerned about the safety of the machine. As for the error scanning the boot sector of the removable medium (e:), this would need further investigation if the scan was actually run with administrator rights, e.g. if the error occurs when the device/medium is connected to another machine with Windows 11 and scanned, or if it occurs if another similar medium is connected, if it also occurs on other systems, etc.