VBS/TrojanDownloader.Banload.FA trojan - error while cleaning

[Marcos 5,074]

4 minutes ago, GregA said:

Try restore this... file://C:\windows\system32\slmgr.vbs
And get this.... Task failed: CNodcommChannel: Send request failed with 14, Command failed - Make sure that Agent runs with Administrator privileges.

Does it fail even if you manually restore the file on the client? I tested it and was able to restore a file to the system32 folder via ESMC alright.

[mcnick 1]

2 hours ago, JackM said:

DISM /Online /Cleanup-Image /RestoreHealth 

This is what fixed the corrupt files.

Guys run this command in an elevated command prompt on your affected machines. It downloads the missing files from Microsoft. Run SFC /SCANNOW before and after to verify it worked.

[GregA 3]

40 minutes ago, Marcos said:

Does it fail even if you manually restore the file on the client? I tested it and was able to restore a file to the system32 folder via ESMC alright.

What do you mean by manually restore? ESMC is not manual and that is the only method I have been trying because it is multiple computers. I go to ESMC, Quarantine, Find the all computers with the hash causing the issue, try restore, one computer at a time, or multiple computers, same issue as described above in my post. So no, it does not work.

Task log... 
Task failed: CNodcommChannel: Send request failed with 14, Command failed - Make sure that Agent runs with Administrator privileges.

This is a little concerning as an admin. If ESET can't restore a system file like this, what would happen if ESET nuked an even more important file that the systems need on a ton of computers (hundreds, thousands) and ESET can't restore the file to computers? Is there a problem with the agent on these computers? We currently have over 1,500 computers and ESET quarantined slmgr.vbs on only about 14 of those computers it looks like.

 

[itman 1,659]

As far as DISM use, here's all the supported platforms for its use: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/dism-supported-platforms

If for some reason:

DISM /Online /Cleanup-Image /RestoreHealth

doesn't work, here's another method. See the linked article for further details:

Quote

Fix problems with DISM using WIM image

Although DISM is usually reliable, if there are problems getting the replacement files or you are not connected to the internet, an alternative source to repair the files using another image with the Source option will be required. In this case, you'll need an install.wim or install.esd file from another device, installation media, or ISO file. Also, the source of the known good files must match the same version, edition, and language of Windows 10 running on the computer.

https://www.windowscentral.com/how-use-dism-command-line-utility-repair-windows-10-image

Edited November 4, 2020 by itman

[itman 1,659]

11 minutes ago, GregA said:

This is a little concerning as an admin. If ESET can't restore a system file like this, what would happen if ESET nuked an even more important file that the systems need on a ton of computers (hundreds, thousands) and ESET can't restore the file to computers? Is there a problem with the agent on these computers? We currently have over 1,500 computers and ESET quarantined slmgr.vbs on only about 14 of those computers it looks like.

It appears that Eset doesn't consider script files as critical "system" files even if located in System32 or SysWow32 directories.

[Marcos 5,074]

17 minutes ago, GregA said:

What do you mean by manually restore?

What I mean is to try restoring the file manually on the client to find out if the problem is with restoring the file or with communication between agent and Endpoint. Just try it on one client, I don't mean to go to each client and restore it manually.

[Marcos 5,074]

5 minutes ago, itman said:

It appears that Eset doesn't consider script files as critical "system" files even if located in System32 or SysWow32 directories.

No. The problem is that only TrustedInstaller can write in the WinSxS folder. Restoration to other folders should work as long as ACL permits it

[itman 1,659]

1 minute ago, Marcos said:

No. The problem is that only TrustedInstaller can write in the WinSxS folder. Restoration to other folders should work as long as ACL permits it

I was referring to why Eset deleted the .vbs script in the first place.

[GregA 3]

8 minutes ago, Marcos said:

What I mean is to try restoring the file manually on the client to find out if the problem is with restoring the file or with communication between agent and Endpoint. Just try it on one client, I don't mean to go to each client and restore it manually.

Ok, I went to one of the computers and pulled up the ESET End Point Security GUI. Went to tools, quarantine, restore, enter the ESET GUI password, yes allow UAC, restore file from quarantine failed. 

File attempted to restore:   C:\windows\system32\slmgr.vbs

[GregA 3]

Update...

The file  C:\windows\system32\slmgr.vbs   actually exists on the system that I was looking at. Even though it shows in the Quarantine on both the local ESET GUI, and in the ESMC.

 

[itman 1,659]

2 minutes ago, GregA said:

Ok, I went to one of the computers and pulled up the ESET End Point Security GUI. Went to tools, quarantine, restore, enter the ESET GUI password, yes allow UAC, restore file from quarantine failed. 

Try to restore from quarantine to another work directory. This way "you can play" with its permissions as needed. Then move this restored file to System 32 directory.

[mcrouse 1]

2 minutes ago, GregA said:

Update...

The file  C:\windows\system32\slmgr.vbs   actually exists on the system that I was looking at. Even though it shows in the Quarantine on both the local ESET GUI, and in the ESMC.

 

I've noticed on the majority of my endpoints that had this detection that ESMC would show the file as being quarantined but when I went on the endpoint to check, there was nothing in the quarantine folder and the files were still in their original location.  It appears that they were never quarantined even though ESMC was showing them as quarantined.  I was also seeing error when cleaning ESET errors on the detections.   And if I sent a restore from quarantine task it would fail

[Marcos 5,074]

1 minute ago, GregA said:

Update...

The file  C:\windows\system32\slmgr.vbs   actually exists on the system that I was looking at. Even though it shows in the Quarantine on both the local ESET GUI, and in the ESMC.

 

If a file with the same name already exists, restoration from quarantine fails. Maybe Windows installed it automatically in the meantime; if it was restored from quarantine it would not be there. Files are removed from quarantine after being successfully restored.

[itman 1,659]

Here's something else to try. The OP originally inadvertently deleted the file:

Quote

The problem was solved.

The first run of the Windows activation troubleshooter did not fix the deletion of the product ID.

None of the administrative command prompt commands using slmgr restored the product key or fixed the activation failure.

Somehow the second run of the activation troubleshooter worked.

The product ID was restored so that third party software displays the 25 digit product ID.

I did not perform a system restore and it remains unclear whether this would or would not restore the Windows 10 product ID after manual deletion.

In summary, it appears that deleting the product ID and having had the licensing information on Microsoft servers allows the activation troubleshooter to restore the product ID.

This converted validation status:  invalid license with validation code 0xC004F014 to validation status:  Genuine with validation code 0x4004F401

https://social.technet.microsoft.com/Forums/en-US/f6b4bf4a-8a55-41b0-a330-fc0df6588c32/recover-product-key-after-deletion

Edited November 4, 2020 by itman

[Marcos 5,074]

25 minutes ago, itman said:

I was referring to why Eset deleted the .vbs script in the first place.

It was a false positive; a detection of malware that was also triggered on this particular file. While ESET is known for being one of AVs with least false positives, they sometimes happen. This FP happened as a coincidence of several factors. Under normal circumstances such detection would not be released. Also the fact that it was a script ruled out the LiveGrid-based antiFP protection mechanism which prevents binary files from being incorrectly detected even if a bad detection is accidentally released.