VirusTotal thinks it looks Malicious

I just installed and figured out how to use SA and ran a test on Virus Total. My original assembly exe was submitted and came back with the following.

Detection ratio: 1 / 60
The only hit was from Qihoo-360 for HEUR/QVM03.0.0000.Malware.Gen which is typical with that one AV. Qihoo is reporting ANY .net assembly with this, and I've asked VirusTotal why they continue to allow this company in their list considering it's history of corruption.

Anyway I then ran SA6 on the code and submitted the new assembly, and here is what I got back this time.

Detection ratio: 6 / 61
CrowdStrike Falcon (ML) malicious_confidence_65% (D) 20170130
Endgame malicious (high confidence) 20170329
Invincea trojan.win32.skeeyah.a!rfn 20170203
McAfee-GW-Edition BehavesLike.Win32.Backdoor.ch 20170329
Qihoo-360 HEUR/QVM03.0.0000.Malware.Gen 20170329
SentinelOne (Static ML) static engine - malicious 20170315

So 5 other AVs are now not liking it, including CrowdStrike and McAfee, those two cannot be ignored.

I guess the next thing to do is go through each project setting option one by one and try and figure out what options are causing these false positives or if anyone already knows how to resolve the issue I would love to hear it here. Thank you.

Tagged:

Comments

  • Jessica RJessica R Posts: 930 Rose Gold 1

    Thanks for your post!

    Regarding this issue, we do unfortunately see this happen with antiviruses sometimes. The problem is that Smartassembly's processing on your assemblies can lead to signatures in your code that are similar to those found in some viruses (though your files are completely safe).

    Project settings can definitely affect this. From a previous test I'd done, it seems that error reporting is a more likely cause of false positives. The assembly I had tested with got flagged by the following number of antiviruses when the listed feature was enabled alone:

    Error reporting - 4
    Feature usage reporting - 2
    Dependencies embedding - 1
    References dynamic proxy - 1
    Resource compression and encryption - 1
    Strings encoding when either improved protection or caching is enabled- 1

    With that, turning some features off can help, but the best solution would be to submit your protected assemblies as false positives to the antiviruses flagging them so that they will be whitelisted and no longer get confused as a virus.

    The contact info for many antiviruses can be found here: http://www.techsupportalert.com/content ... endors.htm

    For the other antiviruses not listed there:
    Crowdstrike - [email protected]
    Endgame - https://www.endgame.com/customer-support *
    Invincea - https://www.invincea.com/misclassified-file
    SentinelOne - [email protected] *

    *These are the only contact details I could find for the antivirus.

    Apologies as I know this isn't the answer you were hoping for but I hope this info helps!

    Product Support Engineer | Redgate Software
  • JensJens Posts: 8 New member
    We also suffer similar problems. For some reason this is becomming more and more an issue since about a year.
    We never heart of any issues like this 5 years ago (using the same obfuscation methods). So it seems that the scanning algorythm became more agressive.

    Currently we do not digitally sign our assemblies. I thought this might help to be treated as trustful source.
    Since the signing and the entire process of getting all the certificate is bound with some amount of work, I want to be sure that this really helps (so it's worth spending time on this).

    Does anybody knows or has expeirense, if the signing of assemblies prevents beeing treated as malware?
  • Russell DRussell D Posts: 625 Rose Gold 3
    edited October 16, 2018 9:07AM
    It won't prevent it entirely, but it will certainly improve your chances.

    When you produce your obfuscated assembly it looks for all intents and purposes exactly like a virus. Strong name signing is one basic way of telling AV vendors that you haven't tampered with it, but the real security comes from your installer certificate's trust rating. This isn't something that is made public so we can't help with that, but when you issue a new build, you start with lower trust than one that has been around for a while.

    Submitting your assemblies to AV vendors as above increases the speed with which you gain trust, but there's really no way around it, newly obfuscated builds can cause problems until they have been seen by enough AVs.


Sign In or Register to comment.