Mp3Tag Blocked After Renaming Files

[Canoman]

I'm new to Immunet and to these forums, so please forgive me if I'm putting this in the wrong place.

This morning, I was using Mp3Tag ( https://www.mp3tag.de/en/ ) to manage some music files, and when I performed an action that takes information from the ID3 tag and uses it to rename the files, Immunet blocked Mp3Tag from running, saying it was performing malicious activity.  This was an intentional action I took and not something that the software was doing on its own.  Is there a way that I can whitelist this program so I can use it again?

I went into settings and added an exception for the Mp3Tag folder after the fact, but I still cannot run the program.  I checked the quarantine section, and it doesn't show anything as being quarantined.

Thanks, in advance.

[ritchie58]

Hi Canoman, I checked Virustotal and didn't get any negative search results for Mp3tag.exe and the URL you provided seems like a legit site so I would concur that this is a False Positive.

There is an on-going issue with some history files not being displayed correctly or at all with this build. I certainly hope it isn't the case that the file got quarantined and the data is not being displayed.

Could you double check that there isn't anything in Quarantine? Try opening the UI and below and too the right of the History tab click on the word Quarantine that's underscored (see image), see if any listings are present. If there is, find the file in question, click on it then click Restore.

You can also click on the History tab, then click on the little downward pointing arrow next to Default. This will give you a little drop down menu, then select Quarantined File History from the menu. See if any quarantine data populates that way too.

If no quarantine data is listed another thing to try is adding an Exclusion rule for "the entire Program Files folder" for the software.

 

[Canoman]

ritchie58,

Thanks for your assistance.  I checked both places for anything quarantined, and in both cases, it told me that there was nothing.  I have added exclusion rules for the following:

c:\Program Files (x86)\Mp3tag

c:\Program Files (x86)\Mp3tag\

Should this be sufficient?

Thanks, again.

[Canoman]

7 hours ago, Canoman said:

ritchie58,

Thanks for your assistance.  I checked both places for anything quarantined, and in both cases, it told me that there was nothing.  I have added exclusion rules for the following:

c:\Program Files (x86)\Mp3tag

c:\Program Files (x86)\Mp3tag\

Should this be sufficient?

Thanks, again.

After a reboot, I tried running Mp3tag again, and it ran successfully.  I have not tried a rename of multiple files again that triggered Immunet to act, but at least I could run the program.  Thanks for your help.

[Canoman]

2 minutes ago, Canoman said:

After a reboot, I tried running Mp3tag again, and it ran successfully.  I have not tried a rename of multiple files again that triggered Immunet to act, but at least I could run the program.  Thanks for your help.

I just renamed an album's worth of files using the program, and Immunet didn't get triggered, so the exceptions must be working like they should.

[ritchie58]

That's great news the Exclusions seem to be working! Always happy to help out when I can Canoman!

It might not be a bad idea to keep both Exclusions in place if the software seems to be working ok now.

One reason for that file not showing up in Quarantine is if it was just a temporary file created by the program that automatically got deleted. Under these circumstances there's no file present to use the Restore feature. I've seen this quarantine behavior happen before with other software packages that use temp file(s).

If you run into any other conflicts between Immunet & Mp3tag don't hesitate to add an additional thread to this topic & we'll further investigate this issue.

Best wishes, Ritchie...

[Zombunny]

Apologies for resurrecting a thread after a few weeks, but I think I've had this same issue with another program, and it's not a signature detection. Your mp3 batch tag operation triggered Immunet's rudimentary ransomware protection, so the operation was stopped and the program terminated; however the lack of a signature detection resulted in the program being blocked but not quarantined.

 

It makes sense, if you think about it. What does ransomware do? It locates any document files it can find, and goes through them sequentially. One by one, each file is opened, changes are written, the file is closed, and the next file is opened... What did your mp3 tagging tool do? Go through a folder of data files (mp3s), and one by one, open each file, write a change to it, close it and progress to the next!

 

So in summary, the program's behaviour was blocked, but nothing was probably quarantined.

[ritchie58]

That is also a possibility Zombunny! Immunet 6 does have a exploit/system process protection feature that could have been triggered instead of a malware quarantine response.

That's not to say that my extrapolation about possible temp files was way off base. Like I mentioned in the previous thread I have seen this type of quarantine behavior before where no file is present in the Quarantined Files list because it's just a temp file that already got deleted but you may be right about a exploit response instead. Great extrapolation on your part!

Cheers, Ritchie...