Malware Detection?

[kk-slide]

I was looking around for something just like this, but ran into a snag downloading the source code.

Malwarebytes stopped the download, saying it was malware.
From what I can tell this isn't really malware, so do you know why there might be a false positive?
Thanks!

[leecher1337]

Some crappy Antivirus products will flag ldntvdm.dll loaders as malware.
The most likely reason is that the loader needs to use process propagation and injection methods to ensure that it gets injected into every process in the system in order to work properly (as the process creation code of the Windows system libraries needs to get patched in order to re-enable DOS/Win16 support and several bugs in Windows also need to get patched, further information can be found in the sourcecode of the loader).
For example, the loader needs to use some shellcode to do a proper 32->64bit process propagation and is doing this with some well-known shellcode that is also available in the Metasploit framework.

As you can imagine, malware also often has the same goals - inject into every process, but not for good, but for evil purposes. Now some Antivirus programs want to be smart and use a "generic" approach for Malware detection instead of relying on signatures. So some AVs mistakenly think that the NTVDMx64 loaders are new malware.
Some other AVs find the Metasploit shellcode for process propagation and flag it as malware, even though it is not used for bad purposes.
And yet some other AVs have very bad signatures and mistake the loader for a sample of another malware (iirc, Windows Defender i.e. has a bad signature for Wacatac!ml and thinks that the loader is this malware sample).

Now, generally one can submit the files to the AV vendors and report them as false positives. The good AV companies then analyze the loader and find out themselves that it is harmless and whitelist the sample in their definition update.
Some shitty AV vendors just refuse to do so for no apparent reason (I also experienced this).
But the problem remains: As soon as the loader code is modified due to an update, you have to submit the new loader again and get another whitelisting from all vendors that report false positives which is quite time consuming and as said, some AV vendors even just ignore you, even though they can read the full source code and compare it with the .dll.

Some personal experienced examples on how stupid generic signatures acutally are: I wrote other software and packed some executable sections together to make the .exe file smaller (Just merged sections, this is completely valid). Which was enough to trigger some generic signatures (for some AV vendor, packed executable - which is completely legitimate - was enough to trigger a generic signature - can you believe that? This behaviour just plain stupid!).
And I once wrote an application whose sole purpose was to reconnect disconnected network drives. Roughly 50 lines of C code. 50% of all AVs on virustotal.com flagged it as a virus! That gave me an impression how bad these generic signatures really are.

So I guess it's helpful if a significant amount of people complain to their AV vendor about the false positives so that they whitelist the loaders, but remember: It only lasts till the next update, then we have to play the whole game again.
So the easiest method is possibly whitelisting the loaders yourself and thell your AV to leave it alone.

In case you don't trust the compiled loaders, you can always compile them yourself with Visual Studio 2015 Community edition (newer versions might also work), full sourcecode is available.