Rufus executable once again being falsely flagged as malware

[Akeo]

Hi,

Once again, the unsigned MinGW build of Rufus (which is built in a fully automated fashion from our public source by GitHub actions here and can also be downloaded here)  is being flagged by Malware byte as malware (Malware.Heuristic.1003).

See https://www.virustotal.com/gui/file/8aed4efd42410e8c5148e741353dc5dc7d9c25ffff4f74f309e239a85be600a9/detection

Whereas for previous releases, the false positive seemed to disappear after the file was digitally signed, there is no reason why the unsigned version of the executable should be flagged, especially when it can be formally demonstrated that the binary can only have been produced from the public source at https://github.com/pbatard/rufus.

So could Malwarebytes please fix these obnoxious false positives so that they stop occurring?

Thank you.

MinGW.zip

[cli]

From Malware.Heuristic.100X Detections and Explanation,

Quote

The Malware.Heuristic.100X detection names come from a new aggressive heuristic which detects malformations in PE headers which are typically found in malware and viruses....

This setting, which can be found under ["Settings > Security > Expert systems algorithms"], is OFF BY DEFAULT...

You should only enable this aggressive heuristic if you suspect your computer has a malware infection which is not detected regularly by Malwarebytes, and want to run a more paranoid scan.

Because this setting is off by default most users will not encounter this detection.

This has been whitelisted. Thanks for reporting.

[Akeo]

I appreciate that. But I'd rather not have every unsigned executable I compile get flagged for behaviour that is not present in the source code (unless you guys can actually point to what it is in our source that triggers this false positive).

My understanding is that, if we're going the whitelisting route, I'm going to have to submit new false positive reports every time I recompile a new executable, and this is going to get old very fast...

So can I ask you to please look at the actual sequence of instructions that trigger the false positive, and, since you do have a clear example of a false positive, address that instead?

[leo3487]

You already reported it and was solved, Im sure when you compile a new version and report it as FP, Malwarebytes staff will take the needed actions to exclude your executab^le for longer time (while you no make significant modifications to code)

 

[Akeo]

It was solved for one executable. It wasn't solved for the 2 previous builds [1], [2], and I just don't have the scope as a software developer to go around every AV vendor out there that suddenly decides to flag my software, which is why I asked for something better than whitelisting...

[shadowwar]

This is an auto learning heuristic. It will usually learn within 24 hours of first scan wether its a fp or not and self correct. Do you know if it still hits if its not upx packed? Also the file has a rcdata resource section but they are all empty. that may be triggering the heuristic. 

 

 

Edited August 11, 2022 by shadowwar

[Akeo]

Hi Rich, thanks for replying.

Quote

It will usually learn within 24 hours of first scan wether its a fp or not and self correct.

Well, those executables were produced days before the one I reported as fp, and they don't appear to have self corrected... The first executable was produced 9 days ago and the second

Quote

Do you know if it still hits if its not upx packed?

It sure does, along what I can only qualify as all the other 16 idiotic engines who clearly have no clue about what they're analysing and also report a false positive:

https://www.virustotal.com/gui/file/94bd317e4621f4d05279d55c1a73bc51f7f89a5da3d6c68427be1754775a0d3b

The above is for the UPX decompressed version of [1] above (executable can be found from the artifact at https://github.com/pbatard/rufus/actions/runs/2784628339).

THIS is why I just don't have the time to go around every AV vendor out there and report a false positive, because, from the inconsistencies I can formally demonstrate, they are much more interested in crying wolf than anything else.

While I understand that you can of course only vouch for the MB engine (who, at least, is consistent there), if one is doing a proper job, then a decompressed UPX exe should produce the same results as a compressed...

Also the file has a rcdata resource section but they are all empty. that may be triggering the heuristic.  

The file was generated in a completely transparent fashion by MinGW through GitHub Actions, using a fairly standard build process. See https://github.com/pbatard/rufus/runs/7638715538?check_suite_focus=true

So, if this is what you are going for, I am going to posit that I should not be the one who has to modify their build process so as not to trigger AV detection. Instead, it should be the exact opposite, with AV vendors being smart enough not to be tripped by an empty resource section when there's nothing malicious actually going on there...

[Porthos]

7 minutes ago, Akeo said:

Well, those executables were produced days before the one I reported as fp, and they don't appear to have self corrected...

The installed Malwarebytes gets corrected. Virus total is way behind as the Malwarebytes scan engine on VT is different than the one in the program.

 

[shadowwar]

The way the heuristic works is it looks for file anomalies. Having empty resource sections for example is something that is seen in malware.  Also its 24 hours from first scan of the file. If the file was digitally signed with a valid signature we could whitelist that signature for all builds. Basically something in your build process is something similar to malware files we have seen. 

Edited August 17, 2022 by shadowwar

[Akeo]

4 minutes ago, shadowwar said:

Having empty resource sections for example is something that is seen in malware.

And now you have seen it in non-malware, therefore, I will argue that you should stop using that rule to qualify an executable as potential malware or, better, refine your rule so that your previous malware sample that had this property still gets flagged (through the use of other characteristics), but innocuous applications that also have this property don't.

I hope you can appreciate that if we go that route, then there's not much that's going to be left for legitimate application developers not to have their executable flagged as malware eventually, if all it takes is a property, that does not qualify as malware per se, to trigger a false positive. That's pretty much the same issue as what we have with the inordinate amount of engines that continue to see the use of UPX compression as an indicator of potential malicious behaviour (instead of just reporting on the uncompressed version of the file). Again, I will reiterate that this is in part why it is exhausting for developers to try to engage with AV vendors, because there's no denying that there's often a strong preference there to prefer "wider nets" over "accuracy of results" (and yes, I do understand where this comes from, since accuracy of results is hard, but when 16 engines are jumping into the same bandwagon and are misclassifying a specific type of build from the exact same source, and not another, I can't help but think that there is definitely a problem that should be fixed there).

20 minutes ago, shadowwar said:

If the file was digitally signed with a valid signature we could whitelist that signature for all builds.

That's a NO_GO for me.

I've happened to have to switch signatures (including CN) in the past, so that last thing I want, if that happens again, is for a dozen AV engines to suddenly declare my application as malware just because I switched signatures.

This also means that we'd be creating two classes of digital signatures: ones that have been whitelisted by major AV vendors and ones that have not, which of course makes trying to steal the credentials for the former quite a juicy prospect, and would have the consequence of painting a nice "Hey, you should try to hack those guys" target on some developers' backs, when such information becomes public...

Besides, it is again my opinion that the presence of a signature (or UPX compression, or an empty resource for that matter) should really have no play when it comes to classifying something as malware, and I am therefore hoping that MalwareBytes can do a bit better than that to solve this specific issue...

[shadowwar]

Ok so my only option was to whitelist it for the specific engine detecting it. This has been done and should be forward looking for version changes. Its not as effective as whitelisting by signature but should work unless you drastically change things. This will be out next update. 

[Akeo]

I appreciate that. Thanks!

[Akeo]

I'm afraid I have to report that I am not seeing much change, more than a month after reporting this false positive.

The latest MinGW builds of Rufus (which is uploaded to VirusTotal straight from GitHub Actions) are still regularly flagged with Malware.Heuristic.1003, despite the fact that not much of the code has changed.

See https://www.virustotal.com/gui/file/7fc870b9c96ae35365fd8fdaef19a6a4117fc5f033809d5a4bc2161bf9eae699/detection (for an executable that was built less than 24 hours ago) as well as the GitHub Action build that produced this executable at https://github.com/pbatard/rufus/actions/runs/3056234089/jobs/4930181344.

So, once again, I will have to reiterate my call for the MalwareBytes staff to do a bit better than report of whole class of binaries as potentially malicious, on account of a rule that should no longer, on its own, be used for such classification when you now have valid counter examples of legitimate executables that also match said rule.

Thank you.

[shadowwar]

The system did autolearn this executable and its not detected on client machines. Note on new executable after first scan of an unknown it cant take up too 24 hours to autolearn. We are still addressing the issue with virustotal reporting incorrectly because they have trouble reaching our cloud.  I added another whitelist definition but not sure if that will help any. 

Edited September 15, 2022 by shadowwar

[Akeo]

Thanks for the update. Obviously I'll keep monitoring the situation over the coming weeks to see if VirusTotal manages to get the updates from your cloud...

[Pop_Rockz]

On 8/3/2022 at 9:42 PM, Akeo said:

Hi,

Once again, the unsigned MinGW build of Rufus (which is built in a fully automated fashion from our public source by GitHub actions here and can also be downloaded here)  is being flagged by Malware byte as malware (Malware.Heuristic.1003).

See https://www.virustotal.com/gui/file/8aed4efd42410e8c5148e741353dc5dc7d9c25ffff4f74f309e239a85be600a9/detection

Whereas for previous releases, the false positive seemed to disappear after the file was digitally signed, there is no reason why the unsigned version of the executable should be flagged, especially when it can be formally demonstrated that the binary can only have been produced from the public source at https://github.com/pbatard/rufus.

So could Malwarebytes please fix these obnoxious false positives so that they stop occurring?

Thank you.

MinGW.zipUnavailable

I think that's coz a malware does exists by the name of rufus. Its around 300MB. I downloaded it once by mistake while trying to download the real Rufus and got my system infected. Had to wipe my drive and do a clean OS install.

[Akeo]

3 minutes ago, Pop_Rockz said:

I think that's coz a malware does exists by the name of rufus. Its around 300MB. I downloaded it once by mistake while trying to download the real Rufus and got my system infected. Had to wipe my drive and do a clean OS install.

If AntiVirus solutions were based, even remotely, on malware sharing the same name as a legitimate application, or even including the legitimate binary as part of their payload (which can also happen, in order to trick end users into thinking that they are running the application after malicious content has been installed), to declare legitimate executables as malware, they'd be doing a pretty poor job, as any malicious actor could create something like a malicious `word.exe`, that would result in the official Microsoft Word being flagged as malicious.

Thankfully, I am not aware of a single AntiVirus solution that can be tricked that easily, precisely because that's the basic of what one would expect security solutions not to be able to be fooled with.

Humans on the other hand will be tricked into thinking that, because malicious software shares the same name as legitimate one, they are the same thing, and not look any further as to whether they got it from the official website or whether its uses a digital signature that is valid and that bears the expected name.

Also, considering that Rufus should be famous to be a very small executable (it's currently a 1.3 MB download), if you are downloading a 300 MB executable, you should be asking yourself some questions...

[Pop_Rockz]

6 hours ago, Akeo said:

If AntiVirus solutions were based, even remotely, on malware sharing the same name as a legitimate application, or even including the legitimate binary as part of their payload (which can also happen, in order to trick end users into thinking that they are running the application after malicious content has been installed), to declare legitimate executables as malware, they'd be doing a pretty poor job, as any malicious actor could create something like a malicious `word.exe`, that would result in the official Microsoft Word being flagged as malicious.

Thankfully, I am not aware of a single AntiVirus solution that can be tricked that easily, precisely because that's the basic of what one would expect security solutions not to be able to be fooled with.

Humans on the other hand will be tricked into thinking that, because malicious software shares the same name as legitimate one, they are the same thing, and not look any further as to whether they got it from the official website or whether its uses a digital signature that is valid and that bears the expected name.

Also, considering that Rufus should be famous to be a very small executable (it's currently a 1.3 MB download), if you are downloading a 300 MB executable, you should be asking yourself some questions...

Ya lol, it was my fault I downloaded the wrong file. I just wrote it. It was my first time downloading rufus when that happened. I had no idea what's it actually size was. I don't spend my time downloading rufus every single day to be familiar with its size lol.

[Pop_Rockz]

And regarding antivirus software being tricked, I have no idea about other antivirus but mine definitely got tricked. I'm running paid version of Norton 360. It didn't flag it as malware when I tried to run it, but after executing it, Norton notified me that it stopped a malware from trying to infect my PC. Later on it kept notifying that it stopped some large outbound traffic from my system so I thought it would be best to wipe my system. 

[Akeo]

18 minutes ago, Pop_Rockz said:

I have no idea about other antivirus but mine definitely got tricked.

It got tricked, as most antivirus will when it comes to brand new malware (since malware is designed to evade detection before it is put in the wild, at which stage security researchers or AV vendors will pick it up and make sure AV definitions are updated to detect it), but this has nothing to do with your earlier statement, which was that antivirus software could have been tricked through the use of a same name, which is just plain wrong.

And I'll also tell you, it's a bit concerning that Electron-based software has led to people thinking that downloading an application that is larger than 100 MB to perform one easily describable task (such as creating boot media) is perfectly acceptable... At any rate, the official Rufus homepage tells you that the application is small ("Despite its small size, Rufus provides everything you need"), and also gives you the expected size for the download. So I would again encourage you, when you want to download software, especially software that is available for free, to double check that you are downloading from an official size, and not from a sleazy ad link that is likely to peddle malware...

[Pop_Rockz]

I never wrote that antivirus software can be tricked through the use of same name. I just stated a malware exists by the name of Rufus. Read again! How Norton got tricked, I have no idea.

I was looking for Rufus not just to create a bootable USB drive but to download an older version of Windows10, specifically version 1909 from 2019, which I'm curently using right now. I have no idea if Rufus is electron based or something else based software. Average users are not aware of such details like whats its based on or how large its size is lol. And that malware had its own website. I happened to download it from its own fake website. I tried googling it again to post its link here but can't find it anymore. 

[Akeo]

11 minutes ago, Pop_Rockz said:

I never wrote that antivirus software can be tricked through the use of same name.

Well, you quoted "Once again, the unsigned MinGW build of Rufus is being flagged by Malware byte as malware" to reply "I think that's coz a malware does exists by the name of rufus.".

So, whereas I'm trying to reevaluate the context of what you intended to mean, it's very difficult not to read your interjection as a means to explain that MalwareBytes mistakenly flagged Rufus as malware because there does exist a malware by the name of Rufus.

I guess I'll let others decide whether my interpretation of what you said speaks to them or not, but I really does seem to me like you were trying to explain the false positive through a case of same-name trickery.

[Pop_Rockz]

First, I am not some antivirus expert or software expert. I just stubled upon this thread because I was researching for an alternate AV software to replace my Norton 360 since it obviously failed to do a proper job last time.

Second, I have no idea how AV software works. I just saw your post of Rufus being flagged as malware so I decribed my personal experience. That's why I clearly started with "I think..............." I clearly described my mistake but somehow you got triggered and wrote this:

7 hours ago, Akeo said:

Also, considering that Rufus should be famous to be a very small executable (it's currently a 1.3 MB download), if you are downloading a 300 MB executable, you should be asking yourself some questions...

Cheers, have a good day.

[Porthos]

10 minutes ago, Pop_Rockz said:

I was researching for an alternate AV software to replace my Norton 360 since it obviously failed to do a proper job last time.

Malware distributors now bloat their files by making executables that are too big for any installed AV. They also make ISO disk images of the malware as well to fool AV's.

Many of these are coming from Discord downloads now.

You can at least take the time to upload it to Virus Total. before opening. Even doing that is not going to 100% protect you.

 

 

[Pop_Rockz]

13 hours ago, Porthos said:

Malware distributors now bloat their files by making executables that are too big for any installed AV. They also make ISO disk images of the malware as well to fool AV's.

Many of these are coming from Discord downloads now.

You can at least take the time to upload it to Virus Total. before opening. Even doing that is not going to 100% protect you.

 

 

Ok, thanks for the info. Really appreciate the information. I'll be more careful from now on.