Hey all,
This is the first time I tried building runtime, so I apologize if this is something that is already been addressed.
I ran the command:
build -subset clr+libs -runtimeConfiguration Release
and Windows Defender screamed with this trojan in the runtime folder:

https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?Name=Trojan:Win32/Wacatac.D!ml&ThreatID=2147749373
I can confirm this is happening for me too.
@jeffschwMSFT
We have seen this before and what we have done is let defender know that this is a false positive. We are not sure what about that binary is causing it to trigger.
@swaroop-sridhar
Thanks, I'll make sure I do that.
It warns about it as a different trojan as well:

(thinking out loud) I wonder if some of this is due to the nature of this exe, it is the base of every .NET Core application and runs in untrusted locations (eg. bin directory). This file is run through scans so I am confident that this is a false positive. We will follow-up again with defender to understand why this is being flagged. @swaroop-sridhar
I just got the same as what @stephentoub reports. Maybe preview.3.20169.1 is triggering this?
Given that this is still happening (and has also been reported internall), I'm re-opening this issue.
This should now be resolved. Please reopen if you continue to see false positives.
I just hit this issue with when attempting to install 5.0.100-preview.8.20351.5 using dotnet-install.ps1. @dagood pointed me to this issue and suggested that I post here.

Recapping relevant parts of an offline conversation here:
@vatsan-madhavan:
So does it happen to only some users but not others, or does Defender complain occasionally (for everybody) and needs to be taught not to complain periodically? Or does this only happen when placed in untrusted locations (%temp%) ?
If someone is in this situation, what's the recourse (tell defender to ignore the folder proactively, for e.g.. What happens if there is a real problem) ?
Are these binaries not signed properly that causes Defender to think there is a problem?
@dagood:
these files aren't signed--and they actually can't be signed because they're templates. Customers (using the SDK) need to be able to replace some contents to host their app and then sign it, and if we already signed it, their signing fails.
More info at SignCheckExclusionsFile.txt and linked issue from there.
@MattGal:
it's not signing, the(ir) binary content partially matches the shape of a known virus' signature.
easiest thing to do is to just defender suppress the paths you use them in
Most helpful comment
I just got the same as what @stephentoub reports. Maybe preview.3.20169.1 is triggering this?
Given that this is still happening (and has also been reported internall), I'm re-opening this issue.