Threat removed popup

[jlhatsfs 0]

I am running ESET Internet Security v13.2.18.0. I have developed a C# application that makes calls to a Fortran DLL that I also developed. Each time I start the C# application, a ESET popup message appears as follows:

Threat removed

A threat (Suspicious) was found in a file that MSBuild.exe tried to access.

The file has been deleted.

When I click on file, it points to the DLL file in a directory in which the indicated file does not exist. I do have in in other directories and when I run a ESET scan on it, no problems are reported. Can you tell me what might be going on here? Thanks for your help.

Jerry Horsewood

[Marcos 4,694]

Please collect logs with ESET Log Collector on the machine and upload the generated archive here.

[itman 1,538]

Also, post the Eset Detection log entry for this for review.

[jlhatsfs 0]

I believe I know what is happening, but not why. I'm running my application in debug mode with Visual Studio 2017. That automatically compiles the application in the debug folder and collects the resources (including the DLL file) into that folder before running. ESET then checks the folder before execution and deletes the DLL file, even though a scan detects no problems. I hope you can help. Thanks.

eis_logs.zip

[jlhatsfs 0]

Here is the Eset Detection log report.

eis_threat_logs.zip

[itman 1,538]

1 hour ago, jlhatsfs said:

Here is the Eset Detection log report.

eis_threat_logs.zipUnavailable

I need you to copy the Detection log entry; not the entire log, and post it into a forum reply. Only Eset moderators can read forum attachments.

Edited September 5, 2020 by itman

[Marcos 4,694]

I assume the file is no longer detected. Could you confirm?

[jlhatsfs 0]

That is correct. I just ran the application and there was no detection. The file now appears in the directory from which it was previously deleted. I then ran a scan on that file and it reported no detections as expected. The one thing different is that it said it used Detection Engine 21941. Previous scans used Detection Engine 21940. Was there a problem with the previous engine that caused the problem?

[jlhatsfs 0]

@itman - I don't know what the Detection Log entry is that you refer to. Is it the report from the scan? A text file on my computer?

[itman 1,538]

1 hour ago, jlhatsfs said:

@itman - I don't know what the Detection Log entry is that you refer to. Is it the report from the scan? A text file on my computer?

Open Eset GUI. Select Tools -> More Tools -> Log Files -> Detections. In that log should be an entry related to this MSBuild.exe file access detection. Right mouse click on the entry and select "Copy." The paste it into your next forum reply.

Edited September 5, 2020 by itman

[jlhatsfs 0]

OK, here it is.

Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here
9/4/2020 7:30:55 PM;Real-time file system protection;file;C:\Users\Jerry\Documents\Visual Studio 2017\Projects\MAnE\Exec\Mission Analysis Environment\bin\x86\debug\OrbitRel.dll;Suspicious Object;cleaned by deleting;SFS-HOME\Jerry;Event occurred on a new file created by the application: C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe (4547B24DB7A512B1F9A6E2ED0DCB7E7FEE0A9E24).;907C4C27F2F3110781DE9D2DF901C0826238FFA2;8/4/2020 11:27:20 PM
 

[itman 1,538]

Interesting.

The issue I see here and of question is why your Visual Studio projects are being stored in C:\Users\Jerry\Documents? That is certainly not a place where executable's; note a .dll is an executable, should be stored.

Note that MSBuild.exe is one of the trusted Win processes abused by hackers. For more details on how this is being done, read this article: https://www.hackingarticles.in/bypass-application-whitelisting-using-msbuild-exe-multiple-methods/ . It seems more than reasonable to me that Eset would detect a .dll created by MSBuild.exe being dropped to the Documents folder as suspicious activity. Also, it is uplifting to see that MSBuild.exe is being actively monitored by Eset.👍

Edited September 5, 2020 by itman

[jlhatsfs 0]

This is the default structure for Visual Studio projects. A project is developed in the User's Documents folder to keep them separate from other users on the computer. Debugging is done from the folder that was causing the problem. Once the application is finalized, the application .exe is built in a Release folder and the installer installs the release version on a target computer in a structure defined by the developer. I routinely install in a subfolder of the Program Files folder. User specific input and output data from the application is stored back in a subfolder of the user's Documents folder to keep them separate from the data of other user's and to assure that they are backed up by normal backups.

BTW, the problem has stopped occurring. I suspect that the change of Detection Engine corrected the problem. @Marcos has not verified this, though.

[Marcos 4,694]

The file that was detected was removed from the LiveGrid blacklist. The detection was not related to the engine.

[jlhatsfs 0]

OK, thank you for your help.