This is not a theoretical attack path. It is a documented, active, observed campaign. And the implications extend well beyond the specific malware involved.

Who This Campaign Is Actually Going After

The first thing worth understanding about this campaign is that it is not random. The utilities it impersonates CrystalDiskInfo, HWMonitor, Display Driver Uninstaller, FurMark, K-Lite Codec Pack, PDFgear are tools that people with high-performance GPUs use. Hardware enthusiasts. Overclockers. Gamers running serious rigs. Developers running local AI inference. The kind of people who ask AI chatbots technical questions about their hardware.

That targeting is deliberate. The attackers are not trying to infect the largest possible number of machines. They are trying to infect the machines with the most GPU horsepower, because GPU horsepower is what cryptocurrency mining runs on. A single high-end gaming rig or workstation GPU generates dramatically more mining revenue than a dozen office laptops. The campaign is optimising for value per compromise rather than volume of compromise which reflects a level of strategic thinking about return on investment that you do not see in commodity malware operations.

But the cryptomining is only part of what this campaign is doing. Every machine it compromises also gets ScreenConnect installed that is legitimate commercial remote access software configured to phone home to an attacker-controlled server. So the victim has a cryptominer running on their GPU and an open remote access channel that the attacker can use whenever they want, for whatever they want: exfiltrating data, deploying ransomware, using the machine as a pivot point into other systems on the same network.

The mining pays the bills. The backdoor is the long game.

How the AI Delivery Technique Actually Works

Before April 2026, this campaign was using standard SEO poisoning manipulating search engine rankings to put malicious sites in front of users searching for legitimate software. That technique is well-documented, increasingly countered by search engine quality improvements, and the subject of security awareness training at organizations that have taken the threat seriously.

What Microsoft observed in April represents an evolution. Users who asked AI chatbots where to download specific system utilities received responses that included links to attacker-controlled domains. The chatbot did not know the sites were malicious. It was surfacing recommendations based on whatever information its training or retrieval systems had absorbed and that information had been poisoned.

The psychological difference between a malicious search result and a malicious chatbot recommendation is significant and worth sitting with for a moment. When a search engine returns a result, users have developed at least some habit of scrutinizing the URL, checking whether the domain looks legitimate, being skeptical of results that seem off. That skepticism took years to develop and is still imperfect, but it exists.

When an AI chatbot answers a question with a recommendation, the framing is different. The user asked for help. The AI provided a personalized, conversational response. The social trust embedded in that exchange is higher than the trust users place in a ranked list of search results from an algorithm they know is gameable. Clicking a link a chatbot recommends feels different from clicking a search result and attackers have figured that out.

Microsoft called this “AI search result poisoning” an extension of traditional SEO poisoning into the AI response layer. That framing is accurate, but it understates what makes the technique dangerous. It is not just a new distribution channel. It is a higher-trust distribution channel that reaches users whose defenses against search result manipulation do not automatically transfer to AI recommendation manipulation.

The Attack Chain, Step by Step

Here is exactly what happens when someone falls for this campaign.

They click the link from the chatbot response. They land on a convincingly designed site that looks like it hosts the software they wanted. There is a download button. They click it. They get a ZIP file.

Inside the ZIP is a legitimate version of the software they asked for it actually installs and works alongside a malicious DLL called autorun.dll that nobody told them about. When they run the legitimate installer, autorun.dll gets sideloaded silently in the background.

That DLL installs a second malicious DLL vcredist_x64.dll, named to look like a standard Microsoft Visual C++ component that would not raise eyebrows in any process log. This DLL is actually a packaged installer for ScreenConnect, the remote access software. ScreenConnect installs and immediately starts trying to reach an attacker-controlled server.

Once that connection is established, the attacker pushes through an executable called SimpleRunPE.exe. This is where it gets technically sophisticated. SimpleRunPE sets up persistence through Registry Run keys and scheduled tasks so it survives reboots. It configures Microsoft Defender exclusions so the mining payload does not get flagged. It runs checks to detect whether it is in an analysis environment. And then it uses process hollowing injecting its actual malicious code into the memory space of a trusted, Microsoft-signed process to launch the miner. From the outside, the mining code appears to be running inside a legitimate Windows process, which is specifically why signature-based detection struggles to catch it.

The malware also watches for security tools Task Manager, Process Hacker, Process Explorer, System Informer and immediately shuts down the miner if any of them appear, then restarts it when they are gone. It recreates its persistence mechanisms and Defender exclusions continuously, so removing them once does not stick. Three miners are supported depending on the GPU: gminer, lolMiner, and SRBMiner-MULTI.

In some variants, instead of using ScreenConnect’s file transfer to drop the payload, a PowerShell script fetches the binary from a remote drive, saves it locally as vlc.exe the name of a completely legitimate and ubiquitous media player creates a scheduled task to run it, and then deletes the script. The file sitting on the machine looks, to a casual inspection, like VLC Media Player.

This is not amateur work. The effort invested in evasion, persistence, and believable cover stories across every stage of the chain reflects threat actors who understand enterprise security tooling well enough to design around it.

Three Campaigns, One Pattern

The Microsoft report puts this cryptojacking campaign alongside two other documented intrusions, and it is worth understanding why because the thread connecting them says something important about where sophisticated attack tradecraft is going.

The second campaign Microsoft documents began with a compromised F5 BIG-IP firewall. The attacker got into an internet-facing appliance, used that foothold to reach an internal Linux host, did extensive reconnaissance from there, found a vulnerable Atlassian Confluence server, and worked through a creative chain setting up an FTP server using Python’s ftplib module, transferring a custom scanning tool, pulling credentials, launching Kerberos relay attacks, exploiting CVE-2025-33073 to eventually compromise a SaaS application and conduct relay-style authentication attacks against Active Directory.

The third campaign did not rely on vulnerabilities at all. Attackers compromised a third-party IT services provider and used that provider’s legitimate access and management tools to establish persistent, credential-stealing access inside client environments. The attacker authenticated to a Linux server over SSH with a privileged account and maintained that access throughout without ever installing persistence mechanisms. The trusted relationship was the persistence mechanism. The environment appeared compliant the entire time the attacker was inside it.

What connects these three campaigns is not technical similarity. It is strategic similarity. Every one of them exploited something the target trusted: AI recommendations, legitimate software packaging, internet-facing infrastructure with established access paths, third-party service providers with standing credentials. None of them needed to break through a hardened defense. They found a door that was already open because something on the other side of it was trusted.

Microsoft put it directly in the report: threat actors leverage legitimate components, trusted update paths, and approved integrations to anchor themselves inside environments that appear compliant on the surface.

What to Actually Do About This

The defenses that work against these campaigns are not about adding more tools. They are about changing some assumptions.

On the AI delivery technique: Your security awareness training probably covers search engine poisoning. It almost certainly does not cover AI chatbot recommendation poisoning as a distinct attack surface. That gap needs to close. Users who understand that search results can be gamed but have not been told that AI recommendations can be gamed will apply skepticism in the wrong place. Add it to your training. Specifically. With examples.

If your organization deploys AI tools for employee use, evaluate whether those tools have any filtering or flagging capability for external download links in generated responses. Most do not today. That is a problem worth raising with your vendors.

On the ScreenConnect backdoor: Do a straightforward audit. Find every ScreenConnect installation in your environment. Any instance that was not provisioned through IT-managed deployment processes is a red flag. Any Microsoft Defender exclusion that was not set through standard IT policy channels is a red flag. The campaign sets both as part of its installation routine, and neither is something that should exist without an explicit, documented, IT-approved reason.

On the process hollowing evasion: If your endpoint detection relies primarily on process name matching or signature scanning, the mining payload in this campaign will run inside a trusted Microsoft-signed process without tripping those controls. Behavioral detection that identifies anomalous resource consumption, unexpected network connections to mining pool infrastructure, or unusual memory patterns inside trusted processes is what catches this. If your EDR is not doing behavioral analysis at that level, this campaign will run quietly for as long as the machine stays online.

On over-privileged identities and third-party access: The SSH-with-sudo-rights access that the third-party intrusion exploited is the kind of thing that persists in environments because removing it requires coordination and someone needs to own the effort. Make someone own it. Privileged accounts used by third-party providers need behavioral monitoring, session logging, and periodic review confirming that the activity profile matches what is expected. Accounts that have not been used in 90 days should not retain standing privileged access. These are not novel recommendations. They are recommendations that become urgent when Microsoft documents a campaign that exploited exactly this attack surface in April 2026.

The Underlying Shift These Campaigns Are Telling You About

Take a step back from the technical details and look at what these three campaigns have in common at the strategic level.

Sophisticated attackers are not primarily trying to break your defenses. They are trying to use the trust relationships your environment depends on. AI tools that users trust for recommendations. Legitimate software that antivirus tools trust. Remote access tools that IT processes trust. Service providers that your authentication infrastructure trusts. Internet-facing appliances that are trusted to filter traffic before it reaches your internal network.

Each of these trust relationships was established for good reasons. They make environments function. The problem is that trust, once established, tends to get assumed rather than continuously verified. Defenders check whether the firewall is running. They do not continuously validate that the firewall’s behavior matches what a legitimate firewall should be doing. They confirm that a service provider has the right credentials. They do not monitor whether those credentials are being used in ways consistent with the service agreement.

Microsoft‘s recommended defensive posture is deliberate verification trust your vendors and tooling, but validate their behavior within your environment. That sounds simple. It is actually a significant operational change for most security programs, because it requires building monitoring and verification infrastructure around the things that are currently treated as inside the trust boundary rather than at the edge of it.

The campaigns documented in this report are not going away. The AI delivery technique will spread to other malware families now that it has been demonstrated to work. The third-party trust exploitation model is already well-established and will keep being refined. The process hollowing and persistence techniques in the cryptojacking campaign will get copied.

The defenders who are going to handle this environment well are the ones who stop treating trusted components as outside the monitoring perimeter and start treating deliberate, continuous verification as the standard operating assumption for everything including and especially the things that have always worked fine before.

Research and Intelligence Sources: Microsoft

To participate in our interviews, please write to our CyberTech Media Room at info@intentamplify.com