So two programs from CPUID. I wonder if there are more affected.
Same topic on Reddit at https://news.ycombinator.com/item?id=47718830 @dang
Supply chain attacks are easier because changelogs for most software are useless now if they are provided at all.
>Dear All, I'm Sam and in I'm working with Franck on CPU-Z (I'm doing the validator). Franck is unfortunately OOO for a couple weeks. I'm just out of bed after worked on Memtest86+ for most the night, so I'm doing my best to check everything. As very first checks, the file on our server looks fine (https://www.virustotal.com/gui/file/6c8faba4768754c3364e7c40...) and the server doesn't seems compromised. I'm investigating further... If anyone can tell me the exact link to the page where the malware was downloaded, that would help a lot
>Thank you. I found the biggest breach, restored the links and put everything in read-only until more investigation is done. Seems they waited Franck was off and I get to bad after working on Memtest86+ yesterday :-/
>The links have been compromised for a bit more than 6 hours between 09/04 and 10/04 GMT :-/
so, it appears that the cpuid website was compromised, with links leading to fake installers.
> (because i am often working with programms which triggering the defender i just ignored that)
This again shows the unfortunate corrosive effect of false-positives. Probably impossible to solve while aggressively detecting viruses though.
Looking forward to information down the line on how this came about.
which you can install with:
winget install --exact --id CPUID.CPU-Z
v1.63 updated 6 days ago https://github.com/microsoft/winget-pkgs/tree/master/manifes... via https://winstall.app/apps/CPUID.HWMonitor
v2.19 updated 15 days ago https://github.com/microsoft/winget-pkgs/tree/master/manifes... via https://winstall.app/apps/CPUID.CPU-Z
Other than that, WinGet is mostly just "run setup.exe". It is not a package manager. It's basically MajorGeeks as a mediocre CLI.
> Q: Why the heck did you hyperlink [the malware installer]?
> A: If someone reads this and they still click the download then they kind of deserve the virus tbh
- CachyOS packages should be coming from known, trusted CachyOS and Arch Linux maintainers. There is still potential for them or their original packages to get compromised (See XZ backdoor) however they are pulling source code from trusted sources so you can generally trust these as much as your trust the OS itself.
- AUR packages are a complete wild west. AUR packages are defined by PKGBUILD files and I highly recommend learning how to read PKGBUILDs and always reading them before installation and re-reading them when they are updated. PKGBUILDs for AUR packages can be treated as untrusted shell scripts and to a certain extent an arbitrary actor can make and upload any PKGBUILD to the AUR. Feel free to use them, but make sure A) they are downloading from trusted sources like the original git repo and B) they are running commands that are expected.
EDIT: Improved accuracy.
Well, the enterprise version of ms defender will not only react to it if it does something "weird", but will specifically look at its "reputation" before it runs at all.
However, as another commenter pointed out, this generates a ton of false positives. Basically everything that's "brand new" is liable to trigger it. Think your freshly compiled hellow_world.exe. So, all in all, people may no longer pay attention to it and just click through all warnings.
I think devs should avoid distributing their software on first party sites unless they're willing to dedicate a bunch of time to making sure all the infra is secure. Not a lot of people verify signatures, but it's also good to have your PKI in order (signing keys should be available on multiple channels)
The script lived above the web root, so they'd have to escape that to tamper with it, and was generated by another script.
Saved me a couple of times since, well worth the 15 minutes I spent on setting it up.
As I recall, they recommended putting the expected values on a floppy disk and setting the ‘write protect’ tab, so the checksums couldn’t be changed.
Yes, a very difficult problem, compilers must be pure functions with thin effectful wrappers.
Wait, how often does your Wordpress site get successfully hacked like that?
One time the hosting provider got compromised, FTP server exploit IIRC, they ran a recursive search and replace from root directory of the server.
All updates are manual, and are done via pull requests. Check everything in-queue: https://github.com/microsoft/winget-pkgs/pulls
Existing versions don't tend to have their metadata updated (I'm not sure winget would accept it). Only new versions are supported.
You can see all the checks that go into cpu-z updates with the latest PR: https://github.com/microsoft/winget-pkgs/pull/349095
> All updates are manual, and are done via pull requests.
The pull requests can be and some are automated, so not all are manual. But more importantly, how would it help?
> Existing versions don't tend to have their metadata updated (I'm not sure winget would accept it). Only new versions are supported.
The attack is version update! How is the old manifest version relevant here?
> You can see all the checks that go into cpu-z updates with the latest PR:
> Description : Invoke an Azure Function > Static Analysis > Status: Started > Status: InProgress
Excellent, now how can I get the answer to the question from this valuable information?
Visitors to the CPUID website were briefly exposed to malware this week after attackers hijacked part of its backend, turning trusted download links into a delivery mechanism for something far less welcome.
The issue hit tools like HWMonitor and CPU-Z, with users on Reddit and elsewhere starting to notice something wasn't right when installers tripped antivirus alerts or showed up under odd names. One example that did the rounds had the HWMonitor 1.63 update pointing to a file called "HWiNFO_Monitor_Setup.exe," which is not what anyone went there to download, and a pretty clear sign that something upstream had been tampered with.
CPUID has since confirmed the breach, pinning it on a compromised backend component rather than tampering with its software builds.
"Investigations are still ongoing, but it appears that a secondary feature (basically a side API) was compromised for approximately six hours between April 9 and April 10, causing the main website to randomly display malicious links (our signed original files were not compromised)," one of the site's owners said in a post on X. "The breach was found and has since been fixed."
The files themselves appear to have been left alone and remain properly signed, so it doesn't seem like anyone got into the build process. Instead, the problem sat in front of that, in how downloads were being served. For anyone who hit the site during that stretch, though, that distinction offers little comfort. If the link you clicked had been swapped out, you were pulling whatever it pointed to, whether you realized it or not.
Analysis shared by vx-underground says the malicious installer appears to have targeted 64-bit HWMonitor users and included a fake CRYPTBASE.dll designed to blend in with legitimate Windows components. That DLL then reached out to a command-and-control server to pull down additional payloads.
From there, things escalate. Analysis suggests the malware tries to stay off disk as much as possible, leaning on PowerShell and running largely in memory. It also pulls down additional code and compiles a .NET payload on the victim machine before injecting it into other processes. There are also signs it's going after browser data. In testing, it was seen interacting with Google Chrome's IElevation COM interface, which can be used to access and decrypt stored credentials.
The same analysis suggests links to infrastructure used in earlier campaigns, including one targeting FileZilla users, hinting that this wasn't a one-off experiment but part of a broader playbook.
CPUID says the issue is now fixed, but there's still no detail on how that API was accessed or how many people actually pulled the bad downloads. Even so, it's another reminder that attackers don't need to touch the code itself to cause harm. ®