Poisoned search is now finding better GPUs

Microsoft describes an active cryptojacking campaign that uses poisoned search results, fake utility download sites, DLL sideloading, and abused ScreenConnect installations to reach machines with stronger GPU value. The interesting part is the target selection. This is not broad spray-and-pray mining. The lure set points at users likely to own high-performance PCs.

Source: Microsoft Security Blog — https://www.microsoft.com/en-us/security/blog/2026/05/26/poisoned-search-results-gpu-mining-cryptojacking-campaign-abusing-screenconnect-microsoft-net-utilities/

What changed#

Microsoft Defender Experts reported a campaign where malicious download sites appeared through traditional search engine poisoning and, based on observed patterns, through AI chatbot interactions.

The campaign impersonates common system and hardware utilities, including CrystalDiskInfo, HWMonitor, Display Driver Uninstaller, FurMark, K-Lite Codec Pack, and PDFgear. That selection matters. Several of these tools are used by PC builders, gamers, troubleshooters, and hardware-focused users. Those users are more likely to have discrete GPUs worth mining on.

The chain starts with a user looking for a trusted utility. A manipulated search result, or in some observed cases a chatbot-generated recommendation, points to an attacker-controlled lookalike domain. The fake site offers a download button. The download retrieves a ZIP archive from a campaign-specific subdomain of gleeze.com, which Microsoft says is hosted by infrastructure associated with Dynu, a dynamic DNS provider often abused by threat actors.

Microsoft says it has identified more than 150 malicious domains since March 2026 that it assesses are serving these masqueraded tools in this campaign.

The payload chain is simple enough to be dangerous. The ZIP contains the legitimate executable for the spoofed utility and a malicious DLL named autorun.dll. When the user runs the legitimate executable, the program loads the DLL from the same folder through DLL sideloading. No exploit is needed. The user may still see the expected application open, which lowers suspicion.

Microsoft found nine distinct autorun.dll variants across the campaign. The malicious DLL then uses msiexec.exe to silently install another DLL, vcredist_x64.dll, named to look like a Visual C++ Redistributable component. That file is a packaged installer for ScreenConnect, also known as ConnectWise Control.

ScreenConnect is a legitimate remote management product. The point is abuse, not a flaw in the product. In this campaign, the attacker uses it to establish persistent remote access.

Why poisoned search matters here#

Poisoned search has always been a good delivery channel because it catches users at the exact moment they intend to install software. This campaign sharpens that model. The attacker is not only trying to rank for generic downloads. The lures are aligned with hardware value.

A fake FurMark or Display Driver Uninstaller download is not random. Those names attract users tuning, testing, or repairing GPU-heavy systems. If the attacker’s goal is mining, that audience is better than a random office endpoint.

The ScreenConnect step also changes the risk. A cryptominer alone is noisy and economically limited. Persistent remote access gives the operator options. Microsoft notes that this access could later support data theft, lateral movement, or ransomware activity. That does not mean every affected host will see those outcomes. It means defenders should not treat this only as a resource-theft incident.

The AI chatbot angle should be handled carefully. Microsoft describes reports and correlated telemetry suggesting that users may have been directed to malicious domains through LLM-based tools. VirusTotal metadata referenced chatbot interactions as a possible referral context. Microsoft also says the example is illustrative and does not indicate a systemic issue with a specific AI service.

That caveat is important. The safe conclusion is narrower: attackers are testing the same trust gap in AI answers that they already exploit in search results. If a tool recommends a download link without strong source verification, the user may treat it as safer than it is.

Operational checks#

For security operations teams, the useful checks are not theoretical. The chain leaves several places to look.

Check recent downloads and execution paths for ZIP archives that contain a legitimate utility executable next to autorun.dll. DLL sideloading often hides behind normal-looking parent processes. The presence of a real vendor tool does not clear the event.

Look for silent installer activity involving msiexec.exe, especially where it follows execution from a user download directory or extracted archive. Microsoft specifically names vcredist_x64.dll as part of this chain, with naming that mimics a Microsoft redistributable component.

Review ScreenConnect or ConnectWise Control installations. A legitimate remote management tool should have a clear owner, ticket, deployment path, and business reason. Unknown or user-context installs deserve priority. The product’s presence is not proof of compromise, but unmanaged remote access is never a small finding.

Watch for DNS and web traffic to recently created lookalike domains tied to popular utilities. Microsoft names campaign-specific subdomains under gleeze.com and notes the parent domain’s infrastructure association with Dynu. Dynamic DNS by itself is not malicious, but it is a useful signal when paired with fake download flows.

For endpoint policy, Microsoft recommends enabling cloud-delivered protection, running EDR in block mode, and enabling attack surface reduction rules. Those controls fit this campaign because the attack depends on downloaded payloads, suspicious child process behavior, and silent installation patterns.

For users and small teams, the practical rule is blunt: do not download system utilities from search ads, random mirrors, or AI-provided links unless you verify the publisher’s real site. When possible, navigate from a known vendor domain, a project’s verified repository, or a trusted package source. Search is a discovery tool, not a trust anchor.

This is also where open source security habits matter. The safer path is not “open source” as a slogan. It is source verification, reproducible or trusted builds where available, signed releases, known maintainers, and a packaging channel with accountability. For more on that operational view, see GigaTap’s notes on making security artifacts useful in practice: https://gigatap.top/en/articles/openssfs-april-signal-make-security-artifacts-operational

What not to overclaim#

This report does not prove that every AI chatbot is poisoning software recommendations at scale. Microsoft’s wording is measured. It points to observed patterns, correlated data, and examples consistent with AI search result poisoning. That is enough to change operational caution, not enough to make broad claims about one AI service.

It also does not mean CrystalDiskInfo, HWMonitor, Display Driver Uninstaller, FurMark, K-Lite Codec Pack, PDFgear, ScreenConnect, or ConnectWise are inherently malicious. The campaign abuses trusted names and legitimate software behavior. That distinction matters for response. Blocking the wrong thing may break operations while missing the attacker-controlled path.

The strongest supported takeaway is that software discovery has become part of the attack surface. Search results can be poisoned. Generated answers can surface unsafe links. Legitimate utilities can be wrapped with malicious DLLs. Remote management tools can turn a mining incident into a persistence problem.

Treat download provenance as a security control, not a user preference. That is the operational change this campaign makes hard to ignore.