MBINCompiler.exe has a range of suspicious behaviors triggering anti-virus heuristics

[jgentil]

It looks like Windows Defender has started triggering on MBINCompiler.exe. I'm not in favor of blindly listening to someone on Discord tell me to "just trust it" so I did some digging and analysis. Here's what I came up with.

First, here are the results I am basing this analysis on: https://www.virustotal.com/gui/file/43d86aa6426c85dbe8864791dbf57a74ba5db80bcd33ea7c65d988dce84985c2 https://www.hybrid-analysis.com/sample/43d86aa6426c85dbe8864791dbf57a74ba5db80bcd33ea7c65d988dce84985c2/624269100ddfe67d881a6312

VirusTotal is an anti-virus response aggregator showing which anti-virus software flagged this as malware. Hybrid-Analysis is a freemium tool created by CrowdStrike using it's Falcon platform, a highly advanced sandbox malware scanning tool that logs literally every little thing an application does when it runs and then categorizes each action by how suspicious it is, especially in relation to one another. This is often what the machine learning algorithms in anti-virus apps do as well.

In this case the various AV in VirusTotal seem to indicate a generic malware detection triggered by their machine learning heuristics. This coincides with the 6 Suspicious Indicators that were flagged by Falcon. Some of them are boring or automatic things that .NET does itself.

The first is an unfortunate side-effect of reverse engineering NMS itself: It's getting upset over the words ExoticExtra1 ... ExoticExtra6. I don't specifically know why though. Something about anti-reverse-engineering?

Another issue is that it's original filename is MBINCompiler.dll. Now I know that a Windows PE DLL and EXE are incredibly similar and can be interchangeable, but it's flagging this really hard.

It looks like the register command may also be triggering issues, as it modifies the system path.

It considers debug information suspicious in general. the .rdata (debug section) section in the .EXE file and the PDB embedded information is triggering it as suspicious as well. It's weird because the build is a release build but still has an AppHost.pdb embedded in it?

I think what's much more concerning, is that as I wrote this and tested a few other release versions, I found that v3.72.0-pre1 had a malicious URL embedded in it, discovered in memory, pointing to v.beahh.com which is flagged as a malware cryptominer data collection endpoint.

The analysis of that version is here: https://www.hybrid-analysis.com/sample/09b73802bad9f2af4cfa5ce9d60d058f8e473a1d444d7dac12a08a359bbb5496/62427cbabff8b86e83078bf6

You may want to check to make sure you don't have a library dependency carrying a malware package. Is Dependabot enabled on the repository? This might be a red herring of sorts but I'd rather be safe than sorry. This may have damaged the AV reputation of the app significantly.

[monkeyman192]

Thanks for the detailed analysis. I'll try look into this. I honestly don't have much experience with this so if you have any pointers on what to add that would be appreciated! Also, would you be able to run this analysis on the source code when you build it yourself (if possible?)

[cmkushnir]

• ExoticExtra1 - 6: Those are the values in one of the enum's the code defines. False positive.
• MBINCompiler.dll and AppHost.pdb - It's a .NET app. .NET uses a thin exe launcher that loads the actualy code in the dll. So the default build creates the MBINCompiler.exe (launcher stub) and MBINCompiler.dll (actual code). The AppHost.pdb is likely coming from the lanucher stub. The CI has instructions to merge the two into a single exe for distribution, and I guess that stuff is included.
• v.beahh.com - that would warrant further anaylsis. of all the stuff reported, this would seem to be the only thing of sig concern. I also assume you've verified your system isn't infected and injecting that into every app that launches.

[monkeyman192]

To comment on the last point. I got the hybrid-analysis site to analyse the binary directly from the github download (ie. I just gave it the path to the binary) and it gives the same result, just to verify this point.

[cmkushnir]

The report said that v.beahh.com was discovered in the network traffic, but I didn't think MBINCompiler.exe did any network calls, so not sure where that would come from.

[jgentil]

I did a build using Visual Studio 2022 Community Edition and it got these results:

https://www.virustotal.com/gui/file/6ea05591fa5e2a5a5c2dc2248b27fdf6a6610dde73ce9f8208369225db5d0a4e https://www.hybrid-analysis.com/sample/c31b1729810ee866a774ac425fa98738a2d2e8c969216f00da892f8514985e3f/6244889c0c0170259c6ac294

So it looks like my version doesn't have the v.beahh.com URL issue, but it does seem to flag two AVs as suspicious. Weird. I wonder if there's just something in the code itself that looks odd and is flagging it. I'll do some deeper analysis into the code itself, though I am not fluent in C# or Microsoft compile tools so it may take a bit of digging.

[HolterPhylo]

AVs will flag stuff regularly as they use pattern matching.
I have personally submitted to Bitdefender .exe I've modded/build so they would stop flagging them as 'false positive'. In my opinion, that is not 'weird' but just then result of the process in use to scan files in a very fast way so as not to disturb (too much) the usability of personnel computers.

[HolterPhylo]

I found that v3.72.0-pre1 had a malicious URL embedded in it, discovered in memory, pointing to v.beahh.com which is flagged as a malware cryptominer data collection endpoint.

If v3.72.0-pre1 is problematic, could we just 'remove' it from the release list? We have v3.72.0-pre2 that better covers 3.72 anyway

[carrow26]

Removing some projects from the Visual Studio solution improves VirusTotal behaviour. In VS2019 I have produced smaller versions of MBINCompiler.exe by just including MBINCompiler (Console EXE) and libMBIN (Shared) projects in the solution. I used 4.5.2 framework (which VTotal seems to prefer to Core) and did not use the supplied solution and project files but rebuilt from scratch, including the supplied source files. VTotal seems to prefer Release builds to Debug.

For 3.71.0.2 (Release): https://www.hybrid-analysis.com/sample/3a63052a35871196054ad450cac47fb274563b20232ad80d7288bc2c5364b926

For 3.82.0.2 (Debug): https://www.hybrid-analysis.com/sample/4885908d9d9e98295ecc16bde260185275ad179b20461b7289080c1935efe099/62571ce85d91fe2c4859028e

[HolterPhylo]

It is only an issue if you let it be an issue for you! Otherwise it is fine and only a 'false positive'

[cmkushnir]

When I look at the details of those reports, with the understanding of what the code does and how the assets are built, to me it seems like they don't know how to recognize single exe .NET builds. Almost all of the items seem related to what VS is likely adding during CI build, not what is in the code. That said, it may be worth recreating the solution|projects at some point, if only to take advantage of the newer lighter formats and to ensure any old cruft is removed.