netty-tcnative boringssl static windows 2.0.73 binary flagged as malware

[stevebeattie]

The netty-tcnative BoringSSL static artifact as published in Maven Central at https://mvnrepository.com/artifact/io.netty/netty-tcnative-boringssl-static is (probably incorrectly) getting flagged as malware; specifically referring to the netty_tcnative_windows_x86_64.dll embedded in https://repo1.maven.org/maven2/io/netty/netty-tcnative-boringssl-static/2.0.73.Final/netty-tcnative-boringssl-static-2.0.73.Final-windows-x86_64.jar.

This was originally flagged by https://github.com/chainguard-dev/malcontent/ as matching the NitrogenLoader Config Extractor using the incorporated yara rules from CAPEv2 at https://github.com/kevoreilly/CAPEv2/blob/439dc0cf6cc2aa7cd4440f3c45d895c3cf861aa7/analyzer/windows/data/yara/NitrogenLoader.yar#L43-L66 ; I suspect this is a false positive hit as it appears the rules are intended for runtime detection, not on disk detection.

One of the virustotal scanners also flags it https://www.virustotal.com/gui/file/76e95018ca02fd0bbd9686b13bef96694d5814a50eff8d944f665a1a3ea9d4fb/details , but it's unclear what basis it is making that determination on (it may also be using the same yara rules).

Finally, the Hybrid Analysis scanner also flagged the DLL as can be seen at https://hybrid-analysis.com/sample/76e95018ca02fd0bbd9686b13bef96694d5814a50eff8d944f665a1a3ea9d4fb - it is again unclear what this service is flagging the DLL on.

It should be noted that the 2.0.72 version of the BoringSSL static Windows DLL do not trigger:

• the CAPEv2 yara rules
• any of virustotal's engines: https://www.virustotal.com/gui/file/cd9e0bfd6e486319facaa5baebb6c859c9db34f104fb8951f0ac1eefd8a535a0/detection
• the Hybrid Analysis scanner: https://hybrid-analysis.com/sample/cd9e0bfd6e486319facaa5baebb6c859c9db34f104fb8951f0ac1eefd8a535a0

Nor did the linux x86_64 2.0.73 version of the static .so get flagged:

• https://www.virustotal.com/gui/file/9153ca17650f6732d2033c044716b50e25f10f169d85eeab6a333a6e8549f1ed/detection
• https://hybrid-analysis.com/sample/9153ca17650f6732d2033c044716b50e25f10f169d85eeab6a333a6e8549f1ed

I don't see anything in the changes between the 2.0.72 and 2.0.73 releases that would have caused these scanners to trigger, though the change from Windows Server 2019 to Windows Server 2022 is interesting.

I'm submitting this issue to document these findings, though again I suspect this to be a false positive.

[chrisvest]

Yeah, that's weird. The release is always built by GitHub Windows agents, because neither me nor @normanmaurer have Windows machines. It's also the same exact upstream BoringSSL version in both 2.0.72 and 2.0.73. The build agent Windows version got upgraded from Windows 2019 to 2022, as you note, because 2019 build agents are being decommissioned. That's the only thing I can think of that might change the binary enough to accidentally trip some rule.

[chrisvest]

Can we report this as a false positive to the scanners, and get them to clear it?

[stevebeattie]

I submitted a ticket with CyNet, the vendor of the VirusTotal engine that flagged it. I'm not sure how to get someone to investigate the Hybrid Analysis finding. It does look like the latter also uses yara rules, so it may be the same rule tripping under the hood.