[Bug] pueued being flagged as Trojan:Win32/Bearfoos.B!ml by Windows Defender

[pfmoore]

Describe the bug

I installed pueue on Windows 11 via scoop. I started pueued using pueued -d and ran a few tasks to test the program out. After a while I got an alert saying that Windows Defender had detected and quarantined a trojan, classified as Trojan:Win32/Bearfoos.B!ml. Checking the logs, the executable was pueued.exe.

Steps to reproduce

Not sure - start pueued -d and wait a while.

Debug logs (if relevant)

No response

Operating system

Windows 11

Pueue version

3.1.2

Additional context

No response

[Nukesor]

Well, this is weird.

How are binaries built

I just took a look at it and scoop just uses the pre-installed binaries from the Github release page.

The way these binaries are built is via this automated release pipeline:
https://github.com/Nukesor/pueue/blob/main/.github/workflows/package-binary.yml

As soon as a new git tag for pueue shows up, the binaries are uploaded and published.
I feared for a moment that they were changed afterwards, but it looks like the upload date of the binaries is that of the release pipeline.

Checking them in an online tool

Virustotal

Virustotal categorized releases 3.1.2 and 3.1.1 of pueued as BehavesLike.Win64.Dropper.tc . I also decided to go a bit back in time and let Virustotal check the pueued v2.0 release and holy shit, that thing lit up!
According to Virustotal, the pre-build binaries of this project are straight from hell :D.

v2.0.0
v3.1.1
v3.1.2

Kaspersky

Kapersky however, which I trust much more as they're actually quite competent, showed all of those binaries to be 100% clean.
v2.0.0
v3.1.1
v3.1.2

Analysis

Let's just assume that this is a real issue. If Virustotal and Windows defender are correct, the pueue project is the victim of a supply chain attack since more then a year. Meaning that there would need to be a poisoned crate in the windows ecosystem that hasn't been detected for a really long time.

To be honest, I find that quite unrealistic. But even if it wasn't, we should start to see a pretty big fallout in the windows ecosystem right now.

Assessment

Personally, I think that this is a false positive. From my understanding Anti virus programs analyze program behavior and try to detect malicious programs based on certain heuristics.

Pueued acts very much like a remote command & control server (which is even more true for Windows, as it doesn't have unix sockets), which is basically what black hats use to control a system, once they managed to deploy a rootkit. I wouldn't be surprised if a heuristic was triggered by its normal behavior.

False
positives
seem
to
be
quite
common

Further steps

I'm not sure what the correct way forward is for such a scenario is.
I don't own a Windows PC and can thereby not properly test/verify this, nor do I know what to do to circumvent such a warning.

To be honest, if this is a false positive I don't really feel like taking care of this, as I don't want to spent time to fight against anti-virus heuristics for an OS I don't use.

If I can assist you in any way to determine whether my binaries are poisoned or if you can point me to a direction on how to easily tell Microsoft that my binaries aren't trojans, I'll happily do so.

Until then, I'm not sure what the next step should be.

[Nukesor]

If you know your way around systems programming, you could take the equivalent of windows' strace and run pueued to see what it does before it gets scrapped by Windows Defender.

As long as there's no visible weird behavior, you should definitely be good to go :)

[pfmoore]

Thanks for the very detailed investigation, I really appreciate it! As you say, I don't think there's a real issue here, it looks more like a false positive from the checker (which I believe uses heuristics which can be fooled, so that's not unlikely).

I don't know of a way to report false positives to MS, unfortunately, but I'll do some digging and see what I can find. The annoyance is that the checker "quarantines" the files (i.e., deletes them!) so the program isn't usable if it does so. You can, however, tell it to ignore the file, it's just that you need to wait for the alert and then manually say "ignore".

(Update: I reported the issue via the "Feedback Hub" - https://aka.ms/AAjvf9b, although that link may only work on Windows as it opens the feedback hub app for me. I'm not sure there's much chance they'll do anything with it, but at least it's on record).

One minor thing that would have been useful when I was checking everything was OK, would have been if the hashes for the release files were published here - is that something you could add to the release process? It's not a huge deal if not, it would just have been a small extra reassurance.

Again, thanks for the help here. I was mostly reporting it in case others hit the same issue - so I'm fine with leaving it as simply a false positive from Windows Defender.

[Nukesor]

That's a good point :)

I'll take a look how to include the hashes in future releases :)

[Nukesor]

I'll keep the issue open for a bit, so other people can quickly spot it and chime in :)

If anybody else hase more info about this topic, I would be interested to hear about it!

[Nukesor]

I talked with a good friend of mine and they told me that this might also be triggered by upx. This obfuscates the contents of the binary (through compression) and thereby triggers some heuristics, as binary obfuscation is usually a technique used by malicious actors.

It might be a good idea to disable upx for windows builds.

[pfmoore]

Awesome! Once again, many thanks 🙂