Evermore 0 Posted June 17 Share Posted June 17 I have a PowerShell script saved as a .txt file which NOD32 suddenly decided needed to be deleted when I did a search with a utility that scans for text inside files, even though the file has existed for 5 months and wasn't detected as bad previously when created or opened. NOD32 decided it's a "trojan downloader", and it does download .cmd script files and I don't expect ESET to have vetted every tool like this, so I'm not upset that it's detected, but excluding it was really difficult and I'm just wondering why it happens this way. I couldn't restore from quarantine and exclude it in one step because the option was grayed out. I went to add an exclusion in settings, and browsed to the file and selected it and clicked Open, and that caused the file to be scanned and sent to quarantine so it couldn't be added to the exclusions because it didn't exist anymore. The only way to add it was manually putting in the path and file name. Why does the program scan a file that you're trying to add as an exclusion and remove it so it can't be excluded? Why can't this file type be restored from quarantine and excluded in one step? Why are any files not allowed to be handled that way? Why does it take digging so far down into the Advanced settings to add an exclusion? (NOD32 has always had a ridiculously complex set of options and steps required to change them.) Link to comment Share on other sites More sharing options...
Administrators Marcos 5,397 Posted June 17 Administrators Share Posted June 17 Please provide logs collected with ESET Log Collector so that we see what was detected. Link to comment Share on other sites More sharing options...
rotaru 15 Posted June 18 Share Posted June 18 18 hours ago, Marcos said: so that we see what was detected. How is relevant "what was detected" for the issue mentioned here??? The OP said "Unable to exclude a file" So , regardless of "what was detected" he/she should be able to exclude it as he/she wish..... Link to comment Share on other sites More sharing options...
Administrators Marcos 5,397 Posted June 18 Administrators Share Posted June 18 I need to see what was entered by the OP in the exclusion detection: Link to comment Share on other sites More sharing options...
Evermore 0 Posted June 19 Author Share Posted June 19 The detected "danger" is irrelevant. In the Add exclusion dialog, nothing was "entered" that is relevant. I followed the instructions from ESET and clicked the ..., browsed to the file I wanted to exclude and selected it and clicked Open, which caused it to be instantly detected and quarantined so it could no longer be selected. I had to manually type the path and filename and click OK to enter the exclusion, and restore it from quarantine in order to have the exclusion work. Selecting the file from the dialog to add it to exclusions should not cause the scanner to detect the contents of the file and delete it. It's that simple. Link to comment Share on other sites More sharing options...
Administrators Marcos 5,397 Posted June 19 Administrators Share Posted June 19 For security reasons exclusion of a file needs to be done in two steps: 1, You browse for the file (if excluding the detection in a whole folder is not an option) The file gets detected and quarantined. 2, You restore the file from quarantine. Due to an existing exclusion, it won't be detected again. In case it's a PUA/PUsA detections, these can be excluded directly from the Detections log: Link to comment Share on other sites More sharing options...
Evermore 0 Posted June 19 Author Share Posted June 19 It's detected as a trojan, which it's not. It's just a tool that does something that CAN be used maliciously but is NOT in this case. I don't mind that this type of thing is detected because normally one would not want this to be happening but this is a TOOL that I need to use for legitimate reasons. It's a PowerShell script that just has .txt as a file extension. There is no "existing exclusion". Restoring from quarantine doesn't create an exclusion as I mentioned (that option is grayed out) and I CANNOT CREATE THE EXCLUSION EXCEPT BY MANUALLY TYPING THE PATH AND FILENAME. What are you not getting about this? Stop reciting what's in your response scripts and actually read. My complaint is that I can't just follow the steps to select the file and add an exclusion without MANUALLY TYPING THE PATH AND FILENAME. It's impossible to add an exclusion using the obvious method of selecting the file after browsing for it, the method that ESET's own instructions give, because selecting the file immediately deletes it so I can't press OK to have the file's path and name put into the exclusion path field. It has to be done manually, and claiming that it's a two-step process "for security" is ridiculous and insulting (not to mention it doesn't work the way you said). It takes plenty of effort to even get to the exclusions, and what's the point of even having a "browse" option if you can't actually use it? Why prevent me from simply adding the exclusion in the same step as restoring it from Quarantine? And excluding the entire folder isn't a good idea when it's just a temp folder with a bunch of other unrelated files, and you shouldn't blindly recommend that to users without information about what the folder contains. Link to comment Share on other sites More sharing options...
Administrators Marcos 5,397 Posted June 19 Administrators Share Posted June 19 1 hour ago, Evermore said: It's detected as a trojan, which it's not. Please provide the full detection name along with the hash of the file, if known. If it's a false positive, we will remove the detection. 1 hour ago, Evermore said: There is no "existing exclusion". Restoring from quarantine doesn't create an exclusion as I mentioned (that option is grayed out) and I CANNOT CREATE THE EXCLUSION EXCEPT BY MANUALLY TYPING THE PATH AND FILENAME. We recommend copying and pasting the full path to the file to the exclusion path field instead of using the browse function. If you use it, the file will be first detected and quarantined but you will be able to set up the exclusion though. Then you can right-click the file in quarantine and select Restore or "Restore to". Since the exclusion will already exist, the file won't be detected then. 1 hour ago, Evermore said: Stop reciting what's in your response scripts and actually read. We don't use any response scripts except for the instructions how to collect logs. Link to comment Share on other sites More sharing options...
Evermore 0 Posted June 19 Author Share Posted June 19 Good God. You people just are incapable of focusing on the topic at hand. You don't need to know ANYTHING about what was actually detected to respond to my post. I was ONLY commenting on the fact that I shouldn't have to manually enter the path and filename in the field. There is a BROWSE function, so why is it not FUNCTIONAL? Why is it even there if you recommend not using it because the software will not let it work? I'm done with this. It's bad design, it's that simple. Link to comment Share on other sites More sharing options...
Administrators Marcos 5,397 Posted June 19 Administrators Share Posted June 19 Security is what matters. For security reasons we cannot exclude the egui process from detection when browsing for files. Hence we recommend copying and pasting the path to the file in the path field in the exclusion setup window. Or browse for the file, create the exclusion (the file will be detected and cleaned) and then restore it from quarantine. This is the official statement consulted with developers and a product owner on this. Link to comment Share on other sites More sharing options...
rotaru 15 Posted June 19 Share Posted June 19 What about using ESET in interactive mode??? When something is detected , you select an option to "Create exclusion" . Link to comment Share on other sites More sharing options...
Recommended Posts