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.

[joshbarrass]

Did anything come of any of this? The issue of it referencing v.beahh.com seems pretty serious, and, though it doesn't seem to have reared its head since, it seems like it would be prudent for everyone's safety to figure out what caused it and whether any other versions would've been affected.

The latest version at the time of writing seems to have completely shaken off any anti-virus flags. VirusTotal reports 0/75 detections, and hybrid-analysis seems to think it's clean. So that's good for the latest versions at least.

Interestingly, I just ran v3.72.0-pre1 through the analyser again (on the Windows 10 and Windows 11 systems instead of Windows 7) and the reference to v.beahh.com seems to have disappeared altogether. VirusTotal even now only shows 2 detections from random programs -- I'd expect more reputable anti-virus software to be detecting something after 2 years if there really is something nefarious in there. This isn't really my area of expertise, so maybe I've made a mistake somewhere in running the analysis, but if the same file doesn't consistently produce the same suspicious behaviour, it seems to throw up two possibilities imo:

1) The domain flagged up in the original report in error, or because of something unrelated to MBINCompiler. This would probably be consistent with @jgentil's experience of their builds not throwing up the v.beahh.com issue. That said, I have no idea how that would've happened. 2) There is some hidden malware, but it hasn't triggered in the sandbox since the original analysis. If there is some hidden malware that manages to fly under the sandbox's radar most of the time, then that brings all the analyses of other versions into question as well.

I'm not sure which of these scenarios is most likely. Has anyone (who knows what they're doing, unlike me :sweat_smile:) actually managed to encounter the v.beahh.com issue on the original build artefact since the original report?

[cmkushnir]

No, none of the issues that were raised seemed like a concern. Neither mbincompiler.exe nor libmbin.dll contain v.beahh.com in their code or binary; neither should be making any network calls either. If there are network calls being made then it may be telemetry being added by visual studio, but i also find that unlikely. All-in-all i take all virus-checker results with a grain of salt. The fact that a rerun of 3.72.0.1 does not show v.beahh.com suggests that the virus checker had a bug that they fixed.