How Malware Abused Paste.tc: XWorm, LimeRAT, and AsyncRAT Cases

Paste.tc was used in observed 2021–2024 malware chains as a dead-drop resolver for command-and-control (C2) infrastructure and, in separate captures, as a host for second-stage PowerShell. In three public sandbox reports, AsyncRAT, LimeRAT/njRAT, and XWorm reached a paste.tc/raw/... URL before connecting to another host or high TCP port. The domain was not the final C2 in those cases: the useful signal was the combination of process, raw path, response, and next connection.

There is an important attribution boundary. Registry data now gives paste.tc a May 16, 2025 creation date, while the current site prohibits malware.^[11] The historical raw URLs examined for this article return 404, and we found no verified campaign after that registration date. The cases below document historical abuse of the domain name; they do not establish involvement by its current operator.

Key findings

• Two abuse models appeared. Small raw pastes supplied a real host:port value to a RAT; much larger pastes carried PowerShell with an embedded PE byte array.
• The implementation was simple and reusable. Public AsyncRAT and LimeRAT code downloads a configured paste URL, splits its response on a colon, and uses the first value as the host and a later value as the port.
• Domain reputation alone was insufficient. A clean root page and an HTTPS connection can coexist with a malicious user-created path.
• The strongest detection is sequential. Correlate a non-browser process requesting /raw/ with a second connection by the same process to a rare IP, dynamic-DNS name, or high port.
• Blanket blocking is a poor default. Block confirmed paste paths and downstream C2 indicators; do not block Cloudflare IPs shared by unrelated sites.

Scope and evidence model

We reviewed public ANY.RUN reports, including process and network timelines, for three Windows samples; compared the behavior with two public RAT source trees; checked two URLScan captures of raw paste content; tested the cited historical paths; and reviewed the current site policy and registry record. We did not execute malware or retrieve live payloads.

The analysis uses three confidence levels:

• Observed: a sandbox or web capture directly records the process, request, response content, persistence, or next connection.
• Corroborated: public source code implements the same retrieval-and-split mechanism seen in the sandbox.
• Inferred: a relationship is consistent with timing and configuration, but the public report does not expose every packet or decoded instruction.

How the Paste.tc C2 relay worked

The common pattern is a dead-drop resolver: malware knows the address of a legitimate web service, but not necessarily the current address of its operator’s server. It fetches a small record such as example.invalid:443, parses the value, and then opens the real C2 connection. The attacker can rotate the destination by editing the paste instead of rebuilding and redistributing the implant.^[1]

This separation matters for incident response. A request to a paste site may look like ordinary HTTPS traffic, while the destination that follows it may be an unfamiliar IP on a nonstandard port. Neither event is as strong alone as the two-event sequence.

Three concrete malware cases

Case 1: AsyncRAT used a paste as an address book

The 2021 AsyncRAT report is the clearest early example of indirection. The process first contacted Paste.tc and then an Ngrok TCP endpoint. Static analysis of the sample alone could reveal the paste URL without revealing the final C2 address that was present when the malware ran.

Public AsyncRAT code explains the implementation. If a paste setting is present, the client uses WebClient.DownloadString, splits the response on :, assigns the first element to the host, selects a later element as a port, and connects.^[5] Reduced to safe pseudocode, the logic is:

GET configured raw-paste URL
split response on ":"
host = first field
port = one later field
connect(host, port)

The paste can therefore contain one host and multiple ports. That makes the response format itself a useful hunt clue, even when the final address has rotated.

Case 2: LimeRAT encrypted the resolver URL in its settings

The 2024 LimeRAT/njRAT case used the same architecture with an extra configuration layer. The client decrypts the configured paste URL, downloads the response, splits it on a colon, and connects to the selected host and port. That exact sequence is visible in the public LimeRAT client code.^[6]

The sandbox also recorded behavior beyond C2 discovery: a dropped executable in %TEMP%, registry persistence, anti-analysis checks, and propagation options. This is why a paste request from a browser and a paste request from an unsigned executable in Temp are very different security events.

Case 3: XWorm paired the raw paste with scheduled-task persistence

In the XWorm report, XpiViewer.exe was both the process that contacted Paste.tc and the process that reached the final IP address. The one-minute XPI scheduled task made the chain recurrent. Even if a network block interrupted one connection, persistence could trigger another attempt shortly afterward.

The evidence supports a high-confidence sequence—raw-paste request followed by a direct connection from the same PID—but not a claim that every Paste.tc request by XWorm uses the same response format. The historical paste is gone, so its exact contents cannot be revalidated today.

A second implementation: hosting PowerShell and an embedded PE

Not every malicious paste acted only as a pointer. URLScan captured two large text/plain responses under the names officexwrm and xwrm-99580. Both contained PowerShell that created an alias for IEX and defined a large byte array beginning with decimal values 77,90—the ASCII bytes for the MZ header of a Windows PE file.^[7][8]

The captures had different resource hashes, which is consistent with separate payload variants rather than one repeatedly scanned object:

officexwrm resource SHA-256
658543c2ce30e8c6c521680607c00aaa8245d95458506e6a389bef43c1febeae

xwrm-99580 resource SHA-256
ec96a2706e1f4b7734ad5a9c7b175b5fa839d8f20f7cd0328820b38436b11c90

We are intentionally not reproducing the full scripts or arrays. For defenders, the useful identity is the response shape: PowerShell syntax, an unusually large decimal byte array, an IEX-style execution path, and an MZ prefix.

Stable behavior versus rotating indicators

Exact hashes remain valuable for retrospective searches, but they are not a durable preventive control. The current historical paste paths return 404, and the final C2 infrastructure may have disappeared or changed ownership.

MITRE ATT&CK mapping

Detection and hunting opportunities

A useful analytic should correlate endpoint and network telemetry instead of treating the hostname as a verdict. Start with this sequence:

1. Identify HTTP/S requests to paste.tc, prioritizing paths beginning with /raw/.
2. Exclude expected browser and approved developer-tool activity only after validating the process path and signer.
3. Within the next 60 seconds, look for the same PID or process tree connecting to a rare external IP, dynamic-DNS hostname, or unusual TCP port.
4. Increase severity if the originating binary runs from %TEMP%, %APPDATA%, Downloads, or another user-writable directory.
5. Check for adjacent persistence: HKCU Run values, scheduled tasks with short recurrence, Startup entries, services, or copied executables.

Where TLS inspection or endpoint response capture is permitted, two body patterns deserve review:

Pattern A: short resolver record
{hostname-or-ip}:{port}[:{alternate-port}]

Pattern B: staged PowerShell
[Byte[]] ... (77,90,...) ... IEX or assembly-loading behavior

Do not turn these patterns into an automatic conviction. Developers and administrators use paste services legitimately, and decimal arrays can occur in benign tooling. Process ancestry, file origin, persistence, and the immediate downstream connection supply the missing context.

Containment and response

1. Isolate the endpoint when a suspicious process has already reached a second destination or established persistence.
2. Preserve the process tree and network timeline before terminating processes, including the raw path, response size, next destination, and PID relationship.
3. Block the exact malicious path and downstream C2. Avoid blocking the Cloudflare IPs currently serving the domain because those addresses are shared infrastructure.
4. Remove persistence and dropped files, then reboot and verify that the scheduled task, Run entry, or process does not return. Our RAT response guide covers the broader containment decisions.
5. Run a full endpoint scan. For a personal Windows system, Gridinsoft Anti-Malware can check dropped files, startup entries, scheduled tasks, and other persistence, but no scan can prove that credentials were never exposed.
6. Reset sensitive credentials from a clean device if the RAT executed, especially email, browser-saved accounts, messaging, banking, and cryptocurrency access.

If the only evidence is a URL, inspect the complete path rather than the root domain alone. The current Gridinsoft reputation report for Paste.tc describes the root as generally safe; that does not retroactively clear historical user-created paths or make every future paste trustworthy. For suspicious PowerShell behavior, see our guide to PowerShell outbound connections.

What the current Paste.tc site changes—and what it does not

The current FAQ says public and unlisted pastes can be created without an account and documents raw-output URLs.^[10] Those features are useful for legitimate sharing, but they also preserve the low-friction mechanics that attackers historically sought. The current Terms explicitly prohibit malware and illegal activity.^[9]

Neither point establishes that the present service is malicious. The 2025 registry creation date creates a discontinuity with the 2021–2024 evidence, and attribution across that boundary would require ownership records or fresh operational evidence we do not have. Our confidence is high in the historical behavior and low in any claim about continuity of operators.

FAQ

References

1. MITRE ATT&CK. “Web Service: Dead Drop Resolver (T1102.001).” MITRE, updated May 12, 2026. Technique page.
2. ANY.RUN. “ByRR Crypter & Binder.rar — AsyncRAT malware analysis.” Public sandbox report, March 23, 2021. Report.
3. ANY.RUN. “New-Client.exe — LimeRAT/njRAT malware analysis.” Public sandbox report, July 28, 2024. Report.
4. ANY.RUN. “Stake Predictor.exe — XWorm malware analysis.” Public sandbox report, August 14, 2024. Report.
5. NYAN-x-CAT. “AsyncRAT ClientSocket.cs.” GitHub source repository, accessed August 14, 2026. Source file.
6. NYAN-x-CAT. “Lime-RAT C_TcpClient.vb.” GitHub source repository, accessed August 14, 2026. Source file.
7. urlscan.io. “paste.tc/officexwrm capture.” Public result captured September 12, 2024; accessed August 14, 2026. Result.
8. urlscan.io. “paste.tc/xwrm-99580 capture.” Public result captured October 26, 2024; accessed August 14, 2026. Result.
9. Paste.tc. “Terms of Service.” Updated May 17, 2025; accessed August 14, 2026. Terms.
10. Paste.tc. “Frequently Asked Questions.” Accessed August 14, 2026. FAQ.
11. NIC.TC Registry. “WHOIS record for paste.tc.” Accessed through ICANN Lookup, August 14, 2026. Registry record.