Norton Security Alert Downloading ClassicStartSetup_4.4.109

[ghost]

When I download Classic Start 4.4.109 I'm getting Norton Security alerts about some malware coming along with it. See attached images. However, ClassicStartSetup_4_4_109.exe is downloaded and saved on my computer. Subsequent scans with Norton Security and Malwarebytes show no problem with the downloaded file. However, whatever else is coming along with the file is tagged, deleted from the computer and is apparently the source of the issue.

[Clintlgm]

Yes this happens because they haven't gotten all the signuture up to date yet. A month ago when I download I got the same warning from Norton and Malwarebytes I just by passsed the warning has had no issues with any of my computers. This was all discuss on the 10 forum in this thread https://www.tenforums.com/windows-10-news/99582-classic-shell-no-longer-development-now-open-source.htmlo

[ge0rdi]

This is false-positive detection of Norton Security product. There is no malware present in the installer. You can check sources and eventually compile by yourself if you want to be 100% sure.

I'd recommend to report the FP to Symantec so they will eventually investigate the file and stop flagging it as malicious.

You can find more such FP reports if you google for that detection name.

This is from Heur.AdvML.C description:

Heur.AdvML.C is a heuristic detection designed to generically detect malicious files using advanced machine learning technology.

Apparently this top-notch machine learning based heuristics just flags files with very low prevalence (very few Symantec users encountered the file) that are not digitally signed (this is common trend among current anti-malware products).

Actually digitally signing binaries is very good idea (and it may prevent such FPs in the future). But signing certificate costs some money. And since this is non-profit volunteer-maintained project, I'm not sure we will be able to cover such costs.

[Nodens-]

It's far from top-notch heh and Norton products are abysmal since Peter Norton sold the company. Top-notch heuristic engines are the ones employed in products by ESET and Kaspersky. ML based heuristics that flag on prevalence instead of code analysis (specially on PEs/binaries that are not even packed/encrypted/virtualized) are a joke/marketing scheme :P

[Ibuprophen]

@LGotkin, @Clintlgm, @Nodens-, @ge0rdi, @coddec, @XenHat, etc... etc... etc...

After performing a little research regarding this I've came up with the following (as brief as I can)...

Norton is looking at the Open Shell, Classic Shell, etc... as a form of "Start Menu Hijacking". This is being reflected for either/or the "Heur.AdvMl.A, Heur.AdvML.B, Heur.AdvML.C, etc... with some reflecting one of them and others reflecting more than one (which is kinda odd).

Keep in mind that it's actually appropriate for Norton to report a Hijacking (Malware) for any software that takes over a critical feature in Windows even if your aware of it because Symantec isn't aware of it (as reflected on their Whitelist).

There's a few options (regarding Symantec products and others) that I would encourage not only the developers to do but, also the users of said software (Norton, Malware Bytes, etc...) not all at once but, as they are reflected on the Malware software.

This list is actually specific to Symantec/Norton because that's the issue topic. This is also not in any specific order either. Just use whichever may apply to your situation at hand.

Restoring an item from Quarantine: https://support.norton.com/sp/en/us/home/current/solutions/v6200368

Resolving a Norton product alerts that had falsely reflected one or more files that was downloaded and deemed that it's is not safe, and then deletes it: https://support.norton.com/sp/en/us/home/current/solutions/v80629965

Resolving a Norton product that incorrectly alerts you that a file is infected and/or a program/website is suspicious: https://support.norton.com/sp/en/us/home/current/solutions/kb20100222230832

How to Add items to the Signature Exclusions: https://support.norton.com/sp/en/us/home/current/solutions/v54298598

How to toggle the Download Intelligence feature OFF/ON: https://support.norton.com/sp/en/us/norton-security/current/solutions/v23920640

How to report false positives (For Symantec to Determine the Whitelist Inclusion): https://community.norton.com/en/forums/how-report-false-positives

I hope that I had explained this okay via text... :-)

~Ibuprophen

[XenHat]

Pretty sure that's a thing because Microsoft are trying to fix their menu and want to shove it down our throats. And because we are a young project in name and existence. I can't afford a paid certificate. Also Anti-virus programs being what they are...

See related question I posted years ago: https://softwareengineering.stackexchange.com/questions/273916/convince-windows-smartscreen-and-web-browser-that-my-application-is-safe

[Nodens-]

Having worked in the security field, I'm pretty sure it's exactly what I said above. Heuristics engines are supposed to do code analysis and check specifically for malevolent code practices. Generic hooking of anything, does not qualify for flagging and I'm 200% sure this is not the case here. And reputation based systems are not real heuristics.

The Heur.AdvMl.x designations are part of Symantec's SONAR (https://support.symantec.com/en_US/article.HOWTO80968.html) which is mainly a reputation based system (see Insight lookups) that boasts heuristic capability which is laughable compared to proper heuristics engines.

This is just Symantec being Symantec. To give you a better example of how bad their heuristics engine is, I have developed a piece of software for a client that is being used for competitive benchmarking. In order to prevent certain cheats, I'm hooking the keyboard, in a very clean way, in order to cause any keystroke to abort the benchmark. Also hooking the mouse to abort on mouse movement (moving further than 30 pixel radius). Notice that the keyboard hook is not system wide while the mouse hook is. This was getting flagged by Symantec products but not by any of the proper heuristics engines (ESET, Kaspersky). As a test, I made a build that actually logged the intercepted keystrokes and obfuscated the code just slightly. This build passed the Symantec products just fine while it was flagged immediately by ESET (did not test Kaspersky). As a second test, I signed the software with the client's certificate (the original version not the test one) which was a well known certificate in Symantec's db. This caused the original version that was flagged not to get flagged anymore. This is not heuristics at work. It's just a poorly implemented reputation system with elementary level code analysis..

There is only one way to deal with Symantec and few other companies who employ such bad practices under the label of "heuristics": Code signing. It also helps with Windows SmartScreen/Defender who also likes to scare off users when they run unsigned binaries.. There is a cheap option (the only one), specifically for open source project needs, by Certum, here: https://en.sklep.certum.pl/data-safety/code-signing-certificates/open-source-code-signing-on-simplysign.html This is easily sustainable by donations at 49Euro per year.

[Ibuprophen]

I believe that Symantec is basically taking the lead from Microsoft regarding their "in house" way of trying to prevent other software (like a start menu one in this case) from being installed.

Though, I know that there's more specifics behind this but, this is ultimately what it looks like is happening. I feel that the Symantec and Microsoft (as well as others) angle is a form of a "Scare Tactic" to help accomplish this.

The situation itself is similar to what Google did on the Android when Google began using their PSA (PSA = Poison System Alert). The alert that you get when Google asks you to uninstall an app because it can do harm to a device. There are many of those apps that does do harm but, there's many that doesn't do harm but, Google doesn't want you to have it.

I did the best I could to explain the above via text... 😱

~Ibuprophen

[Nodens-]

Google and Microsoft can do that if they detect that something interferes with their OS in a way they do not wish to enable or support. Symantec on the other hand has no such incentive or right. If they're blocking anything on those grounds they're setting themselves up for a huge lawsuit and that is not happening any time soon mate.

Bottomline is that in order to avoid such false positives, the binaries have to be signed so that reputation based systems start trusting the certificate after in-house analysis. Without signing, you can expect issues like this popping up on the tracker regularly (by SmartScreen/Defender users alone..). The good thing is that Open Shell does not require a ring 0 driver because Win10, since a few builds ago, requires an EV certificate for signing kernel drivers, or they won't even load (unless in test mode) and those are VERY expensive. A paypal donation button for the cost of the code singing certificate should be considered.

[Ibuprophen]

I'm not trying to debate, contradict nor prove anything alike...

I'm just supporting this development and providing my personal insight into this issue itself.

I'm positive that one or more of the developers have looked into this (and/or still looking into this).

I'm just going to let them work it out and await their further instructions/guidance regarding this.

Thank you very much for your time and understanding with this! :-)

~Ibuprophen

[jboutin]

Just a few automated scans (from VT, and Jotti) that checks for heuristics/malicious code: VirusTotal | Jotti.

Yes it is possible to inject code into an existing executable, and many infection writers use that technique to hide their creations, however when there's only one AV program making a detection, then it's much more likely that the detection is a false positive. (See: BleepingComputer thread regarding the 'WisdomEyes' detection.)

Truly looks like nothing more than a false positive.

[ghost]

Following up with Norton and doing a little more research we've determined that the problem is not due to the file ClassicStartSetup_4_4_109.exe. The problem is with the cache file 5f0c0...... that the Firefox browser is creating as shown in the activity description in the image below. In fact, I did the same download using the Microsoft Edge browser, with Norton active at the time, and no Norton alert is shown. Bottom line - it's a Firefox issue and not an issue with the ClassicStartSetup file.

[XenHat]

I would wager that this is a recent behavior Flag after the "browser mining Malware" since it's storing an unsigned, large file.

While I do have the ability to sign binaries, free self-signed certificates are meaningless to the Trust framework av uses.

[Nodens-]

Are you sure that Norton is supporting Edge? Because this sounds to me like Edge is just not being checked. Usually the mechanism for checking SSL connections on browsers includes installing a MITM (AV handles the actual SSL tunnel) so the AV can check the encrypted traffic. Firefox is supported but Edge being rather new may not be.