A Match Made in Malware: Quick Assist
A convincing voice on the phone can do what a vulnerability scan cannot. Vishing works because it exploits urgency, authority, and the natural desire to be helpful, which turns routine support moment into a security event. The Blackpoint Security Operations Center (SOC) continues to respond to breaches stemming from a threat actor masquerading as the help desk or support to obtain remote access using Quick Assist. During these killchains, the threat actor only needs to convince the user that they are talking to the right person long enough for the staging of further payloads on this host.
From there, the intrusions follow a familiar modern playbook that blends social engineering with low friction tradecraft. Quick Assist provides interactive access that appears legitimate in real time, and once the session is established, the attacker can stage additional tooling with basic command execution. In this case, the operator uses simple download and execution steps to introduce payloads, then pivots into scripted follow on activity to prepare the host for continued operations. The technical details matter, but the bigger story is that the attacker is leveraging normal workflows to make abnormal behavior feel expected.
The killchain at a high level is a rapid escalation from helpdesk style access to persistence and operator flexibility. After establishing remote control, the attacker retrieves additional components and executes them using common Windows mechanisms, then transitions into a Bring Your Own Runtime (BYOR) approach that enables JavaScript based tooling and follow on payloads. Persistence is achieved through user level autorun behavior, so access survives reboots, and the attacker performs quick profiling to understand the system, the locale, and the environment they landed in. None of these steps require exotic malware. They rely on familiarity, speed, and the ability to operate under the cover of legitimacy.
Who should care is anyone who assumes endpoint security is primarily a technology problem. Security leadership should care because remote assistance tooling is often treated as an IT convenience rather than an access channel that needs policy, controls, and telemetry. IT and helpdesk teams should care because vishing frequently impersonates support staff, and informal verification processes make it easier for attackers to blend into normal operations. Executives should care because this is the practical reality of people as the weakest link. The goal is not to shame users; it is to design guardrails that reduce the blast radius of a single moment of trust, and to detect the pivot from remote support into attacker-controlled execution before it becomes a persistent compromise.
Key Takeaways
- Vishing is the real initial access vector. The technical intrusion starts after the attacker trust from a user.
- Remote support tools are remote access tools in practice. Quick Assist should be governed, monitored, and risk managed like any other interactive access channel.
- The fastest killchains are low complexity. Native utilities and straightforward download and execute steps can be enough to establish control and stage follow on tooling.
- BYOR changes the defender’s problem set. Once an attacker can bring or leverage a runtime, they gain flexibility to run modular scripts and tooling without relying on traditional malware packaging.
- Defense must match the workflow, not just the malware. Combine strong caller verification and remote support procedures with endpoint and identity telemetry that flags when a legitimate Quick Assist session turns into command execution, payload staging, and runtime-based tooling.
Timeline
From Helpful to Hostile: Quick Assist as Initial Access
The Blackpoint Response Operations Center (BROC) recently responded to an intrusion that converted a socially engineered Quick Assist session into a staged, multi-path execution pipeline. The key theme across the observed activity is optionality. The attacker did not rely on one dropper or one execution method. Instead, they established interactive control through a trusted support channel, then staged multiple artifacts that each served a distinct role: immediate code execution, packaged script-based delivery, and a runtime-enabled orchestration layer that could flex based on what the endpoint allowed.
From the Quick Assist foothold, the operator’s priority was to get durable staging material onto disk using tools that are commonly present and frequently abused for this purpose. Curl was used to write an MSI package into the user’s Temp directory, while bitsadmin was used to retrieve a companion DLL from the same external host. Redundancy matters because it increases reliability under varied defensive conditions. If one transfer method is blocked, throttled, or flagged, the operator still has a second route. This is a strong indicator of hands-on keyboard tradecraft rather than a single scripted commodity drop.
Image showcasing Process Tree during operator staging
Once staged, execution was designed to remain familiar to Windows while minimizing dependencies on higher privilege mechanisms. The DLL, lpu.dll, is a 32-bit loader style module with a single exported function named main, executed via rundll32 directly from a user writable Temp path. The file structure is consistent with an execution bridge: minimal static imports and a design that favors runtime resolution, which reduces obvious indicators during quick triage and keeps meaningful behavior behind dynamically resolved API calls.
That orchestration role is filled by Spf.ps1, which is not just a downloader but an environment preparation and payload materialization script. Rather than dropping cleartext next stage logic, Spf.ps1 prepares a user space Node.js runtime by pulling Node 18.17.0 from nodejs.org, then invokes npm in silent mode to install prerequisites. These prerequisites are leveraged to ensure the requirements are present to drop an implant for the Tsundere Netto botnet.
From Access to Action: Tsundere Netto Deployment
Tsundere Netto is a multi-stage malware botnet that blends social engineering, lightweight loaders, and modular payload delivery to establish and maintain control of infected systems. It is notable for using layered staging and obfuscation to hide critical infrastructure details until later in execution, which makes early detection and attribution more difficult. At a high level, it reflects a modern operator mindset that favors flexible delivery, resilient command and control, and rapid adaptation over a single monolithic malware binary.
Analysis of the JavaScript tied to the Tsundere Netto botnet shows it was packed with the free, widely used service obfuscator.io. Once deobfuscated, the script exposes several hard coded values that anchor the campaign command path to the Ethereum ecosystem, including a wallet reference and a smart contract address used as an external coordination point.
Image showing the hardcoded Contract + Wallet address
Reviewing the associated contract activity in Etherscan shows three prior transactions. More importantly, the transaction input data can be decoded to recover the botnet’s downstream Command –and –Control (C2) details. In this case, decoding reveals a WebSocket endpoint that the malware uses as its C2 address, effectively treating the contract as a resolver that publishes where infected hosts should connect next.
Image showing the transactions on etherscan for this malicious wallet
This on-chain design reflects an EtherHiding style tradecraft choice and fits the broader kill chain by separating delivery from control. Instead of embedding a fixed command and control destination that can be quickly blocked, the malware retrieves a blockchain hosted value that acts as a durable pointer to the current operator infrastructure.
In this case, the resolved contract data points to a WebSocket endpoint, which directly supports the malware’s interactive command and control model. That matters because it gives the operator a flexible way to rotate backend infrastructure while preserving the same staging workflow, making the overall intrusion chain more resilient and harder to disrupt with simple blocklists.
Image showing decoded WebSocket C2
Beyond the on-chain indirection, the bot’s WebSocket transport is engineered to be resilient and stateful, which is where the ping pong logic becomes more than just connectivity noise. After the client receives the AES key and IV from the server and enrolls by sending an encrypted system fingerprint, it moves into a steady heartbeat loop that periodically transmits an encrypted ping and expects an encrypted pong in return. This does two things operationally. It gives the operator a cheap liveness signal for hosts that are still online and reachable, and it provides a builtin health check that forces a reconnect when the session is disrupted or tampered with.
The implementation is also defensive in practice: if the client is already waiting for a pong, it will not spam the server, and if a pong does not arrive within the timeout window, it intentionally closes the socket and re initiates the connection cycle. This self healing loop pairs naturally with the contract based endpoint lookup, since each reconnect is an opportunity to pull up updated infrastructure without pushing a new sample.
Image showing Ping Pong logic of Tsundere
The locale gate further supports attribution to Tsundere Netto tradecraft because it behaves like a targeting decision, not just a generic sandbox check. Before the implant retrieves infrastructure details or opens a WebSocket session, it checks the system’s installed UI culture, which is the operating system language and regional setting used to present menus, dialogs, and interface text. It then compares that value against a denylist of locales commonly associated with CIS and nearby regions and exits immediately when there is a match.
This matters because it shows intent. A CIS locale check is a form of environment fingerprinting, where malware inspects host characteristics to decide whether a system fits the operator’s targeting model. In practice, this reduces exposure in regions the operator wants to avoid, limits accidental infections, and helps preserve infrastructure by preventing unnecessary connections from non target environments. The sequencing is especially important because the check runs early and quietly, which means the malware can avoid touching blockchain RPC providers or the downstream C2 infrastructure at all when the host does not meet its criteria.
Image showing Locale Check
Combined with the Russian language diagnostic strings in the RPC handling and the overall operator centric reliability patterns, this is consistent with a botnet that is actively managing exposure, avoiding unwanted attention, and steering execution toward intended victim populations. In other words, the ping pong and locale logic are not just implementation details; they are behavioral markers that align with a mature, region aware operator model rather than a one off commodity Node backdoor.
Image showing Censys.io results for C2. HTML panel shows the telltale Tsundere Netto title
Serial.msi behaves less like a legitimate installer and more like a delivery container for a quiet launcher chain that can run under the user’s context. Based on the updated artifacts, the MSI drops a small VBScript wrapper, Falcon13.vbs, whose only purpose is to start PowerShell in a hidden window with profile loading disabled and execution policy bypassed, then hand off to a local script, eagle_package6.ps1.
Image showing the contents of the Falcon13.vbs Wrapper
Eagle_package6.ps1 bootstraps Deno in the user profile and then uses it as the runtime for the next stage. Deno is an open source JavaScript and TypeScript runtime, similar to Node.js, that makes it easy to fetch code over the network and run it as modules. In this chain, the attacker uses Deno as a Bring Your Own Runtime (BYOR) platform and launches it with the -A flag, which grants broad permissions and allows the downloaded module to access the system and network without meaningful restrictions.
If deno.exe is missing, the script installs it from the official deno[.]land installer. It then launches Deno with full permissions and executes a base64-encoded JavaScript stager via a data URL, which keeps the meaningful logic off disk and easy to replace.
The JavaScript stager fingerprints the host, performs a simple local check to avoid collisions, validates a reachable upstream endpoint using a health probe, and then dynamically imports the next stage from the network. In practice, the MSI is simply the packaging layer. The real functionality lives in runtime driven stages that can be updated without rebuilding the installer.
The decoded Deno stager is the control loop behind the Serial.msi execution path. It is not the final payload. It is a lightweight loader that fingerprints the host, confirms the attacker’s infrastructure is reachable, and then pulls and executes a remote JavaScript module on a recurring basis.
Image showing the contents of Eagle_package6.ps1
Decoding the base64 that is fed to Deno explains why this BYOR chain is flexible for the attacker and difficult to triage. The loader launches Deno with a data URL that contains JavaScript encoded as base64, which allows the first stage to execute without writing a readable script to disk. This creates a portable bootstrap that can be delivered through an installer, executed quietly, and replaced easily without changing the surrounding launcher logic.
The decoded Deno content typically acts as a stager rather than a full implant. Its core behavior is to fetch the next stage from the network, transform the response into a base64 data module, import it dynamically, and execute the module’s default export. This shifts meaningful capability off host and keeps it server controlled. If infrastructure changes or a module is detected, the operator can update what the endpoint retrieves without rebuilding the MSI, the VBS wrapper, or the PowerShell loader.
Image showing decrypted Configuration tied to Deno BYOR
Reviewing the Deno stager shows that this is not a simple downloader. It acts as a configuration driven BYOR runner, with campaign context and routing logic embedded directly in the network request path. Before pulling the next stage, it checks that the upstream is reachable via a health probe, then builds a versioned retrieval URL that includes a JWT and a host specific identifier. This structure keeps the primary capability modular and controlled server-side, while the endpoint continuously performs a predictable cycle of fetching, importing, and executing the next module. The JWT details reveal the following:
- Campaign name
The embedded JWT payload includes a campaignName field set to “test”. While simple, this is still meaningful because it indicates the operator is organizing activity under a campaign construct rather than a one off script.
- Preset C2 / Staging Address
The initial upstream for this BYOR chain is okobojirent[.]com. The stager probes okobojirent[.]com/health to confirm availability before pulling the next stage. That health check pattern is consistent with an operator managed staging setup, where the client is designed to keep retrying until a live node becomes available.
- JWT Issuance Time
The JWT includes an issued-at timestamp (iat) of 1770156847. Converted from Unix epoch, that corresponds to Tue 3 February 2026 22:14:07 UTC. This timestamp is useful for correlating infrastructure activity, staging events, and the approximate timeline of when this configuration or campaign token was generated.
Notably, the BYOR runner’s C2 domain was registered on the same date as the JWT issued-at timestamp, suggesting the infrastructure was stood up in tandem with the token used to bootstrap this campaign.
Image showing registration date for the Deno C2 domain
What makes this killchain significant is not any single payload, but the operator’s mindset behind it. The sequence is built to reduce friction at every step: persuade a user to grant legitimate access, stage multiple execution paths to avoid single point failure and shift long-term capability into flexible runtimes where logic can be updated remotely and kept opaque at rest. Instead of betting one noisy malware drop, the methodology favors modularity, resilience, and deniability, with actions that can be framed as routine support or tooling setup until the foothold is durable. The bigger picture is that this tradecraft scales because it is repeatable and adaptable, and it pushes defenders toward detecting workflow abuse and intent rather than waiting for a single suspicious file to make the intrusion obvious.
Methodology and Attribution
Attribution for the botnet and C2 layer is assessed as highly probable to be Tsundere Netto, based on corroborating indicators in the deobfuscated JavaScript and its runtime behavior. The implant establishes an encrypted WebSocket client with a defined key and IV exchange, periodic ping-pong keepalives, and automatic reconnect logic, which reflects an operator model built for long lived, interactive tasking rather than one time beaconing. It also performs an early locale gate against CIS-aligned languages and exits when matches are found, indicating deliberate regional targeting and an intent to reduce operational exposure in specific environments.
This tradecraft is complemented by a BYOR execution strategy that uses Deno as a modular runner. Deno provides a modern JavaScript runtime with straightforward networking and module loading, and when launched with broad permissions it becomes an efficient platform for staging, updating, and executing follow on capability without relying on a traditional compiled implant. In this pattern, Deno is used to fetch remote content, import it dynamically as a module, and execute it in a repeatable loop, keeping the most meaningful logic server controlled and easy to rotate.
Finally, the campaign’s resilience is reinforced through blockchain-based indirection for C2 resolution. Instead of hard coding a single static endpoint, the malware queries an Ethereum smart contract via multiple public RPC providers, selects the most consistently returned value, and uses that result as its WebSocket destination. The recovered WebSocket URI, such as ws[://]185.236.25[.]119[:]3001, ties on-chain data directly to the live command path. Taken together, the combination of region aware execution gating, encrypted WebSocket control with heartbeat enforcement, Deno based BYOR staging, and smart contract-driven C2 routing aligns strongly with Tsundere Netto tradecraft and is unlikely to be coincidental.
Defense Takeaways & Partner Guidance
- Strengthen remote support verification, so vishing attempts fail more often. Require clear identity checks and a consistent approval process before any remote control session begins.
- Treat Quick Assist as a remote access channel. Limit where it is allowed, define who can use it, and watch for the moment a support session turns into command execution or software staging.
- Reduce exposure to built in download and transfer methods. Focus on spotting unusual outbound retrieval behavior that drops files into user writable locations.
- Harden common execution pivots. Pay particular attention to behaviors that convert staged files or remote scripts into code execution, especially when they appear during or immediately after a remote support session.
- Constrain BYOR patterns. Control the presence and use of script runtimes on endpoints, and flag runtime driven module loading that enables rapid payload rotation.
- Detect and remove user level persistence quickly. Monitor for new autorun mechanisms and respond when they appear in conjunction with remote session activity.
Concluding Thoughts
This incident highlights a modern intrusion mindset that prioritizes trust and workflow abuse over technical exploitation. The killchain moves quickly from social engineering to staged execution, using legitimate remote support as the entry point and then building a reliable path to run follow on code. The methodology is designed to look ordinary in the moment, with actions that can be framed as routine support or setup, even as the attacker establishes control and prepares the host for continued access.
The bigger takeaway is that this style of intrusion scales because it is simple, repeatable, and resilient. Instead of relying on one fragile payload, the operator uses layered staging, flexible runtimes, and modular retrieval to keep options open and rotate capability when needed. Defending against it requires the same mindset shift: focus less on single file detection and more on catching the pivot from legitimate user activity into attacker driven execution, persistence, and remote tasking.
Indicators of Compromise (IOCs)
| Type | Indicator | Context / Notes |
| Domain | terymar[.]com | Primary staging domain |
| Domain | okobojirent[.]com | Command and Control |
| Domain | deno[.]land | Legitimate Deno Domain |
| URL | hxxp[://]terymar[.]com/install/Serial.msi | Deno installer file |
| URL | hxxp[://]terymar[.]com/install/lpu.dll | Staging |
| URL | hxxp[://]terymar[.]com/install/Spf.ps1 | Tsundere Staging |
| URL | hxxp[://]okobojirent[.]com/mv2/ | C2 associated with Deno |
| IP | Ws[://]185.236.25[.]119:3001 | Tsundere Netto C2 |
| File name / Path | SHA256 | Context / Notes |
| Serial.msi | 23a0a9b0755e052966b1e9e6137334444494c250afcf9f4a7e18c650cf2f4078 | Installs Deno |
| lpu.dll | d587959841a763669279ad831b8f0379f6a7b037dffc19deab5d41f37f8b5ffc | Staged Payload |
| Spf.ps1 | 29b777e7c5470d557e34f3b7b76d2ee291c2dfe7fbaee72821b53eb50a4062c8 | Tsundere Dependency Installer |
| deno.exe | N/A | Deno Runtime |
| QOCEKoCOSUzuPItExA.js | 4654B4F03368DB1483A14B76FB772C5FCAD53D21B85A71CA5C543E75787DAC71 | Tsundere Netto |
| falcon13.vbs | 55FE8014D5C3148693F578127D79700785BA54D373A45674C5CBFB492B42B2FA | VBS Loader to Call Deno |
| eagle_package6.ps1 | 4A2594B704EC785958A3224EA60CC3D8F8D199D49A65C69B00B6FA71BC51CFB2 | PS1 Loader to Install Deno + start BYOR |
| Ethereum Contract | 0x2B77671cfEE4907776a95abbb9681eee598c102E |
| Wallet Address | 0x002E9Eb388CBd72bad2e1409306af719D0DB15e4 |