TONResolver RAT Abuses TON Blockchain to Target Japan's Hotel Industry

Key takeaways

Attackers are targeting employees of Booking.com partner companies in Japan, using phishing emails that impersonate guest complaints and review requests to trick hotel staff into executing malicious files.
Multiple email delivery methods were observed, including bulk phishing and interactive conversational attacks via Gmail that build initial trust before delivering a malicious URL.
The malware, TONResolver, appears to function as an initial access and command-execution foothold, and observed follow-on activity indicates potential credential theft and further compromise.
By storing the C&C server domain in a TON smart contract, attackers can swap in a new server at any time, even if the current one is blocked or taken down.

In late May 2026, suspicious emails were identified being sent to Japanese partner companies of Booking.com, with the subject line “Important: Guest Stay Review Request” (重要：ゲスト滞在レビュー依頼). In this attack, a zip file was downloaded by accessing a hyperlink to a suspicious web site, and the infection began when the user clicked a shortcut link file (LNK) disguised as a photo file within the zip archive. Unlike conventional phishing campaigns, the malware abuses The Open Network (TON) blockchain platform as a dead drop resolver, a technique that allows attackers to update their command-and-control (C&C) server destination without hardcoding it into the malware, making detection and takedown significantly more difficult.

Upon examining the access patterns of the domain group (CFD TLD, described later in this blog entry) hosting the suspicious web sites listed in the email links, TrendAI™ telemetry confirmed that accesses from the Japan region were the most prevalent. Endpoints infected with the malware, identified as TrojanSpy.JS.TONRESOLVER.A, remain in a persistent Keepalive loop awaiting attacker commands, so the risk of credential theft and additional malware deployment continues so long as the infection is active.

Figure 1. Telemetry plot results from May 17 to June 8

Characteristics of the phishing emails

In the observed attacks targeting Japan, two types of subject lines were identified. By framing the messages as “customer complaints” in the hospitality industry and requesting link clicks and photo viewing, the intent to deceive hotel employees and operators into executing the malicious content was apparent.

These emails were confirmed to have been sent using the notification functionality of a scheduling tool service. As a result, defense based solely on domain authentication technologies such as Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) was insufficient to prevent receipt of these emails.

重要：ゲスト滞在レビュー依頼 (Important: Guest Stay Review Request)
【重要】お客様からの重大な苦情に関するご連絡 (Important: Notification Regarding a Serious Complaint from a Guest)

In addition to the subject lines, distinguishing characteristics were identified in the hyperlink text strings contained in the emails, with the following multiple strings observed:

Download Photos and Videos
証拠写真・動画を確認する (View Evidence Photos and Videos)
添付資料を確認する (View Attached Materials)

Figure 2. Email sample generated by organizing information from reported emails (Japanese)

Translated from Japanese, the email sample in Figure 2 reads as follows:

Booking.com Partner Support

A serious complaint has been received from a guest who stayed at your property from May 11 to May 14, 2026. We kindly ask that you review this matter promptly and take the necessary action.

Content of the guest's complaint:

"Bed bugs were discovered in the room, and my daughter was bitten multiple times during our stay. Concerned about health risks, we visited a medical facility. Photos of the bed bugs are attached as evidence. We strongly request an immediate response."

The guest's name, contact information, reservation number, exact dates of stay, and all evidence related to the complaint are available for download via the link below.

Download Photos and Videos

All information and materials necessary for investigation and prompt response regarding this serious matter are included in the attachment, so please review the contents carefully.

Booking.com Customer Service Team

An English-language email was also observed. Despite being directed at domestic organizations, this attack is presumed to target English speakers. Only one subject line was identified: “Urgent: Bed bug complaint from guest".

Investigation of the hyperlink destination infrastructure and malware revealed information linking this campaign to different emails, and tactics abusing Gmail as a sender were also observed.

In these attacks, we observed a “conversational attack” method used. In this approach, the attacker first sent a normal inquiry email without a URL to the accommodation facility’s contact person, and after receiving a reply, sent a follow-up email containing a hyperlink with a malicious URL. The tactic of gaining the target’s trust through initial correspondence rather than sending a malicious URL in the first email is a technique also common to advanced persistent threats (APTs).

The subject lines observed in Gmail emails are listed below; no Japanese-language ones were found. However, given the characteristics of initiating correspondence while posing as a normal customer using Gmail, caution is warranted as this technique may be employed in future attacks beyond this investigation.

Below is a list of examples of subject lines used in interactive attacks via Gmail^,with {number} containing arbitrary numbers, and {English name} containing strings presumed to be non-Japanese personal names:

Accommodation Inquiry – {number}
Amazing Anniversary visit Extras Costs?
Assessing Hotel Room Availability
Availability Confirmation Needed
Checking Available Hotel Rooms
Checking Hotel Availability for Stay
Disappointed with Room Service
Hotel Accommodation Availability Inquiry
Hotel Accommodation Request
Hotel Booking Availability Status
Hotel Booking Possibilities Check
Hotel Booking Request
Hotel Reservation Availability Inquiry
Hotel Rooms: Availability Status
Hotel Stay Availability Verification
Inquiry About Hotel Stay Options
Inquiry for Hotel Stay Availability
Inquiry: Availability and Total Cost
Looking at Hotel Room Reservations
Looking for Hotel Vacancies
Quick Availability Question
Request for Booking Options
Room Inquiry ({number})
Short Stay Availability Check
Unacceptable Room Condition
Unacceptable Room service
Very bad experience with room service
{English name} {number}

Multiple types of delivery infrastructure used by attackers

Along with multiple email delivery methods, trends were also identified in the initial payload distribution domains that the attackers prepared to redirect victims from emails. Domains linked to the same attacker (or attack group) fell into four top-level domain (TLD) groups, all of which delivered the same initial payload on request.

Figure 3. Duration of domain creation per TLD group (Observation results through June 8)

All TLD groups implemented a mechanism whereby accessing the URL “http://{domain name}/v” triggered the download of a .ZIP file, and it was confirmed that domains were used selectively based on the target email addresses.

These observed domains abused Cloudflare’s infrastructure and used the Cloudflare Name Server pair “galilea” and “moura”. Cloudflare DNS always assigns two name server names per account. Because the probability of two different users receiving the same pair is low, domains sharing a name server pair can be presumed to belong to the same attacker.

For domains created from June onward, the pair changed to “brianna” and “roan”, suggesting that the zones within the account or management procedures may have changed for some reason. Our investigation of URLs from observed emails and domains revealed the classification shown in Figure 4.

As described above, the .COM TLD group was the only one where Registrant (domain registrant) characteristics were uniquely identified. The “ghastlier” domain used in the Registrant Email is a disposable email domain, making long-term continued use difficult. The attacker appears to have set these values for the Registrant Name and Registrant Email.

Figure 4. Results of investigating .COM domains using whois

Infection chain via user execution

The infection begins when a user downloads a zip file via a hyperlink in the email and executes a shortcut link file (LNK) disguised as a photo (PNG) file contained within the archive.

Figure 5. Files contained in the zip archive

The PowerShell command embedded in the LNK file handles two large integers as [System.Numerics.BigInteger] and computes their difference. The resulting value is then repeatedly divided by 256, with each remainder converted to a single-byte character (Char), thereby reconstructing the destination domain. The script then executes Invoke-WebRequest against the reconstructed domain, saves the retrieved PS1 file (PowerShell script file) under "%TEMP%", and executes it with PowerShell. [System.Numerics.BigInteger] has been used from June onward; prior to the end of May, it was defined using [bigint].

Figure 6. Large integer processing using [bigint], employed until the end of May

Figure 7. Large integer processing using System.Numerics.BigInteger, employed from June onward

When communicating externally to retrieve the PS1 file, the domain name generated via System.Numerics.BigInteger connects to the URL of the domain from which the zip file was obtained using Powershell.exe. At this point, the server verifies whether the User-Agent contains the string "Powershell." If "Powershell" is not present (for example, a browser User-Agent), the response is 404 NotFound; if "Powershell" is present, a 200 OK response returns the PS1 file script string. The User-Agent string in Figure 8 below is one that would not normally exist in the wild because a combination of Mozilla and PowerShell is essentially impossible under normal circumstances, yet the server still returns a normal response.

Figure 8. An HTTP/200 OK response is returned, confirming the server's behavior of responding normally when PowerShell is present in the User-Agent

The retrieved PS1 file is invoked with the PowerShell window hidden by controlling ShowWindow. Subsequently, concatenated string fragments define the folder under "%USERPROFILE%\AppData\Local\Nodejs" as the Node.js deployment location, and the subsequent JavaScript payload is saved to the same folder path. The payload save locations are as follows. Additionally, string concatenation is performed to extract node-v24.13.0-win-x64 to the same folder. This Node.js extraction involves downloading from a website described below.

%USERPROFILE％\Appdata\Local\Nodejs\{filename}.js
%USERPROFILE％\Appdata\Local\Nodejs\node-v24.13.0-win-x64\

A multiple-execution prevention mechanism was also incorporated using Get-Process and Where-Object, so that if node.exe from the same folder path is already running on the endpoint, the process terminates with exit 1.

Figure 9. JavaScript payload save location and Node.exe path concatenation processing

Within the script, a 32-byte AES key and 16-byte IV are recovered from a hardcoded Base64 value, and processing for the Mutex name, execution of the subsequent JavaScript payload, and argument decryption are performed.

An encrypted Binary Large Object (Blob), a large chunk of data, is decrypted using AES-CBC (Cipher Block Chaining) to obtain the Mutex name. Multiple-execution prevention via the Mutex name was also implemented. Furthermore, line 77 contains an extremely long Base64 string.

Figure 11. Mutex name processing and Base64 storage location

If Node.exe does not exist, “node-v24.13.0-win-x64.zip” is retrieved from the official Node.js website (nodejs.org) and extracted under "%USERPROFILE%\AppData\Local\Nodejs." String concatenation produces the following URL. In this download, v24.13.0 is specified, and all samples examined at the time of this investigation were confirmed to specify v24.13.0.

https://nodejs.org/dist/v24.13.0/node-v24.13.0-win-x64.zip

Figure 12. Node.js retrieval and zip extraction processing

The Base64 string stored at line 77 is decoded at lines 100–101, and then further decrypted via AES-CBC to generate the JavaScript payload. Additionally, as an argument used during JavaScript payload execution, the encrypted Blob is decrypted via AES-CBC at line 103 to recover the domain name from which the PS1 file was obtained. As a result, execution proceeds as follows:

node.exe {JavaScript payload}.js {DomainName}

Figure 13. Execution argument processing and JavaScript payload execution

Static analysis of the malware TONResolver

The JavaScript file executed with arguments by node.exe (detection name: TrojanSpy.JS.TONRESOLVER.A) was identified as malware functioning as a remote access trojan (RAT). This RAT malware employs VM-based obfuscation, making it impossible to reveal details through pure static analysis alone. By combining static analysis with dynamic analysis to verify its behavior, it was confirmed that the malware uses TON as the resolution target for its C&C server. TON is a blockchain platform that Telegram originally began developing under the name Telegram Open Network; it is currently developed and operated primarily by the TON Foundation.

Abusing legitimate services as a cover is a communication resolution attack technique known as a "dead drop resolver", where the communication destination cannot be identified through simple static analysis alone. Even if an active C&C server is taken down or blocked by some means, this technique enables switching the C&C server's communication destination, making it one of the methods used by attackers to ensure attack persistence.

In VM-based obfuscation, the logic is converted into a custom virtual instruction set, and interpretation causes the Custom VM Interpreter embedded within the script to be executed. Through this interpretation, the Dispatcher routes processing to handlers in the script according to the virtual opcodes, making it difficult to reconstruct and analyze the flow through static analysis alone.

Figure 14. Excerpt of the JavaScript (TONResolver) script

When the code is organized, it becomes apparent that within the JavaScript, the vme(0x…) portions possess a mechanism for decrypting strings, and the vmn_22aed1 portions function as the VM interpreter. By performing string decryption through static analysis of this code, the following functionalities were identified as being implemented.

Handoff to the interpreter

Static analysis of the code revealed a structure in which processing is passed to and called by vmn_22aed1, and vmn_22aed1 is considered to function as a VM interpreter that interprets the obfuscated instructions.

Figure 15. Call processing to vmn_22aed1

Structures related to file operations and information collection

In function “h”, which passes processing to vmn_22aed1, it was observed that modules for performing operating system-level operations, such as “os” and “fs”, are loaded.

Figure 16. Loading of Node.js modules via require

String decryption focusing on functions

Since the original JavaScript is obfuscated, the functions being used are not apparent. Therefore, focusing on the vmz function (which corresponds to the processing that returns string arrays) and the vme function (presumed to be the string decryption portion), the vme(…) calls were decrypted. By examining Base64 strings and plaintext among the decrypted strings, strings related to the following functionalities were identified:

HKCU:\Software\Microsoft\Windows\CurrentVersion\Run
Received message
aes-256-cbc
createCipheriv
createDecipheriv
fetch + https://google.com
secp256k1

Figure 17. Base64 decode results from the section implementing AES encryption processing

Figure 18. Base64 decode results from the section implementing AES decryption processing

Based on these static analysis results, the malware is loaded into Node.js, interpreted and executed through its custom interpreter, and encrypted via WebSocket (ECDH + HKDF-SHA256 + AES-256-CBC). Therefore, it is considered extremely difficult to perform suspicious detection based on packet strings in proxy or network security services.

Additionally, the following tonapi[.]io URL was identified among the Base64 strings and plaintext:

hxxps://tonapi[.]io/v2/blockchain/accounts/ 0:c66119f0e5635c4380441d7a79baf0c02a0ab7ea6cd78de06507fc5dc2c1a5d9/methods/get_domain

By examining this URL, it was determined that rather than holding the C&C server communication destination as a fixed string within the JavaScript, the malware retrieves it via TonAPI — enabling the attacker to easily change the C&C server destination.

The communication destination tonapi[.]io is a legitimate website and service. It was confirmed that the attacker implemented a script in a TON smart contract and embedded the active C&C server domain in methods/get_domain. If the C&C server is blocked, the attacker can send a new string to the TON smart contract, and communication to a new C&C server is automatically initiated.

Dynamic analysis

Including the static analysis described thus far, dynamic analysis was conducted to verify more precise behavior. This confirmed the execution flow after JavaScript execution, which is as follows:

Execution of TONResolver (malware body JavaScript)
Initialization within the execution environment via VM-based obfuscation
Checking for multiple execution via Mutex
Checking and setting Run key persistence (HKCU:\Software\Microsoft\Windows\CurrentVersion\Run)
Connectivity check to Google.com
Access to TonAPI “methods/get_domain”
Retrieval of C&C domain communication destination from TON contract
Connection to C&C domain via WebSocket communication
Key exchange via ECDH secp256k1
Derivation of AES key/IV via HKDF-SHA256
Message sending via AES-256-CBC encryption
Message receiving via AES-256-CBC decryption (C&C server connection established)
Transmission of endpoint information
Keepalive every 20 seconds
Reconnection/re-handshake upon network disconnection
Command reception from C&C server

Additionally, analysis of the sent and received messages during dynamic analysis revealed the following functional classification from type:0 through type:4, which are presumed to correspond to RAT operations. However, type:5 through type:8 are provisional classifications assigned based on static analysis string groups and code analysis.

Type	Frequency	Functional role
type:0	Every 20 seconds during execution	Keepalive (ping) from C&C server → Client
type:1	Immediately after type:0	Keepalive response from Client → C&C server
type:2	At startup + network connection	Sending Client public key
type:3	At startup + network connection	Receiving C&C server public key + salt
type:4	Immediately after type:2 + type:3	Transmission of endpoint information
type:5	Command from C&C server	Interpretation and execution of arbitrary JavaScript strings
type:6	Command from C&C server	Execution result/response processing
type:7	Command from C&C server	File retrieval/execution
type:8	Command from C&C server	PowerShell command execution

Table 1. Observed execution functions and provisional interpretation assignments

The endpoint information transmission in type:4 was confirmed to contain the following information. The "domain" field is assigned as the argument during LNK and PS1 retrieval and execution. Other information includes the endpoint's username, hostname, as well as OS, CPU core count, memory information, and MAC address hardware information.

Figure 19. JSON contained in the “type:4” endpoint information transmission (some values shown as examples)

Up to this point, it was determined that even when a victim user executes the LNK and runs TONResolver via Node.js, this is not an attack that immediately steals files or credentials from the endpoint. However, since the Keepalive communication with the attacker provides the capability to execute additional commands and files, it can be inferred that the attacker selects targets for additional command execution based on the victim's endpoint information and source IP address environment information.

Organizing the flow from the beginning of the attack through to additional command and subsequent malware execution, the process is as follows:

Attacker configures infrastructure and scripts on TON, and updates the C&C domain
Phishing email is sent, and the included hyperlink is clicked
Connection to malicious website photo-*****[.]cfd
Download and extraction of zip file containing malicious shortcut links
User execution of the shortcut link file
Re-connection to malicious website photo-*****[.]cfd for PS1 script download request
PS1 script execution
Retrieval and extraction of Node.zip (Node.exe)
Loading and executing malicious JavaScript (TONResolver) in Node.exe
Connection to TON platform (tonapi[.]io), accessing “methods/get_domain”
C&C domain obtained in response
Connection to retrieved C&C server, public key authentication established (followed by endpoint information transmission)
Keepalive initiated
Attacker selects targets for additional attack execution and sends commands
Command execution and additional malware deployment (credential theft, etc.)

Figure 20. Attack flow from TONResolver to subsequent malware infection

Analysis of blockchain TON contracts and transactions

The access destination for the TON contract abused as a dead drop resolver was the URL obtained through the WebSocket connection to “methods/get_domain” contained in tonapi[.]io, which resolves the C&C server. TON contract Transactions can be viewed by anyone by accessing this tonapi[.]io URL; however, the C&C server is not directly written as a plaintext string:

hxxps://tonapi[.]io/v2/blockchain/accounts/0:c66119f0e5635c4380441d7a79baf0c02a0ab7ea6cd78de06507fc5dc2c1a5d9/transactions

Figure 21. TON contract Transaction verification results

The hex string within the raw_body portion of the TON contract is structured and can be organized as follows when interpreted:

Structure	Data role and interpretation
b5ee9c72	TON Blockchain (BOC) format magic number
0101201002100	BOC overall header, cell, size and other Init information
0110	Data length information for the first cell
17be49cf	op_code
00000014	Length of subsequent
01	Reference index for the next cell
0028	Data length information for the second cell
746f6e616a756b626875616b706f322e73686f70	Hex string of the URL (actual data), C&C server domain

Table 2. Interpretation example of the raw_body contained in Figure 21

When the TONResolver JavaScript is executed, accessing “methods/get_domain” for communication destination retrieval confirmed that this C&C server domain is processed. The response obtained by sending a request to “methods/get_domain” returned the C&C server domain in decoded.domain as shown below.

Figure 22. Response from “methods/get_domain”

By examining the utime (date/time) and Hex strings of each Transaction Hash, it was possible to confirm when each C&C server domain was written to the TON contract by the attacker.

Transaction hash	utime (UTC)	Hex string	C&C server domain
4ec8b349dec92720325aa4cd2637165283ef9b657efed25595d1127e13d9ed6c	2026-06-02 02:53:50	746f6e616a756b626875616b706f322e73686f70	tonajukbhuakpo2[.]shop
ad8a41329520983bd5b87610729aee7bc984a262df0a611efecc1e65d8122ac8	2026-02-20 15:19:03	7a6c6f61706f62696b61687932332e626f6e64	zloapobikahy23[.]bond
5853f2fb23c9824382a29e5094110cafa28cd8bb4b9ecbc6e7f890bf728a0d45	2026-02-09 19:17:05	68736165727479756f616e6733342e736273	hsaertyuoang34[.]sbs
acf58e82c2716e3ca47eca715d318ab5c0fdf2d1bc50f4c89e7a8ad3324e244a	2026-02-07 14:03:27	616d616e6f6875677574612e636664	amanohuguta[.]cfd

Table 3. Transition of communication destinations resolved by C&C server

Organizing the Transactions of the TON contract (0:c66119f0e5635c4380441d7a79baf0c02a0ab7ea6cd78de06507fc5dc2c1a5d9), the following flow was confirmed. Upon examining the source TON contract for incoming funds, deposits were found from a TON contract with name:Huobi set, but no other useful information was identified. The TON contract used by the attacker for C&C server updates is 0:6d5b44d0678e6bd6703f2cabd2531ccf5a0b11cc081f8f7175bd679db4c12d41, and all Transactions originated from this address.

utime	UTC	Hash	Summary
1770471436	2026-02-07 13:37:16	540d78d1b48059f41d1e44f29bb255cfc4c3d628c2a4e2478fcca311c955c232	Approximately 5.99 TON (5.984) deposited. Contract transitions from nonexist → uninit
1770473007	2026-02-07 14:03:27	ed53b4d2adfe22d7e3852667834bb472c7963777c8468c7355d9cc5b08086a6c	“get_domain” code initialized. Contract transitions from uninit → active (initialization). amanohuguta[.]cfd is written
1770664625	2026-02-09 19:17:05	bf72fbba31df1d3699ae7b72dd2737a22c80219e07055db607d17c12cf8ed760	hsaertyuoang34[.]sbs is written via Transaction
1771600743	2026-02-20 15:19:03	0fe5a035b02526ae1ecc1f212aea4564620103ce520532ed3dd6104abb6ac459	zloapobikahy23[.]bond is written via Transaction
1780368830	2026-06-02 02:53:50	aea565f34dff268bbfea6d704d88ed7b198d0470f18a59e7e3468e64e4b9864f	tonajukbhuakpo2[.]shop is written via Transaction

Table 4. Transaction history of the TON contract implementing “methods/get_domain”

The methods of the TON contract are invoked and processed by TonAPI. Through a calculation formula using CRC16, the string called by “methods/get_domain” is converted to a number, and processing is performed according to the TON contract's implementation. Therefore, it is necessary to verify how the attacker's contract calling “get_domain” is implemented. As shown below, the CRC16/XMODEM calculation formula converts “get_domain” to 119378:

crc16(“get_domain”) | 0x10000
==> 119378

The functionality implemented in the TON contract can be examined at the assembly level by obtaining the "code" as a binary file and disassembling it using a library for processing TON-Blockchain (tdisasm). The "data," which is presumed to store the values used by the attacker, can similarly be obtained as a binary file.

Figure 23. Results of retrieving TON contract information

The disassembly results are as shown in the figure below, where line 3 shows the processing for key 0 and line 40 shows the processing for key 119378. Furthermore, line 16 confirms the op_code x{17BE49CF}, which was contained in the TON contract Transaction. This op_code matches the one described in Table 4, indicating that the attacker implemented the TON contract including this processing.

Figure 24. Results of disassembling the TON contract

This language is called TVM Assembly, a constituent language of TON. By reading the TVM Instructions reference provided in the TON Docs, the assembly can be interpreted. The processing identified for key 0 and key 119378 from TVM Assembly interpretation is as follows:

Key0: Update processing from the management wallet via internal messages

Receive internal messages (Transactions) from the management wallet
Read the registered wallet address from the data cell
Compare the sender address of the internal message with the wallet address in the data cell
If they do not match, reject processing with 403
If they match, check whether the body begins with 0x17BE49CF
If it begins with 0x17BE49CF, save the new C&C domain described in the internal message to the data cell

Key119378: C&C domain processing via “methods/get_domain”

When “methods/get_domain” is called, processing for 119378 begins
Read the domain from the data cell
Skip the first 128-bit processing and management wallet address processing
Read the domain length stored in the data cell
Read out the Hex representing the domain string stored in ref[0] of the data cell and return the C&C domain string as decoded.domain

Attack observation by TrendAI Vision One™ Services – Managed Detection and Response (MDR)

Regarding the deployment of subsequent malware following TONResolver, the attack chain was discovered through TrendAI Vision One™ Services – Managed Detection and Response (MDR) observation. Starting from the node.exe process loaded with TONResolver, an executable was deployed to a directory under “%USERPROFILE%\AppData\Local\Temp”, and further execution was found to have attempted credential theft.

Figure 25. Attack chain observed through TrendAI Vision One™ Services – Managed Detection and Response (MDR) analysis

The deployed executable was observed performing operations on the following folders and involving the “C:\Windows\System32\lsass.exe” process. These folders contain browser-stored password SQLite DBs, Cookie DBs, History, autofill, bookmark information, and other data, raising suspicion of exfiltration by the attacker.

C:\Users\<UserName>\AppData\Local\Google\Chrome\User Data\
C:\Users\<UserName>\AppData\Local\Microsoft\Edge\User Data\

This is an ongoing campaign, and TrendAI™ continues to analyze the attack details and scope of impact. If publicly disclosable information regarding subsequently deployed malware is confirmed, an additional article will be published.

Conclusion

This attack campaign targets Booking.com partner companies, abusing TON as a dead drop resolver and applying obfuscation through Node.js. The combination of TON blockchain platform abuse and legitimate Node.js presents a risk of evading many conventional detection mechanisms.

In alignment with the campaign's progression, new domain registrations and C&C server switching were also carried out, indicating that the attackers are constantly monitoring attack trends and success rates. Endpoints infected with TONResolver are perpetually waiting for command reception via Keepalive; if the attacker chooses to target them, the attack can proceed — a risk that persists continuously.

Node.js is a convenient execution environment and platform that can easily run JavaScript on endpoints and execute applications. However, such convenient environments can at times evade detection and also facilitate attacker operations. It is critical that organizations continuously monitor the services and processes running on their endpoints and build systems for establishing baselines and detecting anomalies on an ongoing basis.

For targeted Booking.com partner companies, it has been confirmed that victimization has occurred through email as an attack vector. Implementing controls on communications and applications unnecessary for normal business operations, leveraging existing services and capabilities, can also help protect organizations from these attack-related threats. We recommend reviewing configurations, strengthening monitoring, and reassessing incident response operational procedures at this time.

Security recommendations

The following countermeasures and mitigation are recommended against these attacks:

Restricting connectivity to the TON platform

By deploying a proxy gateway on internet-facing endpoints and performing connection filtering, it is possible to protect against specific dead drop resolver abuse. In this attack, the C&C server domain was retrieved by accessing "tonapi[.]io."

Normally, the need for business environments to access blockchain platforms is considered limited. If such communication is unnecessary, pre-emptively implementing connectivity restrictions can sever the attack chain at an intermediate stage.

Detection by TrendAI Vision One™ Workbench

Workbench detects suspicious use of Node.js through the "Suspicious Autorun Entry Created by Node.js" model with a severity rating of High.

Figure 26. TrendAI Vision One™ Workbench detection of the TONResolver attack chain

TrendAI™ Apex One™ and TrendAI Vision One™ Endpoint Security

By utilizing the firewall functionality built into the endpoint, it is possible to implement communication restrictions to block the PS1 file retrieval communication in this attack. By configuring settings to block Powershell.exe communications to external IP addresses, the attack can be interrupted midway. Configuration is required from the Endpoint Security menu in the Vision One console.

TrendAI Vision One™ Zero Trust Secure Access (ZTSA)

By implementing communication restrictions on User-Agents containing the "Powershell" string through the Internet Access Rules provided by ZTSA, external communications by PowerShell and attacks involving file retrieval can be interrupted. Configuration is required from the Zero Trust Secure Access menu in the Vision One console.

Hunting queries

MDR Data Explorer App

Customers using TrendAI Vision One™ can use the XDR Data Explorer App to match the malicious indicators covered in this blog article against data in their own environments for hunting purposes.

eventSubId: 101 AND processCmd: (powershell.exe AND ps1) AND objectFilePath: AppData\\Local\\Nodejs\\node.zip AND parentCmd: ([bigint] OR BigInteger)

eventSubId: 901 AND processCmd: (SOFTWARE\\Microsoft\\Cryptography AND MachineGuid) AND parentFilePath: \\AppData\\Local\\Nodejs\\node-v24.13.0-win-x64\\node.exe AND processName: powershell.exe

eventSubId: 301 AND processFilePath: AppData\\Local\\Nodejs\\node-v24.13.0-win-x64\\node.exe AND processCmd: (node.exe AND .js) AND hostName: tonapi

Indicators of compromise (IOCs)

The full list of IOCs can be found here.

Special thanks to Don Ovid Ladores (Advanced Cyber Defense Group, Senior Engineer, Threat IR and Forensic), JP Managed Service Team’s Engineer, who coordinated with us in this investigation.

TONResolver RAT Abuses TON Blockchain to Target Japan's Hotel Industry

Key takeaways

Characteristics of the phishing emails

Multiple types of delivery infrastructure used by attackers

Infection chain via user execution

Static analysis of the malware TONResolver

Dynamic analysis

Analysis of blockchain TON contracts and transactions

Attack observation by TrendAI Vision One™ Services – Managed Detection and Response (MDR)

Conclusion

Security recommendations

Hunting queries

Indicators of compromise (IOCs)

Authors

Trend Vision One™ – Proaktive Sicherheit beginnt hier.

Ressourcen

Support

Über Trend

Hauptniederlassung DACH