[CRASH] Crowdstrike is Killing UniGetUI

[twight-lightbox]

Please confirm these before moving forward.

• I have tried deleting a folder named UniGetUI under %UserProfile%\AppData\Local\UniGetUI.
• I have tried reinstalling UniGetUI.
• I have tested that this issue has not been fixed in the latest (beta or stable) release.

Describe your crash

My company is using Crowdstrike for security. The Falcon Sensor on my laptop is killing the UniGetUI process soon after launch with the following message: "A suspicious .NET module was loaded into the process. Adversaries may load malicious .NET assemblies into a process in order to conceal the execution of malicious payloads. Investigate the process and surrounding events."

We have contacted Crowdstrike support and they say they are aware of these alerts, but don't have a plan or date to mitigate the false alarms (assuming they are false alarms).

I thought you should be aware of this since Crowdstrike is used by so many organizations. I recently upgraded from WingetUI and have not been able to run the new version since.

Logs (if possible)

A suspicious .NET module was loaded into the process. Adversaries may load malicious .NET assemblies into a process in order to conceal the execution of malicious payloads. Investigate the process and surrounding events.

Message from Crowdstrike Falcon Sensor.

More details

No response

[marticliment]

I am aware, different people have reported this issue to me, but there seems to be no way for me, a developer, to report a false positive on my app.

[twight-lightbox]

Well, for better or worse, we have reported it to them and will continue to bother them until it is fixed.

[jessiewestlake]

Same issue in my organization, with a slightly different message. Still mentions being a suspicious process.

[marticliment]

Please test UniGetUI 3.1.2

[jessiewestlake]

I still seem to experience the same behavior with version 3.1.2.

Interestingly, I can run the WingetUI.exe that is included as part of the installation in the same folder
– %UserProfile%\AppData\Local\Programs\UniGetUI — as the UniGetUI.exe and the WingetUI.exe does not get flagged and terminated by CrowdStrike. It runs fine. Both on version 3.1.1 and 3.1.2

[marticliment]

Just to check things twice, both executables are identical, right?

[LRomano72]

Just to check things twice, both executables are identical, right?

@marticliment - tested with v3.1.2 and if I load the WignetUI.exe (705 KB) it will load correctly and CrowdStrike does report any issues.
App said it would update to 3.1.3 on close, it did, both EXE's are no 711 KB - when I run WingetUI.exe - it works and finds new packages to update.
Running UniGetUI.exe - will trigger CrowdStrike to terminate the process, happens after the UI loads and seems to be scanning for packages or something.

Hope this helps.

[marticliment]

Please talk to CrowdStrike (I have tried, but they don't accept feedback from devs), as you will see it makes no sense that from two exact same files one can be executed and the other not just by the filename... I expected better from an entreprise-grade AV...

[smadgerano]

Can I politely offer an alternative perspective.

Crowdstrike is doing exactly what it should, literally flagging that a "suspicious .NET module was loaded into the process". Just because it's suspicious doesn't necessarily mean it's bad, just that there is enough "suspicion" for it to get flagged for attention and inspection.

Step two in the process is that the agent has observed enough activity surrounding the event for it to warrant killing the process.

The task is not on Crowdstrike to mark the code here as not suspicious but on the organisations running Crowdstrike to manage that risk, and the developers to understand why the process may trigger such events.

So if you as an organisation believe the activity is either a false positive, or a level of acceptable risk for the hash of that particular file, then you have the option to mark it as such. I AM NOT ADVOCATING YOU DO THIS UNLESS YOU KNOW WHAT YOU'RE DOING AND HAVE SIGN OFF FROM THE SECURITRY TEAM TO DO SO. just that this would be the usual process.

Then my next question would be to the developer, what is the intention of the code here, and are we sure we're doing everything in the right way? - not accusing anybody of anything, code is complex, but are there acceptable methods of achieving the process that perhaps haven't been met for some reason?

Again, please don't take this the wrong way, just saying that perhaps we're missing something? :)

[marticliment]

@smadgerano, I see what you mean, but the nature of UniGetUI requires it to launch executables and subprocess and load .NET dependencies at some times.

Furthermore, if the process has to be flagged as suspicious, shouldn't WingetUI.exe, which is an exact copy of UniGetUI.exe be also be flagged?

[smadgerano]

the nature of UniGetUI requires it to launch executables and subprocess and load .NET dependencies at some times.

Absolutely, and that's a common task for many applications, it's not unusual. I would not expect an application that does that to be flagged purely on those actions if performed correctly.

Furthermore, if the process has to be flagged as suspicious, shouldn't WingetUI.exe, which is an exact copy of UniGetUI.exe be also be flagged?

I'm not an expert in either of these topics, but something that comes to mind is how are those files generated, is one built copied and then renamed, or are they both built independently?

[marticliment]

I'm not an expert in either of these topics, but something that comes to mind is how are those files generated, is one built copied and then renamed, or are they both built independently?

After build, UniGetUI.exe gets digitally signed. Afterwards, UniGetUI.exe gets copied via the copy command on Command Prompt to WingetUI.exe

[marticliment]

They are the exact same file:

[smadgerano]

Perhaps this is down to pure file reputation then, almost stands to reason that the hash and old filename would have a history of previous use right, but maybe the hash associated with the new name is causing uncertainty. The more it's used, the more confident the system becomes that's it's fine, in the same way Windows Defender will always prompt for "new and unusual" applications it's not got enough data for in order to be familiar with.