Windhawk snitches to my employer 🙂

[HaveSpacesuit]

When I install Windhawk on my Windows 11 work machine (either the global or the user-specific set up), I get a bunch of warnings from the CrowdStrike Falcon Sensor security software. It terminates the program and declares it has found malicious behavior. Then I get an email from corporate asking me what I'm up to. 😱

I've used the 7+ Taskbar Tweaker for years with no problems, but just upgraded to Win 11 and wanted to "fix" things. Any idea what could be causing this, and if there may be a reasonable fix?

[HaveSpacesuit]

It may have something to do with the VSCodium.exe file.

[m417z]

I'm not sure what exactly triggers CrowdStrike to mark Windhawk as having malicious behavior. It's not very surprising, though, as Windhawk injects code into all running processes, which is not something an average program does, and is a technique that's often misused. 7+ Taskbar Tweaker is probably not marked both because it only injects code into explorer.exe, and because it's a well known tool that's available for many years. If you can contact CrowdStrike and ask them about it, that would be great.

Regarding VSCodium, it's an open source project based on Microsoft's code which Windhawk uses for the UI. It's probably being detected just because it was started by windhawk.exe which is flagged.

In the next version of Windhawk, I'd like to add an option to exclude processes to inject code into, so it will be possible to configure Windhawk to only customize explorer.exe, like 7+ Taskbar Tweaker does. That might make it more compatible with security tools.

[m417z]

With Windhawk v1.0, it's now possible to exclude processes in Windhawk. Please try it and let me know whether it helps.

[59e5aaf4]

Yup, CrowdStrike Falcon monitors injections, even if they won't publish the list of hooked kernel/userland functions for obvious malware development reasons. They record that in the InjectedThread telemetry events, which just stores the process info, thread ids, the threadstartaddress and 512 bytes of thread start data.

Whenever there's an alert, dubbed MaliciousInjection by CS, here is what happens:

• Detect Desc.: A suspicious process injected into another process in an unusual way. Investigate the process trees for the injector and injectee.
• Pattern Desc.: Prevention, process killed.

That's a really impressive feat you achieved with this piece of software, congratulations. It's hard not to make snarky comments on Microsoft numerous different policies on window UI settings over the ages. I can't show you much, but from the CrowdStrike telemetry, you can correlate InjectedThread data and figure out that over a specific time frame on a random host with Windhawk, there's an intense hooking activity. In our case, here, just a few injections in teams and some random setup files.

It's a good idea to have a system to decide whether to inject or not in processes, obv stay away of lsass, and maybe don't touch processes owned by S-1-5-18 or admin accounts ?

I found your project when I finally found a way to correlate process ids to process names ( ahem ), and thank you for making it obvious in your documentation that you're injecting dlls, and for writing https://m417z.com/Implementing-Global-Injection-and-Hooking-in-Windows/ which is a gem.

If you want to protect windhawk from being killed by CS, you'd have to pop a separate process for each injection you do, so that if it's killed because the CS bouncer says you're not invited to party in msteams.exe, it's just a temporary process that gets killed and not the main one.

Have fun !

[m417z]

It's a good idea to have a system to decide whether to inject or not in processes, obv stay away of lsass, and maybe don't touch processes owned by S-1-5-18 or admin accounts ?

Some of the processes, such as lsass, are protected processes, so Windhawk can't inject code into them even if it wanted. Also, by default, Windhawk has a list of system processes such as svchost.exe which it avoids injecting into them, too. This can be customized in Windhawk's advanced settings. For example, more processes can be excluded or all exclusions can be removed.

If you want to protect windhawk from being killed by CS, you'd have to pop a separate process for each injection you do, so that if it's killed because the CS bouncer says you're not invited to party in msteams.exe, it's just a temporary process that gets killed and not the main one.

That's not an easy change and I'm reluctant to implement it only as a workaround for CrowdStrike. Also, CrowdStrike may be able to realize that those processes have the same origin and just terminate the process tree. Otherwise, it would be a handy workaround for malware too. On the other hand, it may work, who knows. In any case, it's a fragile workaround that I'd rather not have.

[59e5aaf4]

Here's a random list of processes that got killed because they got injected, we have 0 clue why specifically these when there are tons of other processes being injected on our hosts with windhawk:

• Dell-Command-Update-App.EXE
• Microsoft VS Code\Code.exe
• Microsoft\Teams\current\Teams.exe
• vscode-stable-user-x64\CodeSetup-stable-(hash).exe
• Dism++x64.exe

I don't think windhawk.exe itself gets killed, rather it's the injectee processes that are definitely killed by CrowdStrike.

There's not much problems to solve here, but I just thought of yet another unwanted feature ( :D ) , where you could check if the injectee process has been violently killed after injection (e.g. https://github.com/ramensoftware/windhawk/wiki/Mod-lifetime got interrupted and there might(???) be broadcasted info about the killing method), and track that in a local blacklist of injection targets.

Also, you already reported possible AV issues in https://github.com/ramensoftware/windhawk/wiki/Troubleshooting#windhawk-isnt-usable-or-causes-problems for your users, I'm not sure why I'm writing this down then 🙃

Have a nice day, cheers !