Windows Defender identifies llvm-strings.exe as Trojan:Win32/Acll

[mxk]

I'm guessing this is a false positive, but still wanted to mention that mingw64\bin\llvm-strings.exe in winlibs-x86_64-posix-seh-gcc-13.2.0-llvm-18.1.3-mingw-w64ucrt-11.0.1-r7.7z is being identified as Trojan:Win32/Acll on Windows 11 23H2.

[brechtsanders]

My build system was also Windows 11 23H2, using Defender as antivirus, and I got no alerts.

Were you also using Defender or a different antivirus software?

[mxk]

Also using Defender, but on a company-managed computer, which has everything under "Virus & threat protection settings" enabled. If you have any MAPS or other cloud-related settings turned off, that may be the reason why.

[juanmbt]

I got the same alert on my pc running Windows 10 Home 22H2 (Build 19045.4291).

I did a full offline scan of the 7z file, and only llvm-strings.exe was detected.

I uploaded it to Virus Total and got 30 detections:

https://www.virustotal.com/gui/file/084b09fcab3d3b0812873c876fdbd1797f4a31384e0b00253b44ac29116ffb6a

[brechtsanders]

Looks like generic/heuristic detections, so still seems like false positive.

Though 30 false positives on VirusTotal is a lot.

[brechtsanders]

Is the same false positive present in the release from https://github.com/mstorsjo/llvm-mingw/releases ?

[mxk]

No, neither llvm-mingw-20240417-ucrt-x86_64.zip nor llvm-mingw-20240417-msvcrt-x86_64.zip trigger any Defender alerts. I don't know if it matters, but the ucrt version of llvm-strings.exe in that zip is about half the size of the winlibs version.

[juanmbt]

I re-scanned the original compressed file after updating the definitions in Defender. Now I got two new alerts:

The original reported alert, and these two:

Trojan:Win32/Wacatac.H!ml nvptx-arch.exe

Trojan:Win32/Znyonm UnicodeNameMappingGenerator.exe

[brechtsanders]

It's not uncommon for antivirus heuristics to find threats in software development tools (assemblers, compilers, linkers).

From my side all I can say is that I really built everything from source, down to each and every dependency.

So in theory, if these are not false positives, either the code was compromised before I compiled it, or the binaries were comprimised after (the checksum files are there to detect tampered with files after I published them).

How can we be certain these are false positives?

[YouriAndropov]

Same here, defender alert on llvm-enabled builds. Workaround : download non-llvm releases :)

mingw64\bin\UnicodeNameMappingGenerator.exe -> Trojan:Win32/Znyonm mingw64\bin\nvptx-arch.exe -> Trojan:Win32/Phonzy.A!ml mingw64\bin\llvm-strings.exe -> Trojan:Win32/Acll

[clearoce]

Same as YouriAndropov and an additional trojan of Virgof.A, and all of these don't appear in winlibs-x86_64-posix-seh-gcc-13.1.0-llvm-16.0.5-mingw-w64ucrt-11.0.0-r5.7

[anirban6996]

I used brave to download it, brave said it's unsafe and promoted If I should keep it or not, then when unzipping bitdefender kicked in and quarantined the files, also I scanned with virus total I got detections

[ghost]

[lucascampolimm]

Results from Malwarebytes Anti-Malware

Trojan.Crypt.Generic, C:\MINGW64\BIN\AMDGPU-ARCH.EXE Trojan.Crypt.Generic, C:\MINGW64\BIN\LLVM-STRINGS.EXE Trojan.Crypt.Generic, C:\MINGW64\BIN\UNICODENAMEMAPPINGGENERATOR.EXE Trojan.Crypt.Generic, C:\MINGW64\BIN\NVPTX-ARCH.EXE

[brechtsanders]

I created new releases. Can you please tell me if your virus alerts are gone in these releases?

• https://github.com/brechtsanders/winlibs_mingw/releases/tag/13.2.0posix-18.1.5-11.0.1-msvcrt-r8
• https://github.com/brechtsanders/winlibs_mingw/releases/tag/13.2.0posix-18.1.5-11.0.1-ucrt-r8

[YouriAndropov]

I tested the ucrt x64 release r8 and it seems OK now. I think Harsh Kumar Narula was right and the infection was real.

[lucascampolimm]

New results from Malwarebytes Anti-Malware, UCRT version. To date, I haven't encountered any issues with these releases, but I felt it was important to report these detections.

Malware.AI.4095755650 C:\MINGW64\BIN\AMDGPU-ARCH.EXE Malware.AI.4031154886 C:\MINGW64\BIN\LLVM-STRINGS.EXE Malware.AI.4196497163 C:\MINGW64\BIN\UNICODENAMEMAPPINGGENERATOR.EXE Malware.AI.3214030154 C:\MINGW64\BIN\NVPTX-ARCH.EXE

[plashenkov]

Have you gained an understanding of what was the cause of the possible infection? To prevent this from happening in the future.

[YouriAndropov]

@lucascampolimm are you talking about the revision 7 or revision 8 ? It is quite unclear. My windows defender couldn't find any threat in the latest build.

[juanmbt]

I dowloaded the R8 UCRT LLVM x64 file: winlibs-x86_64-posix-seh-gcc-13.2.0-llvm-18.1.5-mingw-w64ucrt-11.0.1-r8.zip

Got these detections:

Trojan:Win32/Wacatac.H!ml mingw64/bin/amdgpu-arch.exe

Trojan:Win32/Phonzy.A!ml mingw64/bin/llvm-strings.exe mingw64/bin/nvptx-arch.exe mingw64/bin/UnicodeNameMappingGenerator.exe

[lucascampolimm]

@YouriAndropov I tried out the r7 first, and then I gave the r8 a go.

[brechtsanders]

If r8 also shows the threats than I'm even more convinced these are false positives, especially since some antivirus scanners label the threats as generic or heuristic, meaning they don't match actual signatures of know viruses.

Add to that that it's only in LLVM binaries, not in all the rest, which was also build on the same build system.

[YouriAndropov]

Tested again and this time defender found Trojan:Script/Wacatac.H!ml… Maybe safer to stick to non-llvm releases until we know for sure.

[brechtsanders]

Question: I just released GCC 14.1.0 builds. Does this change anythinwith regards to the virus alerts?

[plashenkov]

My Windows Defender finds no threats in GCC 14.1.0 + LLVM.

Release 8 of GCC 13.2.0 was the same just after its release (no threats), but after some time Defender began to show the alerts.

[PyryLaa]

My antivirus (F-secure) flagged: -UnicodeNameMappingGenerator.exe with Trojan.TR/AVI.Agent.cbart -nvptx-arch.exe with Trojan.TR/AVI.Agent.miqlr -llvm-strings.exe with Trojan.TR/AVI.Agent.wolyp -amdgpu-arch.exe with Trojan.TR/AVI.Agent.knzjf

Using winlibs personal build version gcc-13.2.0-llvm-18.1.5-mingw-w64ucrt-11.0.1-r8

[YouriAndropov]

Defender now finds Trojan:Win32/cerber on winlibs-x86_64-posix-seh-gcc-14.1.0-llvm-18.1.5-mingw-w64ucrt-11.0.1-r1.7z following files:

• libLLVMNVPTXDesc.dll
• libLLVMX86Desc.dll

Still unsure of what to think about these alerts.

[lucascampolimm]

https://www.virustotal.com/gui/file/6ad191561595d4359d2e3efc65c7e0168f592ed96a8680f4c1f711914cb7ed6b/behavior

Why does nvptx-arch.exe delete folders and registry keys related to Google Update?

[Alcaro]

In this context, "dropped" usually means created (as in dropped onto your hard drive), not deleted.

Completely agree it has no business touching any of those files, though.

[brechtsanders]

Are the virus alerts for LLVM components still present in these last releases?

• https://github.com/brechtsanders/winlibs_mingw/releases/tag/14.1.0posix-18.1.7-12.0.0-ucrt-r2
• https://github.com/brechtsanders/winlibs_mingw/releases/tag/14.1.0posix-18.1.7-12.0.0-msvcrt-r2

The build system used to build these releases has been scanned with multiple virus scanners and nothing was found.

[YouriAndropov]

Hello, Trojan:Win32/Phonzy.B!ml detected on : winlibs-x86_64-posix-seh-gcc-14.1.0-llvm-18.1.7-mingw-w64ucrt-12.0.0-r2.7z File : UnicodeNameMappingGenerator.exe

[brechtsanders]

How can we confirm if these are false positives?

[YouriAndropov]

What about https://www.microsoft.com/en-us/wdsi/filesubmission/ ?

[brechtsanders]

Based on the suggestion here to add an icon to the .exe files I have modified my LLVM build to actually use a resource file (which was apparently only the case for MSVC builds). And I modified the resource file to include an icon.

Can you please check if this makes any difference in the virus detections?

The updated files are the ones including llvm in the name at these links:

• https://github.com/brechtsanders/winlibs_mingw/releases/tag/14.1.0posix-18.1.7-12.0.0-ucrt-r2
• https://github.com/brechtsanders/winlibs_mingw/releases/tag/14.1.0posix-18.1.7-12.0.0-msvcrt-r2

[YouriAndropov]

Trojan:Win32/Wacatac.B!ml found in winlibs-x86_64-posix-seh-gcc-14.1.0-llvm-18.1.7-mingw-w64ucrt-12.0.0-r2.7z File : UnicodeNameMappingGenerator.exe

[brechtsanders]

@YouriAndropov is this the same as before? Did you also only have this one match before? Which antivirus was this?

[YouriAndropov]

Yes, same file but different threat. It's windows defender.

[brechtsanders]

I have reported one of the releases to https://www.microsoft.com/en-us/wdsi/filesubmission/ for further investigation.

[CagesThrottleUs]

Redownloaded the entire LLVM + GCC in latest after the logo - no issues from BitDefender side. Thanks for the update.

[brechtsanders]

@CagesThrottleUs Glad to hear that.

So apparently adding an icon / adding a resource file to the build does make a difference...

[mxk]

I am no longer getting alerts from winlibs-x86_64-posix-seh-gcc-14.1.0-llvm-18.1.7-mingw-w64ucrt-12.0.0-r2.7z. r1, which didn't have the icons, was still blocked.

[brechtsanders]

Well, I did report this issue to Microsoft, so they are probably looking into it.

[gwenning-arcfield]

I received threats from Sentinal One against winlibs-x86_64-posix-seh-gcc-14.1.0-llvm-18.1.5-mingw-w64ucrt-11.0.1-r1.zip. New zip file at https://github.com/brechtsanders/winlibs_mingw/releases/tag/14.1.0posix-18.1.7-12.0.0-ucrt-r2 worked! Thank you for your excellent support!

[TaylorMater]

Windows Defender would not let me download the most recent release twice, then after temporarily turning it off, I was able to download it, but the following file was quarantined immediately:

I do want to play with g++ and clang, but I think I will stick with MSVC until I get a linux dev box.

[drmolix]

I think I will stick with MSVC until I get a linux dev box.

I think this is the reason they keep flagging these files as a virus. They want to force their compiler into our lives.

[TaylorMater]

More like force me off of their operating system, but I hear you. I just don't want to take chances though.

[AlexanderEvans]

I'm getting a warning from the most recent build too and it's immediately quarantined. Is it possible there is some kind of sophisticated injection occurring similar to what happened with XZ Utils, or could there be some persistent undetected malware on the build computer? I'm not super familiar with how exactly winlibs/mingw work, but I just wanted to throw some things that came to mind out there in case someone more knowlegable than me can think of anything. In older versions I really loved the simplicity of winlibs, and how easy it was to use as a drop in for cross platform development with minor tweaks. Unfortunately I'm stuck on windows and I prefer GCC, and I would like to still have all this tooling. I don't want to have to use wsl, especially as I want to be able to distribute executables to people easily that they can just run. Winlibs has been a great solution so I hope this can get resolved...

[brechtsanders]

@AlexanderEvans If you prefer GCC, then why do you download the file with LLVM?

Can you confirm the downloads without LLVM are okay for you?

The winlibs build of LLVM uses GCC's standard libraries, which is not ideal.

For those who want to use LLVM/Clang on Windows I recommend using https://github.com/mstorsjo/llvm-mingw

The ticket I made to Microsoft about the Defender false positives is still in progress :-(

[juanmbt]

I downloaded the 64bit non-LLVM version: winlibs-x86_64-posix-seh-gcc-14.1.0-mingw-w64ucrt-11.0.1-r1.7z

No detections when extracting, I scanned the extracted files again and I also got no detections.

[TaylorMater]

@brechtsanders I totally forgot I could get a non-LLVM version, downloaded it and no threats.

[AlexanderEvans]

@brechtsanders I like to just have all the tooling in case I need it mostly for convenience in testing edge cases. And I'll occasionally use it for linting... at least I think that was it.... you can tell how often I fiddle with it by my uncertainty x3 Linting is such a 'set it and forget it' type of thing most of the time.

I'm curious what you mean about the winlibs build of LLVM using the GCC standard libraries? Is there another implementation they usually use, and why is that not ideal?

I could probably grab the version without llvm, but until it's confirmed the detection is a false positive, or we know the attack vector through which the infection occurred I'd rather not download either version just to be safe.

I may be a bit overly cautious and paranoid, but I prefer to take the stance of "it's better to be safe than sorry" in such cases.