Blocked EDTD? ntoskrnl.exe?

[cmit 2]

Could ESET experts help explain what these messages mean?

Same computer name, same infected file/message.
Infection identified changed from 'suspicious object' to 'blocked EDTD'.

Was it really a threat file that got deleted thanks to EDTD?
Would the ESET EndPoint Antivirus (without EDTD) still catch it?

My understanding is the ntoskernl.exe could be related to BSOD but need confirmation.

 

[itman 1,659]

The only files I have in that directory on Win 10 are .xml and .cdf-ms files.

[cmit 2]

15 minutes ago, itman said:

The only files I have in that directory on Win 10 are .xml and .cdf-ms files.

Which means....?

(this computer runs Win7 x64)

Edited April 16, 2019 by cmit
need clear answer

[itman 1,659]

What I read on the web is that directory is used by both installers and Win Updates as basically a work directory during their respective processing. Also, both are supposedly responsible for cleanup; i.e. deletion of files in that directory.

Note that the last Win 7 cumulative update was pretty much a mess for a lot a devices. You will have to submit those files to Eset for analysis before a definitive verdict can be rendered if they are truly malicious.

[Matus 21]

Hi Guys,

this thing was identified as malicious, however, it's False Positive. We've added that to whitelist not to trigger, however, we're investigating what has happened, which system and why it was identified that as malicious. The issue will be fixed properly after that investigation.

Anyway, for imagination if that would not be FP, then to your questions:

Was it really a threat file that got deleted thanks to EDTD? - YES
Would the ESET EndPoint Antivirus (without EDTD) still catch it? - No, it would not. Into EDTD are sent only files which Endpoint identified as clean, but "interesting" to further investigation

[keeganford 0]

I am searching for this from last 2 month but finally I got it. I also found something related to dreaded ntoskrnl exe bsod you can check it out here at: https://validedge.com/dreaded-ntoskrnl-exe-bsod/

Edited May 21, 2019 by keeganford

[cmit 2]

5 hours ago, Matus said:

Hi Guys,

this thing was identified as malicious, however, it's False Positive. We've added that to whitelist not to trigger, however, we're investigating what has happened, which system and why it was identified that as malicious. The issue will be fixed properly after that investigation.

Anyway, for imagination if that would not be FP, then to your questions:

Was it really a threat file that got deleted thanks to EDTD? - YES
Would the ESET EndPoint Antivirus (without EDTD) still catch it? - No, it would not. Into EDTD are sent only files which Endpoint identified as clean, but "interesting" to further investigation

- Could you explain what this deleted 'false positive' file really is and what does it do? (not sure if it's even related to the blue screen of death or related to Windows Updates)
- Why it re-appeared 3 times after got deleted the first time?
- What negative affects might happen to this computer since now this 'false positive' already got deleted (or will it reappear again)?

noticed this same 'false positive' happened on two computers so far.

Edited April 17, 2019 by cmit
added more info

[Marcos 5,070]

1, Since it was found in the WinSxS\temp\PendingRenames folder, judging from the name of the executable I assume it was created during a Windows update.

2, Probably because Windows update attempted to download and install it again and again.

3, Windows update should install it alright once it's not detected / blocked. Still, it's just a hunch that it was Windows update that generated the file.

[itman 1,659]

1 hour ago, Marcos said:

3, Windows update should install it alright once it's not detected / blocked. Still, it's just a hunch that it was Windows update that generated the file.

I think that is a good assumption. On my Win 10 build for example, ntoskrnl.exe was updated as a result of the 4/9 cumulative update.

Whether the file deleted in C:\Windows\WinSxS\Temp could cause a blue screen is debatable. The only way I see this happening is if C:\Windows\System32\ntosknrl.exe was deleted in the Win Updating processing and the file in C:\Windows\WinSxS\Temp was its replacement. Since Win Updating is performed in isolated off-line fashion, I really don't see how Eset in any fashion could have deleted the file prior to full completion of Win Updating processing. However Win Updating on Win 7 is "pretty primitive" compared to that done on Win 10, so anything in this regard is possible.

Edited April 17, 2019 by itman